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

Atmega8 Bascom Uart - Nieprawidłowe znaki na terminalu po użyciu PRINT

adam220 25 Sty 2018 14:18 2607 45
REKLAMA
  • #1 16987701
    adam220
    Poziom 14  
    Witam,
    jest Atmega8.
    Niby wszystko dobrze podłaczone i skonfigurowane, ale coś jest źle bo na terminalu , po użyciu PRINT, widać krzaczki zamiast znaków.

    Kod
    Kod: VB.net
    Zaloguj się, aby zobaczyć kod


    a na terminalu zamiast
    aaaaaa
    widać
    000000y=
    Liczba znaków się zgadza. Ale znaki inne...
    Zmiana w kodzie na inne znaki np bbbbbb powoduje wyświetlenie sekwencji
    $$$$$$y=

    Ten "y=" na końcu to znaki CR/LF które znikają gdy da się średnik po komendzie print.

    NIe wiem co jest źle.

    Zasilanie 3v3,
    Fusy E1 D9, co moim zdaniem oznacza wewnętrzny oscylator 1MHz
    Programuję USBasp
    "avrdude" -p m8 -c usbasp -P lpt1 -U flash:w:"c:\Users\(...)\print.hex":a -U lfuse:w:0xe1:m -U hfuse:w:0xd9:m -v

    Taktowanie chyba poprawne bo waitms 1000 rzeczywiście daje 1s przerwy.

    Proszę o pomoc.
  • REKLAMA
  • #2 16987711
    tmf
    VIP Zasłużony dla elektroda
    adam220 napisał:
    Fusy E1 D9, co moim zdaniem oznacza wewnętrzny oscylator 1MHz


    Wewnętrzny oscylator RC nie nadaje się do taktowania transmisji UART - w ATMega8 ma zbyt duża niedokładność. A już szczególnie przy 1 MHz sam podział może wprowadzać zbyt duży błąd. Zmień najlepiej na kwarc, a przynajmniej zwiększ taktowanie do 8 MHz.
  • REKLAMA
  • #3 16987755
    pawlik118
    Poziom 32  
    Bez przesady - u mnie kilka lat system złożony z kilku atmeg działa na wewntrzym RC przy prędkości 250kbps. Dwe lub trzy ramki na dobę mają błąd (crc) (1 ramka na s - ok 100bajtów).
  • #4 16987760
    Kuniarz
    Moderator Projektowanie
    Czy terminal masz odpowiednio ustawiony ? 1200 bps 8N1 ?
    Pomogłem? Kup mi kawę.
  • #5 16987773
    adam220
    Poziom 14  
    @tmf wydawało mi się że już używałem bez problemu Atmegę8 z RC 1MHz z uartem.
    zmieniłem taktowanie na 8MHz (wew RC) i nadal źle. A nawet gorzej bo jeden ze środkowych znaków "a", odczytywany jest inaczej.

    @pawlik118 miałem notatkę w kodzie, nie wiem skąd że dla 1MHz błąd przy 4800 wynosi 0,1% a przy 9600 7%, co jest juz niedopuszczalne

    @Kuniarz tak sprawdzałem 1200 bps 8N1 i wszystkie inne kombinacje:( jaki mi przyszły do głowy...

    Czy napięcie zasilania 3v3 może mieć jakiś związek? Uważam że używałem tej samej płytki z uartem na 1Mhz ale była zasilana 5V.
  • #6 16987887
    maly_ninja
    Poziom 14  
    adam220 napisał:
    aaaaaa
    widać
    000000y=
    Liczba znaków się zgadza. Ale znaki inne...
    Zmiana w kodzie na inne znaki np bbbbbb powoduje wyświetlenie sekwencji
    $$$$$$y=


    To nie są do końca krzaki. Te znaki są ze sobą powiązane, tzn. a -> 0, b -> $ i \r\n -> y=. Wygląda na to, że jest błędna konfiguracja uarta, upewnij się, że na pewno masz ustawiony 1200,8n1. Może spróbuj włączyć inny terminal?
  • #7 16987962
    pawlik118
    Poziom 32  
    w terminalu też wybiera się sposób prezentowania - czy wartość, czy kod ASCII
  • #8 16988074
    tmf
    VIP Zasłużony dla elektroda
    pawlik118 napisał:
    Bez przesady - u mnie kilka lat system złożony z kilku atmeg działa na wewntrzym RC przy prędkości 250kbps.


    Fantastycznie, że jesteś farciarzem. Niemniej, ponieważ MCU mają niewiele wspólnego z magią, proponuję jednak zajrzeć do noty układu, w szczególności do sekcji opisującej taktowanie oraz na wykresy obrazujące stabilność gen. RC vs. temperatura i napięcie zasilania.
  • #9 16989017
    pawlik118
    Poziom 32  
    Ja się nie upieram że RC to gwarancja poprawności działania w każdych warunkach. W komentarzu do Twojego wpisu (sugerującego że komunikacja z wyk. gen. wewnętrznego uniemożliwia poprawną komunikację) chciałem jednak zwrócić uwagę, że komunikacja z powodzeniem może na nim działać.
  • REKLAMA
  • #10 16989449
    JacekCz
    Poziom 42  
    Mysle że implementacja kol @pawlik118 na zasadzie "kompensujących się błędów" ukrywa problem.

    Asynchroniczna transmisja bajtu wymaga 11-12 impulsów zależnie od ustawień. Jeśli przyjmiemy 12, weźmiemy odwrotność, błąd zegara 4% to pół impulsu, umowna granica że z większym błędem nie może dobrze działać.
  • #11 16989519
    el2010tmp
    Poziom 25  
    adam220 napisał:
    a na terminalu zamiast
    aaaaaa
    widać
    000000y=
    Liczba znaków się zgadza. Ale znaki inne...

    Stawiam na błędną konfiguracje terminala.
    'a' to binarnie: 01100001
    natomiast '0' to 00110000
    Jakiego terminala używasz ?
  • #12 16989732
    tmf
    VIP Zasłużony dla elektroda
    pawlik118 napisał:
    Ja się nie upieram że RC to gwarancja poprawności działania w każdych warunkach. W komentarzu do Twojego wpisu (sugerującego że komunikacja z wyk. gen. wewnętrznego uniemożliwia poprawną komunikację) chciałem jednak zwrócić uwagę, że komunikacja z powodzeniem może na nim działać.


    Co znaczy może? Układów nie projektuje się tak, aby "może" działały, tylko po prostu mają działać. Owszem, da się zrobić komunikację z użyciem wewnętrznego RC, ale, aby to działało, a nie "może" działało, trzeba się postarać i chociażby kalibrować generator, szczególnie jeśli już z samego faktu obniżenia napięcia z 5V na 3,3V, jak to ma miejsce u autora mamy kilkuprocentowy błąd.
    Tu mamy sytuację w której autorowi akurat komunikacja nie działa, więc fuksiarzem najwyraźiej nie jest i powinien przede wszystkim zastosować rozwiązanie zalecane przez producenta, czyli kwarc.
  • #13 16990017
    adam220
    Poziom 14  
    @tmf
    Założyłem oscylator 3,6864MHz jako najkorzystniejszy pod względem podziałów częstotliwosci, jak wynika z dokumentacji Atmegi.

    w kodzie oczywiście zmieniłem na $crystal = 3686400
    uruchomiłem i dalej to samo. Żadnej różnicy nie widzę.

    Sprawdziłem na innym komputerze (ale tym samym programowym terminalu Breya)

    znaki wpisane do kodu odczytane są ze 100% powtarzalnością jako inne znaki.
    Mógłbym zrobić tabelę ale nie widzę sensu.
    Na podglądzie bitów - nie stwierdzam jakiegoś powtarzalnego maskowania.
    Ale nie mam wprawy.

    Kombinacje prędkości, parzystości, stopu i liczby bitów przeleciałem wszystkie chyba.
    Najlepszy wynik dostaje się przy nastawach zgodnych z kodem. Jest wtedy ta podmiana znaków. Przy innych nastawach na ogół sieczka.

    O co tu chodzi??? Bo nie o kwarc.
    Może jakaś konfiguracja niewłaściwa, albo jakiejś brak?
    Kod z 1-wszego postu aktualny (obecnie poza $crystal).

    Dodano po 6 [minuty]:

    uzupełnienie
    Sprawdziłem na innym terminalu programowym (jakimś z netu).
    Wynik ten sam co w Breyu.
  • #14 16990122
    Kuniarz
    Moderator Projektowanie
    To może czas na konkrety, bo powyższe przepychanki na temat kwarcu, taktowania, błędów jak widać były (jak zwykle) niepotrzebne. Zasilanie procka masz 3,3V - co dalej ? Łączysz się przez jakiś adapter USB - UART ? Przejściówka również w logice 3,3V ?
    Pomogłem? Kup mi kawę.
  • #15 16990159
    pawlik118
    Poziom 32  
    tmf napisał:
    pawlik118 napisał:
    Ja się nie upieram że RC to gwarancja poprawności działania w każdych warunkach. W komentarzu do Twojego wpisu (sugerującego że komunikacja z wyk. gen. wewnętrznego uniemożliwia poprawną komunikację) chciałem jednak zwrócić uwagę, że komunikacja z powodzeniem może na nim działać.


    Co znaczy może? Układów nie projektuje się tak, aby "może" działały, tylko po prostu mają działać. Owszem, da się zrobić komunikację z użyciem wewnętrznego RC, ale, aby to działało, a nie "może" działało, trzeba się postarać i chociażby kalibrować generator, szczególnie jeśli już z samego faktu obniżenia napięcia z 5V na 3,3V, jak to ma miejsce u autora mamy kilkuprocentowy błąd.
    Tu mamy sytuację w której autorowi akurat komunikacja nie działa, więc fuksiarzem najwyraźiej nie jest i powinien przede wszystkim zastosować rozwiązanie zalecane przez producenta, czyli kwarc.


    Panie Moderatorze, proszę czytać moje posty ze zrozumieniem. Napisałem, że komunikacja z wyk. RC może działać poprawnie (tak jak jest u mnie w domu). Z tego wynika, że nie jest przesądzone, że komunikacja nie działa z powodu użycia RC, bo może być inny powód tego problemu. Oczywiście zgadzam się że bazowanie na niedokładnym RC jest rozwiązaniem niepewnym i niestabilnym, i w tej sytuacji należy zastosować kwarc. Nigdy nigdzie nie polecałem, ani nie upierałem się aby wykorzystać RC do komunikacji szeregowej.
  • #16 16990201
    adam220
    Poziom 14  
    @Kuniarz
    Tak, zasilanie 3V3.
    Pin Tx-owy atmegi i masa do złacza DB9,
    dalej chińska przejściówka RS232-USB i komputer.

    Tą przejściówkę używałem z innym prockiem (PIC) zasilanym z dwóch baterii AA.
    Sprawdziła się wtedy do napięcia słabej baterii 2,5V, a może mniej.

    Ja mierzę na atmedze 3,25V.

    Aha. Jak dołożyłem ten zewnętrzny kwarc, to nie wiedziałem jakie ustawić fusy: czy 3,6MHz to low/medium/czy high frequency, wybrałem medium i poszedł. Fusy FD D9.
  • #17 16990204
    kamyczek
    Poziom 38  
    Podłącz analizator np saleae koszt niecałe 50pln na "alledrogo" sprawdź prędkość jaką masz fizycznie wykluczymy problemy z fusami ,oscylatorem RC . Analizator pomoże w wielu sytuacjach więc warto go kupić . Moim zdaniem oscylator rc nie robi problemu tym bardziej przy małych prędkościach transmisji .
  • #18 16990211
    adam220
    Poziom 14  
    Mam saleae i oscyloskop...
    czy na prawdę mam sprawdzić czy kwarc ma tyle co na obudowie mu wygrawerowali?
    Czy o co innego Ci chodzi?
  • #19 16990213
    Kuniarz
    Moderator Projektowanie
    adam220 napisał:
    Pin Tx-owy atmegi i masa do złacza DB9,
    dalej chińska przejściówka RS232-USB i komputer.


    Piny TX i RX Atmegi to nie jest standard RS232, tylko UART. Nie możesz tego podłączyć do przejściówki RS232-USB tylko do przejściówki UART-USB.

    Dziękuję, to wszystko w temacie ;-)
    Pomogłem? Kup mi kawę.
  • #20 16990218
    adam220
    Poziom 14  
    Zrzut z terminala:

    Atmega8 Bascom Uart - Nieprawidłowe znaki na terminalu po użyciu PRINT

    Widać na nim odpowiedź Atmegi8 na taki kod:

    Kod: VB.net
    Zaloguj się, aby zobaczyć kod


    Dodano po 5 [minuty]:

    @Kuniarz
    przejściówkę toja określiłem w ten sposób "RS232"- może nieprawidłowy.
    To jest chińska no-name, znana jako CH340, ale używałem jej do PIC-ów.
    Myślę że UART w Atmedze to to samo.
  • #21 16990230
    Kuniarz
    Moderator Projektowanie
    adam220 napisał:
    przejściówkę toja określiłem w ten sposób "RS232"- może nieprawidłowy.
    To jest chińska no-name, znana jako CH340, ale używałem jej do PIC-ów.
    Myślę że UART w Atmedze to to samo.


    Dobrze, wykluczmy więc wpływ przejściówki - zewrzyj na niej RX z TX. To co napiszesz na terminalu musi przyjść z powrotem jako echo. Działa ?
    Pomogłem? Kup mi kawę.
  • #22 16990245
    krzysiek_krm
    Poziom 40  
    adam220 napisał:
    Zrzut z terminala:

    Atmega8 Bascom Uart - Nieprawidłowe znaki na terminalu po użyciu PRINT

    Widać na nim odpowiedź Atmegi8 na taki kod:

    Kod: VB.net
    Zaloguj się, aby zobaczyć kod


    Dodano po 5 [minuty]:

    @Kuniarz
    przejściówkę toja określiłem w ten sposób "RS232"- może nieprawidłowy.
    To jest chińska no-name, znana jako CH340, ale używałem jej do PIC-ów.
    Myślę że UART w Atmedze to to samo.

    Być może handshaking powinien być ustawiony na "none".
  • #23 16990247
    adam220
    Poziom 14  
    @Kuniarz
    po zwarciu pinów 2 i 3 na DB9 przejściówki jest poprawne echo bez przekłamań.
  • #24 16990248
    Kuniarz
    Moderator Projektowanie
    krzysiek_krm napisał:
    Być może handshaking powinien być ustawiony na "none".


    Faktycznie, nie zauważyłem, to może być to.
    Pomogłem? Kup mi kawę.
  • REKLAMA
  • #25 16990255
    adam220
    Poziom 14  
    @krzysiek_krm
    tak oczywiście handshaking był na none, ale w ramach poszukiwania magii sprawdzałem wszystkie ustawienia i tak zostało.
    Oczywiście komenda print w bascomie jest niewrażliwa na handshaking i atmega sypie znaki od razu.
    Chciałem powiedzieć: niezależnie od ustawień handshaking znaki przychodzą w rytmie programu Atmegi. Oczywiście złe znaki.
  • #26 16990297
    krzysiek_krm
    Poziom 40  
    Ja się w ogóle nie znam na Bascom-ie, ale z ciekawości rzuciłem okiem w jakąś przykładową dokumentację
    https://avrhelp.mcselec.com/index.html?uart.htm
    i w podanym przykładowym programie nie ma instrukcji konfigurowania pinu, która jest w Twoim programie, może ma to jakieś znaczenie ?
    Nawiasem mówiąc ten przykładowy program jest prosty jak drut, co tam właściwie może źle działać ?
  • #27 16990322
    adam220
    Poziom 14  
    @krzysiek_krm
    konfigurację pinu jako output dodałem jak mi nie chciało działać.

    Obecnie uprościłem kod do kilku 7 linii:

    Kod: VB.net
    Zaloguj się, aby zobaczyć kod

    i nie działa jak powienien

    Dodano po 52 [sekundy]:

    Pracuję na Lenovo, może to?

    Dodano po 2 [minuty]:

    Hmmm
    a może $regfile = "m8def.dat" <- ten plik jest zepsuty???
    Jak to sprawdzić?
  • #28 16990337
    krzysiek_krm
    Poziom 40  
    adam220 napisał:
    Mam saleae i oscyloskop...
    czy na prawdę mam sprawdzić czy kwarc ma tyle co na obudowie mu wygrawerowali?
    Czy o co innego Ci chodzi?

    Może faktycznie podłącz analizator i / lub oscyloskop do linii TX i zobacz co tam się naprawdę dzieje.
  • #29 16990402
    adam220
    Poziom 14  
    Podłączyłem oscyloskop...

    1) do oscylatora,
    częstotliwość 3,60-3,70MHz, czyli OK
    zrzut:



    Atmega8 Bascom Uart - Nieprawidłowe znaki na terminalu po użyciu PRINT

    2) do TX-a przy prędkości 1200 wysłano znak "a" bez znaków końca linii
    zrzut:



    Atmega8 Bascom Uart - Nieprawidłowe znaki na terminalu po użyciu PRINT

    Dodano po 21 [minuty]:

    2 kolejne znaki charakterystyczne - może ktoś pomoże zdekodować:
    1) znak zapytania czyli ASCII 63, czyli 111111 same jedynki
    zrzut
    Atmega8 Bascom Uart - Nieprawidłowe znaki na terminalu po użyciu PRINT
    2) znak U czyli ASCII 85 czyli 1010101 naprzemiennie
    zrzut
    Atmega8 Bascom Uart - Nieprawidłowe znaki na terminalu po użyciu PRINT
    Może coś nie tak z timingiem?
    Zdjęcia ostre tym razem działka to 1.0ms (użyto1200baud)

    Dodano po 22 [minuty]:

    @krzysiek_krm @Kuniarz @kamyczek
    co koledzy na to?
  • #30 16990600
    Jaca
    Poziom 31  
    Układ i przejściówkę zasilasz z tego samego źródła czy z oddzielnych ?
REKLAMA