logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[Atmega8][C]Problem z odczytem ramki z modułu RFID

monte88 12 Wrz 2011 02:21 3042 9
  • #1 9918264
    monte88
    Poziom 9  
    Witam.

    Mam pewien problem z odczytem ramki z czytnika RFID. Moduł (z allegro) komunikuje się z atmegą przy pomocy UART-a. Atmega działa na wewnętrznym oscylatorze 1MHz, parametry transmisji: 19200 bps, bez parzystości, 8 bitów danych, 1 bit stopu. Jakąś tam ramkę udało mi się odebrać, tzn. 4 bajty z czego tylko 3 pierwsze są poprawne. Poprawna ramka powinna zawierać 16 bajtów. Układ składa się praktycznie tylko z Atmegi, LCD i modułu RFID więc raczej nie ma się gdzie pomylić w połączeniach dlatego też obstawiam, że problem tkwi gdzieś w samym programie, a jak na żółtodzioba przystało nie potrafię go znaleźć. Z góry dzięki za wszelką pomoc.

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #2 9918348
    mirekk36
    Poziom 42  
    Przede wszystkim jak na początkującego przystało popełniasz/powielasz ten sam błąd i zachowanie. Zapewne z uwagi na strach przed słynnym rzekomym zablokowaniem procka boisz się przestawić fusebitów na jakieś normalne taktowanie, np 8MHz. Dlatego działasz na fabrycznym 1MHz. A przy tej okazji wybierasz do komunikacji UART taką prędkość, która przy tak niskim taktowaniu procka nigdy nie będzie działać poprawnie. Czyli także jak na początkującego nie korzystasz z noty PDF procka. A wystarczyłoby zajrzeć na ostatnią stronę rozdziału USART noty PDF dowolnego procka AVR. Masz tam jak na tacy podane tabelki z prędkościami taktowania mikrokontrolerów począwszy właśnie od 1MHz oraz co WAŻNE po lewej masz podane prędkości RS232 i PROCENT BŁĘDÓW. No wystarczy zajrzeć do tej pierwszej tabelki żeby sprawdzić, że nie tylko 19200 ale i 9600 mają dużo większy procent błędów niż 2%. Tymczasem poprawnie będą działać te prędkości, które procent błędów mają poniżej 2% a najlepiej 0%.

    Przyjrzyj się np na procenty błędów dla prędkości RS232 przy zastosowaniu zewnętrznych kwarców (taktowania) takich jak np: 11,0592MHz może to ci też coś powie i na coś naprowadzi.

    Ale sprawdź sobie taktowanie w tabeli = 8MHz i zobacz, że gdybyś jednak nie bał się zmiany fusów i ustawił na 8MHz to bez problemu miałbyś komunikację na 19200.

    Mam nadzieję, że teraz jaśniej i zapamiętasz sobie ten rozdział w PDFach ? bo warto ;)
  • #3 9918537
    nsvinc
    Poziom 35  
    mirekk36 napisał:
    Tymczasem poprawnie będą działać te prędkości, które procent błędów mają poniżej 2% a najlepiej 0%.

    Kolega przesadził ;]
    Na 3..4% błędu potrafi i 115200bd prawidłowo działać... Na tak wolnej prędkości jak 9600 czy 19200, te 2% błędu są zupełnie pomijalne.

    Skoro kontroler UART potrafi prawidłowo odebrać pierwszy bajt, to każdy kolejny też będzie potrafił odebrać, ponieważ synchronizacja następuje z każdym bitem startu ramki; transmisja nie będzie działać wtedy, gdy sampler rozjedzie się w trakcie odbierania danego bajtu (przynajmniej w szanujących się kontrolerach UART). W tym przypadku błąd jest zbyt mały, aby to się stało.
  • #4 9918620
    mirekk36
    Poziom 42  
    nsvinc napisał:
    mirekk36 napisał:
    Tymczasem poprawnie będą działać te prędkości, które procent błędów mają poniżej 2% a najlepiej 0%.

    Kolega przesadził ;]
    Na 3..4% błędu potrafi i 115200bd prawidłowo działać... Na tak wolnej prędkości jak 9600 czy 19200, te 2% błędu są zupełnie pomijalne.
    .


    Idąc taką drogą porad, to też mógłbym powiedzieć, że kolega przesadził. Bo i na 5..6% i przy 115200 też będzie działać prawidłowo a szczególnie pomiędzy dwoma takimi samymi prockami.

    Toż nie chodzi o to. Zajrzyj ile jest procent błędu do noty dla 1MHz przy prędkości 19200. Więc zgodnie z moją poradą jeśli dobierzemy błąd poniżej 2% to zawsze będzie dobrze...

    A z procentem 3..4% co najwyżej jak sam kolega napisał - będzie potrafiło działać a czasem nie - to z kolei zależy od tego z jaką synchronizacją działa urządzenie po drugiej stronie. Stąd właśnie można przyjąć te 2% jako bezpieczny margines. A próbować z większym procentem każdy sobie może.
  • #5 9918961
    monte88
    Poziom 9  
    Bardzo dziękuję za porady. Niestety nadal coś jest nie tak. Po przestawieniu fusebitów na 8 MHz udało mi się odebrać całą ramkę ale teraz mam kolejny problem bo nie wszystkie dane są prawidłowe, tzn. pierwsze 5 bitów powinno być zawsze takie same: 7e 01 01 c1 c1. Te 5 bitów co prawda też odczytuje ale często między nimi w różnych miejscach jest jakiś jeden lub dwa inne. Czy może to być te 0,2% błedu czy problem leży gdzieś indziej? A, i jeszcze jedno pytanie. Przy ustawieniu pierwszego poziomu optymalizacji w AVR Studio przestaje mi działać lcd ale tylko przy zegarze innym niż 1 MHz. Czy da się to jakoś skonfigurować czy po prostu przy optymalizacji mogą już takie rzeczy się dziać?
  • #6 9918980
    mirekk36
    Poziom 42  
    Nie to nie jest te 2% a problem za to na 100% leży gdzieś indziej i na pewno w twoim oprogramowaniu niestety :(

    Odnośnie ustawień poziomów optymalizacji to taka dobra porada. Na tym etapie znajomości języka C ustaw na sztywno najwyższy poziom optymalizacji czyli - Os i NIE ZMIENIAJ go NIGDY ;)

    Bo już z tego opisu widać, że coś strasznie kombinujesz albo nawet przekombinowujesz.

    A tym przekombinowaniem jest m.inn to _delay_ms() w trakcie którego możesz tracić sporą część odbieranej ramki. To podstawowy błąd przekombinatoryki ;)
  • #7 9919193
    nsvinc
    Poziom 35  
    Ehh...
    mirekk36 napisał:
    [...]najwyższy poziom optymalizacji czyli - Os[...]

    Wprowadzasz w błąd. -Os nie jest "najwyższym" poziomem optymalizacji. -O3 jest najwyższym poziomem optymalizacji, i również, sprawia najwięcej kłopotów przy nieumiejętnie napisanym kodzie. -Os jest optymalizacją minimalizującą rozmiar kodu wynikowego...

    mirekk36 napisał:
    Idąc taką drogą porad, to też mógłbym powiedzieć, że kolega przesadził. Bo i na 5..6% i przy 115200 też będzie działać prawidłowo a szczególnie pomiędzy dwoma takimi samymi prockami.

    A ja mówię o komunikacji między prockiem a PCtem przez MAX3232 (nie VCP)...
  • #8 9919237
    mirekk36
    Poziom 42  
    nsvinc napisał:
    Ehh...
    mirekk36 napisał:
    [...]najwyższy poziom optymalizacji czyli - Os[...]

    Wprowadzasz w błąd. -Os nie jest "najwyższym" poziomem optymalizacji. -O3 jest najwyższym poziomem optymalizacji, i również, sprawia najwięcej kłopotów przy nieumiejętnie napisanym kodzie. -Os jest optymalizacją minimalizującą rozmiar kodu wynikowego...


    Tak, sorki tu masz całkowitą rację - pomyliłem się. Ale oczywiście polecam - Os ;)
  • #9 9919253
    nsvinc
    Poziom 35  
    Nie wiem czy -Os jest najlepszym pomysłem, bo, tak jak każda inna optymalizacja "wyższego stopnia", utrudnia debuggowanie. Do celów naukowych/debuggowych najlepiej chyba używać -O1 (przynajmniej na ARMach, na AVR może być podobnie).
    Stosując -Os trzeba też pamiętać o raczej słabej wydajności; mnożą się mikrofunkcje tworzone przez kompilator i setki skoków do nich i z powrotem, a każdy skok to cenny czas...
  • #10 9921756
    monte88
    Poziom 9  
    Dzięki za dobrą radę ale póki program nie będzie jakoś normalnie działał to wolę optymalizacji nie ruszać żeby sobie jeszcze więcej problemów nie narobić. Poza tym jak sprawdzałem Os to zaczęły mi się jakieś dziwne krzaki na wyświetlaczu pokazywać a bez optymalizacji jest ok.
    Trochę okroiłem program i przeszedłem na zewnętrzny kwarc 12Mhz ale nadal jest coś nie tak.
    Aktualnie sprawdzam tylko ile bajtów przesyła moduł rfid i okazuje się że najpierw jest 10 a następne są już po 9 więc może z modułem też jest coś nie tak albo (co jest znacznie bardziej prawdopodobne) ja jakoś źle tą ilość przesyłanych bajtów sprawdzam? Zna ktoś pewny sposób na sprawdzenie ile bajtów jest odbieranych?
    Tak poza tym, to za pierwszym razem gdy przyłożę kartę do modułu i odbierane jest te 10 bajtów z czego co najmniej 5 bajtów jest poprawnie, kolejne 5 chyba też (niestety nie znam numeru karty więc nie wiem czy to poprawny numer) ale już przy drugim odczycie karty się jakieś dziwne liczby pojawiają i nie mam pojęcia dlaczego :(


    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
REKLAMA