Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[atmeg8][Bascom] Komunikacja z PC

pysiorek1985 21 Sty 2009 21:54 2250 12
  • #1 21 Sty 2009 21:54
    pysiorek1985
    Poziom 9  

    Witam
    W zasadzie już zbliżam się ku koncowi stacji meteorologicznej z wykorzystaniem atmegi8 i PC. Z uwagi na funkcje jakie musze wykorzystać a wiec timer i USART wystapił problem. Wykorzystując timer1 generuje przerwanie co sekunde i licze czas aktualny. Podczas połączenia z komputera wysyłam na zasadzie: 1 znak z PC, a w odpowiedzi z Atmegi string z 12 znaków i takich cykli będzie kilkadziesiąt. Ponieważ komunikacja może zostać wywołana w każdej chwili z PC i kiedy w grę wchodzi do tego przerwanie od timera stwierdziłem że podczas wywołania procedury USART poprostu wyłącze timer i włącze po zakończeniu transmisji i zsynchronizuje się z czasem z PC. I tutaj pojawił sie problem. Timer1 po 10 sekundach wyłącza mi się czyli podejżewam, że atmega wchodzi w procedure USARTA. Czy ma ktoś może jakąś metode na podobne zjawiska? Na osobnym programie obsługi RS232 wszystko działa bez problemu, a w połączeniu z kompletnym programem stacji klęka.


    Code:

    Do
    If Ischarwaiting() = 1 Then
                            Stop Timer1
                            Bufor = Inkey()
                            Print Wyjscie(w)
                            Incr W
                            If W > Ilosc Then W = 1
                            If W = Ilosc Then Start Timer1
    End If
    Loop
    End

    powyżej zamieszczam obsługę USART. Z góry dziękuję za wszystkie podpowiedzi[/code]


    Poprawiłem tytuł - Regulamin. [c_p]

    0 12
  • #2 21 Sty 2009 22:00
    dawid512
    Poziom 32  

    Najlepsza metoda to obsługa RS-a w przerwaniu od UARTA.

    0
  • #3 21 Sty 2009 22:31
    mirekk36
    Poziom 42  

    Witam,

    a po choinkę wyłączać Timer przy organizowaniu wymiany danych z PC ???

    poczyta sobie kolega o takich poleceniach jak np:

    Config Serialin - dzięki któremu można ustawić sobie bufor wejściowy, do tego proszę zobaczyć co przy tym poleceniu robi Bytematch - dzięki, któremu można sobie ustalić po nadejściu jakiego znaku ma się zainicjalizować np jakaś procedura odczytu danych z bufora.A nawet bez bytematch można wtedy (gdy mamy włączone buforowanie wejściowe) badać sobie za pomocą Ischarwaiting czy coś już siedzi w buforze i dopiero wtedy podjąć się odczytu całości danego polecenia - szybciutko za pomocą np INPUT, po którym już robisz odesłanie swoich danych.

    Dzięki takiemu podejściu możesz sobie mieć uruchomionych i 5 Timerów, których nie będziesz musiał wyłączać na czas transmisji. Gdyby na czas transmisji RS232 trzeba było wyłączać takie podstawowe bloki funkcjonalne jak Timery - to całe programowanie procków było by mocno pozbawione sensu.

    polecenie Config serialin - tworzy właśnie sprzętowy, oparty na przerwaniach bufor - i samemu dzięki temu nie trzeba się w tak prostych projektach "babrać" w budowanie własnej obsługi RS-a w przerwaniu UARTA

    pozdr

    0
  • #4 22 Sty 2009 17:07
    pysiorek1985
    Poziom 9  

    Witam
    W projekcie wysyłanych będzie około 800bytów danych do PC i w PC bedzie na bieżąco wyświetlane. Do czego zmierzam. W czasie kiedy bedę obsługiwać przerwanie od Timer1 może pojawić się sygnał do PC, że dokonywana bedzie tramsm,isja. W atmega8 nie mozna ustawiać priorytetów przerwań w odróżnieniu do 8051. Kiedy pojawiało mi się przerwanie do timer1 poprostu w PC zaczyły mi się wszystkie dane w buforze rozjeżdzać i podczas wyświetlaniu danych w Memo wyskakiwały mi zupelnie rozjechane informacje niezgodne z prawdą. Informacje jakie docierają do PC są jeszcze przetwarzane. Mniejsza o to. W zasadzie udało mi to przeskoczyć jednakże zastanawiało mnie to dlaczego przerwanie mi to samo sie uruchamiało skoro nie mialo ku temu podstaw. Ale dziękuję za uwagi.

    Dodano po 4 [godziny] 9 [minuty]:

    Przerwanie od USART jest napewno jakąś metodą, jednakże z tego co sie orientuję to w atmega wykonuję sie przerwanie które zostanie wywołane pierwsze, jeżeli byłoby to przerwanie od USART i trwałoby kilka sekund tj. wysyłanie informacji to po zakończeniu tylko poprzez sprawdzenie flagi przerwania od Timer1 wiedzialbym o tym przerwaniu i wątpię żeby to przerwanie wykonało sie kilkakrotnie zaległych cykli a skoro i tak będę sie za każdym razem synchronizować z PC to timer na czas komunikacji nie jest absolutnie potrzebny, a na chwilę obecną tylko mi komplikował komunikację a poza tym ponieważ dane dostarczone do PC i tak są umieszczone w buforze i sformatowane do prezentacji na PC a poza tym chciałem trochę ograniczyć długość komunikacji. Jeżeli jestem w błędzie to proszę o uwagę, wszyscy jesteśmy ludźmi w końcu i mamy prawo sie mylic.

    Dodano po 5 [sekundy]:

    0
  • #5 22 Sty 2009 17:41
    mirekk36
    Poziom 42  

    tak za bardzo przywyczaileś się do priorytetów przerwań z '51nki - i dlatego coś ciężko na razie ci załapać jak poruszać się z tym na zwykłych AVRkach. I stąd twoje kombinacje troszkę niepotrzebne albo założenia, że np przerwanie USART trwałoby kilka sekund ! ;)

    0
  • #6 22 Sty 2009 19:17
    pysiorek1985
    Poziom 9  

    Coż obecnie przy 40 próbkach tj 12bajtach prędkością 2400 i w programie na PC 200ms odczekaniem na odpowiedz to trwa około 2 sekund. Ponieważ przysyłane dane są formatowane i wyświertlane na bieżąco podejżewam że przesłanie 200 próbek czasowych i każda po 3 bajty potrwa jakieś 4 sekundy a nie chcę być zniewolony czasami ponieważ zmiany cisnienia i temperatury i wilgotności nie są raczej zjawiskami których wahania w czasie kilku sekund mogą się znacznie zmieniać więc myśle, że w tym projekcie nie będzie znaczące. Po raz pierwszy w ogóle kombinuje z RS232 i atmega8 więc z pewnością później postaram się przyspieszyć to ale jak wszystko będzie już działać:) Może za duzo kombinuje ale cóż. Liczy sie efekt końcowy ale jak mozna pójść na skróty czemu nie :)

    0
  • #7 22 Sty 2009 21:20
    mirekk36
    Poziom 42  

    nawet jeśli prędkość będzie 1200 to i tak nigdy wszystkie twoje bajty nie są nadawane w jednym przerwaniu. Jeden znak jedno przerwanie. Ale fakt że przy tak małych prędkościach już trzeba zaczynać co nieco kombinować ;)

    z drugiej strony co ty tam takiego w przerwaniu Timera wyrabiasz, że może ono trwać zbyt długo. Dobra zasada jest taka aby każde przerwanie zajmowało jak najmniej czasu - jednak gdy widzę nieraz, jak niektórzy (nie mówię, że ty) wciskają np do obsługi przerwania (jakiegokolwiek) wyświetlanie czegoś np na LCD to ręce opadają. Trzeba używać własnych flag

    0
  • #8 23 Sty 2009 14:11
    pysiorek1985
    Poziom 9  

    Z przerwaniem masz racje, że najlepiej, aby przerwanie trwało jak najkrócej. Mam jeszcze pytanie bop na koniec transmisji wysyłam ciąg danych z PC jak narazie 3 znaki. Funkcja Waitkey z tego co czytałem zwraca przychodzący znak czy może ona zwrócić ciąg znaków jeżeli przypiszę ją do Bufora typu string*5? Probowałem odbierać osobnymi waitkey te 3 bajty ale po p-ierwszym znaku wartości są 0. Program pisałem w Builderze.

    0
  • #9 23 Sty 2009 15:10
    mirekk36
    Poziom 42  

    ale po co bawisz się w odbieranie waitkey??? już pisałem wcześniej:

    1. Utwórz sobie (sprzętowo obsługiwany) bufor wejściowy dla RS232 - za pomocą Config Serialin

    2. Potem używaj gdzieś w kodzie (w pętli głównej czy gdzie chcesz) polecenia Ischarwaiting - aby dowiedzieć, się czy czeka coś na ciebie w buforze

    3. Jeśli coś jest w buforze to odczytujesz od razu calość za pomocą polecenia INPUT (też pisalem o tym)

    z tym, że jeśli masz do wysłania z PCta 3bajty z danymi to jeszcze musisz na ich końcu dodać znak CR o kodzie 13 dziesiętnie, aby polecenie INPUT wczytało całość do twojej zmiennej stringowej i już.

    To na początek - bo później jak już też wspominałem zainteresuj się czyms takim jak mechanizm Bytematch (uruchamiany przy Config Serialin)

    - jak wypróbujesz to o czym piszę - to wiele twoich obecnych problemów z komunikacją RS232 odejdzie w niepamięć ;)

    0
  • #10 23 Sty 2009 19:21
    Jacek54
    Poziom 10  

    Mam pytania:
    1. czy przesyłane dane bedą odbierane na terminalu ?
    2. czy przesłane dane do PC będą obrabiane przez jakiś program.
    3. W jakim języku będzie to program.
    Słyszałem, że do tego nadaje się QBasic pod DOSem

    0
  • #11 25 Sty 2009 12:34
    pysiorek1985
    Poziom 9  

    Twoje porady Mirku muszę przyznać, że dość mi pomogły i miałeś racje. W zasadzie już to działa wszystko. Tak czysto teoretycznie RS232 jest juz rozpracowany ale tak z ciekawości jakby można było wykorzystać USB zamiasr RS232. Z tego co wiem to do napisania musiałbym wykorzystać VxD i biblioteki dll. Wiem, że atmega nie ma USB ale jakby załóżmy udało się napisać w asmeblerze taki lagorytm na Atmege pod USB to byłaby możliwość jakaś by w C++Builderze napisać komunikacje USB tak, żeby nie trzeba było wgrywać VxD? Jst to tylko gdybanie ale może znacie jakąś metodę na to:)

    0
  • #12 25 Sty 2009 14:04
    mirekk36
    Poziom 42  

    pysiorek1985 -> mam dla ciebie dobrą poradę jeśli chodzi o wykorzystanie USB - ale nie zamiast RS232 a przy udziale komunikacji RS232.

    1. RS232 - jak już powoli zauważasz to bardzo dobry, szybki (tani w implementacji bo nie dużo trzeba się naprogramować) protokół wymiany danych - jakichkolwiek

    2. USB - to nowe medium pomiędzy PCtem a urządzeniami zewnętrznymi i czasem już nie spotyka się nawet złączy RS232

    3. Implementacja na własną rękę w asemblerze - obsługi USB na takich prockach - to niestety - muszę cię zmartwić ale jest jak "rzucanie się z motyką na słońce" albo "wywarzanie głową muru" - innymi słowy mało opłacalne i optymalne.

    Jak już chciałbyś zobaczyć dlaczego to mówię to poczytaj sobie - informację np na: http://www.obdev.at/products/avrusb/index.html lub kilku innych stronkach - i wtedy dopiero spróbuj zmierzyć ale swoje prawdziwe siły na zamiary

    .... po co jednak rezygnować z RS232 skoro można przepięknie "ożenić" jedno i drugie a wtedy cieszyć się urokami życia ;) .... czyli w prosty sposób mieć komunikację po USB ale za pomocą protokołu RS232

    jak???

    polecem dwa rozwiązania, albo:

    https://www.elektroda.pl/rtvforum/topic827115.html

    albo o wiele skuteczniejszy i bardziej elegancki sposób, który ostatnio już tylko używam to:

    FTDI 232RL

    poczytaj sobie notę aplikacyjną tego scalaczka to ci oczy zbieleją ;) mam nadzieję. Aplikacja "prosta jak drut" - UWAGA! praktycznie żadnych elementów zewnętrznych nie potrzeba do aplikacji tego scalaka poza kilkoma kondensatorami odsprzęgającymi zasilanie - a masz od razu w 5 sekund - pełnosprawną przejściówkę USB/RS232 albo nawet USB/RS485 - zaznaczam bez najmniejszych problemów i ograniczeń - co do przepustowości, wszystkich sygnałów sterujących a nawet kilku własnych.

    Co ważne - możesz się dzięki temu scalakowi komunikować ze swoimi urządzeniami albo przez RS232/485 - od stony PCta - będzie to virtualny port COM, albo też - poprzez właśnie biblioteki specjalnie do tego celu stworzone i udostępnione przez producenta na stronce - i dzieki nim możesz nawet jak się uprzesz już w prostszy sposób kontaktować się za pomocą protokołu USB od strony PCta ! - ot do wyboru do koloru.

    A sterowniki zawsze takie same, instalacja zawsze ślicznie działa na każdej windzie bez problemu. Dodatkowo uzyskujesz za przejściówką nawet dwa zasilania +5V oraz +3,3V - czyli możesz ją stosować dla układów pracujących na różnych napięciach zasilania jak widzisz i co ważne bez martwienia się o stosowanie układów dopasowujących poziomy sygnałów

    eeeeh - dużo by można było jeszcze pisać o zaletach - a lepiej wziąć PDFa i mózg od pomysłów zastosowań zaczyna się gotować.

    wady? - hmmm może jedna , malutka - układ jest w SMD więc trzeba go przylutować więc dla osób, które mają problemy z montażem SMD może to być małą przeszkodą

    ..... reasumując - po co odżegnywać się od starego, poczciwego, porządnego RS232 - jak widzisz

    0
  • #13 29 Sty 2009 21:52
    pysiorek1985
    Poziom 9  

    No proszę. Rzeczywiście taki układ dużo ułatwia :) Moja wiedza na temat komunikacji jest jeszcze dość krucha ale z pewnością Twoje Mirku porady były pomocne. dzieki zamykam temat. Program z prockiem działają już bez zarzutu

    0