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.

XMEGA 16A4U a 32A4U różnie działa z tym samym programem

ele_marek 21 Lip 2017 17:55 852 6
  • #1 21 Lip 2017 17:55
    ele_marek
    Poziom 6  

    Witam wszystkich czytelników w szczególności tych którzy są gotowi podzielić się swoim doświadczeniem.
    Mam następujący problem i od dwóch dni nie umiem go pokonać. Wreszcie zdecydowałem się tu zasięgnąć rady. Rzadko to robię ale chyba już pora.
    Wysyłam z układu zewnętrznego po UART sześć bajtów do XMEGi która to obrabia te dane i przesyła dalej do MAX485 i leci to w linie do PC. Z braki uC pod jakie pierwotnie zaprojektowałem ten układ czyli 32A4U polutowałem kolejne dwa układy z zastosowaniem 16A4U.
    I teraz mam efekt taki że układ z 32A4U odsyła prawidłowe dane, a ten na 16A4U przekłamuje choć w sposób regularny, ale nie znalazłem zależności między danymi prawidłowymi a tymi przekłamanymi.
    Gdybym nie widział że program prawidłowo działa na 32A4U to bym próbował go poprawić. Jednak w tym wypadku to mogę go chyba tylko zepsuć.
    Już dwa lata buduję układy z xmeg'ami działające z UART 9600bpi i nigdy nie musiałem stosować zewnętrznego Q. Jednak może pora zacząć. Dolutowałem zewnętrzny Q plus 2x 22pF jednak nie mam pewności czy prawidłowo w kodzie włączyłem taktowanie z zewnątrz bo nie zaobserwowałem poprawy.
    Kiedyś zgłębiałem ten temat i pamiętam że dla prędkości 9600bpi przy zegarze 2MHz błąd jest tak mały, że jak wysyłam takie małe paczki to stabilność wewnętrznego zegara w XMEGA'ch spokojnie wystarcza. Takie też miałem dotychczas doświadczenia.
    Nie wiem, może kompletnie w złym miejscu szukam rozwiązania problemu.
    Mogę liczyć na jakąś drobną podpowiedź co tu zrobić żeby XMEGA16.... prawidłowo zapracowała?
    Oczywiście mogę polutować kolejne dwa układy z 32A4U i pewnie będzie działać jednak nurtuje mnie i gryzie _dlaczego_ w tym wypadku działa źle.
    A jeszcze dodam, że cały program mieści się w pamięci wersji 16. Tu błędu nie popełniłem bo program działa prawidłowo. Nie rozpisuję się co dokładnie robi bo nie chcę rozmydlać problemu.
    Oczywiście źródła prze kompilowałem na wersję 16A4U zanim wgrałem w uC.
    Ma ktoś jakieś sugestie???

    Marek

    0 6
  • #2 21 Lip 2017 18:24
    simw
    Poziom 15  

    32AU4 ma 2 razy więcej pamięci RAM.
    Może dla mniejszego brata po prostu następuje nadpisywanie stosu lub coś podobnego.
    Podczas kompilacji programu, w podsumowaniu nie zawsze widać właściwą zajętość pamięci ram, szczególnie mogę wprowadzać w błąd "duże"zmienne lokalne.

    0
  • #3 21 Lip 2017 18:30
    Rasel
    Poziom 20  

    Xmega16a4u ma 2 kB pamięci RAM, a Xmega32a4u - 4kB pamięci RAM. Może stos nadpisuje dane programu w RAM. Sprawdź ile masz wolnej pamięci RAM.

    PS.
    1. Widzę, że się spóźniłem z odpowiedzią.
    2. Ilość wolnej pamięci RAM sprawdź podczas symulacji lub napisz odpowiedni soft. To co jest podane podczas kompilacji jest niewiarygodne.

    0
  • #4 22 Lip 2017 23:22
    ele_marek
    Poziom 6  

    Problem rozwiązany! :)
    W pierwszej chwili bardzo wierzyłem że chodzi właśnie o ten stos, wydawało się to dość logiczne. Tym bardziej że mam w programie uruchomionych 10 rejestrów pierścieniowych każdy po 50 bajtów. Ponieważ w tym wypadku przesyłam tylko po 6 bajtów to szybciutko zmieniłem długość z 50 na 10 i już kompiluję i czekam na pozytywny rezultat. A tu (_|_). Dalej źle działa. Organoleptycznie udowodniłem sobie, że to jednak nie stos. Po chwili zastanowienia doszedłem do wniosku, że to nie mógł być stos bo program mi się nie wysypywał. A jak stos się przepełni to chyba zawsze kończy się wywaleniem dokumentnym programu, a w moim przypadku tego nie zaobserwowałem. Na 100% program mi się nie wywalał, bo choć mam uruchomionego watchdog'a to zwykle dodaję sobie w układach jakiegoś led'a którym monitoruję różne stany w tym start uC.
    Dobra teraz do sedna. Problemem były moje atmegi8 które wysyłały odbierane dane. Nie pisałem wcześniej o tym, żeby nie komplikować rozwiązania. Wcześniej sprawdzałem analizatorem stanów co atmegi8 wysyłają i skoro analizator pokazywał mi prawidłowe dane to zakładałem, że takie są. Przeanalizowałem dane których oczekuję z tymi które dostawałem po obróbce przez atxmegę i zauważyłem błędy na sąsiednich bitach w transmisji. To skierowało moje podejrzenia jednak w stronę problemów z transmisją i jej dokładnością. Ponieważ w układach z atmegami8 nie stosowałem kwarcu, a wiem że ich wewnętrzne zegary są dość niedokładne to postanowiłem dolutować Q i 2xC. Łatwo nie było bo płytki o wymiarach 22x18mm, oczywiście smd ale jakoś się udało. No i rezultat końcowy doskonały. Program w układzie zbierającym dane zarówno z 32A4U jak i 16A4u przekazuje do PC prawidłowo odczytane dane.
    Wnioski:
    Jak się szuka błędu tak gdzie go nie ma to można stracić dużo czasu.
    Jak się chce działać z transmisją asynchroniczną na atmega8 itp. to od razu trzeba takie uC taktować z zewnętrznego Q.
    Ja się wie to wszystko to należy się stosować, a ja choć wiedziałem że atmegi8 mają dość niedokładne rezonatory to to zlekceważyłem, bo od 2 lat do tej pory wszystko działało prawidłowo.
    No to teraz się przejechałem, a na dokładkę i dla utrudnienia niedokładność atmegi objawiała się tylko przy stosowaniu 16A4U, a nie stosując 32A4U co na dzień dobry bardzo dobrze wyprowadziło mnie w pole.
    Napisałem to wszystko aby podziękować tym którzy śpieszą z pomocą i dla wszystkich tych, którzy kiedyś przeczytają ten wątek szukając rozwiązania swoich problemów. Łatwiej stosować się do zasad niż je odkrywać i ustanawiać.

    0
  • #5 23 Lip 2017 12:21
    trol.six
    Poziom 30  

    ele_marek napisał:
    ak się chce działać z transmisją asynchroniczną na atmega8 itp. to od razu trzeba takie uC taktować z zewnętrznego Q.
    Ja się wie to wszystko to należy się stosować, a ja choć wiedziałem że atmegi8 mają dość niedokładne rezonatory to to zlekceważyłem, bo od 2 lat do tej pory wszystko działało prawidłowo.
    Atmegi mają rejestr OSCCAL od którego wartości zależy częstotliwość oscylatora wewnętrznego. Można ją programowo ustawiać, oraz korygować na bieżąco, jeśli z jakiegoś powodu nie chcemy użyć zewnętrznego kwarcu.

    0
  • #6 23 Lip 2017 17:35
    ele_marek
    Poziom 6  

    Faktycznie przypominam sobie coś o tym kiedyś czytałem, ale w kontekście jednorazowej kalibracji podczas programowania wsadu.
    Tak się teraz zastanawiam jak to można w praktyce zastosować, ale tak zastosować żeby ta korekta była wprowadzana dynamicznie czyli jak nastąpiła zmiana warunków atmosferycznych i częstotliwość taktowania transmisji się rozjechała to teraz prowadzam korektę w rejestrze OSCCAL. Jak ustalić że ta transmisja jest błędna jeśli nie ma informacji odsyłanej w druga stronę? Czy to jest w ogóle wykonalne?

    0
  • #7 27 Lip 2017 21:02
    tmf
    Moderator Mikrokontrolery Projektowanie

    @ele_marek Oczywiście jest to niewykonalne. Aby skalibrować cokolwiek potrzebujesz wzorzec. Tym wzorcem może być transmisja zwrotna. Jeśli tylko nadajesz to nie masz nic stabilnego w układzie wg czego mógłbyś zegar wykalibrować. Natomiast jeśli masz wolne piny to można zawsze zamias asynchronicznego UART, zrobić synchroniczny, wtedy master taktuje slave i nie ma problemu z kalibracją. ATMega8 obsługuje synchroniczny UART.

    0