Witajcie,

przychodzę z problemem, który meczy mnie od dłuższego czasu :/



Niebieskie piki do masy to dane przesyłane przez uart z komputera do mikrokontrolera, żółte, to piki które AVR uznaje jako poprawną transmisje.
Jak widać sporo błędów, jedna transmisja na 4 jest uznawana za poprawną... I to ten problem :/
Myślę, że to nie BaudRate, wprawdzie 16MHz, ale 76800.

Jak sprawdzam czy transmisja jest poprawna?
Oto co wysyłam:
Czyli wysyłam jeden bajt rozpoczynający - 85(% w ASCII) kod uint8_t R, G, B, i bajt kończący - '\n'.

I sprawdzam w kodzie AVR, czy bajt '%' jest w buforze odczytu na miejscu 0:

jak jest to spoko, jak nie to kicha.

No i ta kicha jest za często... tak o 4 razy za często, buforek mi się przekręca...

Jest to uart_getln(buforek,5); funkcja ta sczytuje 5 bajtów, lub do znaku nowej linii '\n'.

i chodzi o to, że bajt rozpoczynający w tym buforze jest raz na miejscu 0 raz na 1, 2, 3, 4 itd...
Przekręca mi się w buforze :/

Niby spoko, mogę sobie napisać by czytało wartości od bitu start w buforze na miejscu 1,2,3 zamiast 0, no i tak zrobiłem, podziałało, częstotliwość wykonywania wzrastała, ale ta funkcja odczytu danych zawsze usuwa po odczycie ostatni bajt buforu na 0 albo null, więc jak mam na 3 miejscu w buforze bajt rozpoczynający (%) to na 5 mam uint8_t R, a dalej 0 czyli tylko zmienna R jest użyteczna :/

No myślałem że funkcję odczytu napisać od nowa, ale... Zwrot akcji - uwaga, zaprogramowałem sobie inny uC jako przekaźnik uart, miał w sobie funkcję:

Robił tylko to, w kółko, bez jakiegoś _delay_ms, w prawdzie, wysyłał naet NULL'e, przez co uart w mikrokontrolerze był aktywny non stop, ale szybko działał więc spoko, i się okazało, że miałem prawie 100% odczytanych danych z PC poprawnie - LOL, jak?

Jeszcze raz, dane szły tak :
PC >> uC[uart_putc(uart_getc());] >> uC[Wykonywany kod X] - w takiej konfiguracji działało bez problemu...
PC >> uC[Wykonywany kod X] - już tylko co 4 string jest okej :/

Co jest grane? :/
Pozdrawiam serdecznie internautów

Po pierwsze to nie powinieneś przesyłać danych binarnie, tak jak robisz to w przypadku zmiennych R, G i B tylko przez kod ASCII (zamieniasz bajty na HEX-y i wysyłasz), być może to nie jest główna przyczyna problemu, ale na pewno warto sprawdzić.
Po drugie możesz wstawić kod funkcji uart_getln, może tam tkwi błąd

Ale biblioteka która np działa w ASCII już może narzucać takie ograniczenie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dlaczego? toż to marnowanie 8'mio bitowej transmisji, każdy znak znak z '2''4''5' ma 8 bitów, a tak mam tylko 8 bitów więc po co ?

To się zorientuj najpierw czym różni się transmisja binarna od transmisji ASCII ... a po tej procedurze widać, że takiej używasz - a więc nie dziwota że co to świruje gdy binarkę ślesz

Pomyśl chwilę, jeśli wartość twojego wysyłanego bajtu będzie równa w pewnym momencie 13 .... a twoja funkcja czeka na znak końca linii 13 (ENTER) ... bo przygotowana jest do obsługi ASCII to co się stanie ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Co prawda w jednym z testowych projektów z przed paru lat też przesyłałem binarnie zamiast ascii, ale wcześniej przerobiłem odpowiednio bibliotekę do swoich potrzeb i gnało to bez błędów jak należy. Zależało mi na szybkiej transmisji sporej ilości danych i szybkim odświeżaniu. Jest to więc możliwe, ale bez przeróbki się nie obejdzie, poza tym może masz jakieś zakłócenia po drodze.

_________________
http://www.sylwekkuna.com

Dlatego się zabezpieczam programowo na PC:



no i ta teoria była by poprawna gdyby przesłanie przez inny mikrokontroler [PC>>uC>>uC(docelowe)] nie eliminowało problemu, a w tedy ten problem nie istnieje.

Może bufor nie zawsze jest pusty, a wysłanie pustej ramki na uart jakoś to resetuje, spróbuję po przesyłać z komputera jakieś puste ramki.

jak już to CH340 >> uC, ale na pinie RX od uC ramka wygląda bardzo dobrze, wyślę oscylogram, za jakiś moment,

EDIT:

Niebieski, pod RX, żółty pod diodę, na płytce arduino nano.
Żółty załącza się w momencie gdy:

i trwa do ponownego odczytu uart:


No i oscylogram z tej ramki którą złapał:

Znalazłem błąd:
Po pierwsze, tablica była za mała o jeden bajt, znaczy była okej, ale jak się znalazł błąd o jeden bit, to całość się "przekręcała", tak samo jak '\n', przez co znowu funkcja odczytu kończyła się ciupke za szybko (o jeden bajt) i tablica była niepełna, przez co się "przekręcała" i tak aż się to zsynchronizowało. Czyli aż funkcja zdążyła złapać '\n' na innej pozycji - działo się to około 4 iteracje.

Po drugie, błąd delikatnie wynikał z funkcji, ale to nie był największy problem, chyba troszkę zawinił program na komputerze, czasami zdarzało mu się wysłać o jeden bajt za dużo, albo za mało, dzieje się to przy "połączeniu" z CH340, przez co ramki w buforze od razu startują przesunięte. No a funkcja po prostu nadpisywała bufor, jak sczytała 3 bity a 4 to '\n' to tylko 4 bity nadpisywała, nie 5.

Oba te błędy powodowały że nie byłem w stanie ich wykryć, bo jak po omacku naprawiałem jeden to drugi powodował że dalej nie działało, albo działało przez sekundę, a ja myśląc, że to nie to, się cofałem i szukałem gdzie indziej...

Teraz dopisałem parę zmian...
Pierwsza to większy bufor, przez co '\n' w przypadku błędu nie wskakuje na pierwszą pozycję buforu, tylko na ostatnią i funkcja ma szanse się "wybronić". Druga to czyszczenie "ręczne" buforu po otrzymaniu danych i przetworzeniu, by czasami za mała ilość bajtów odebranych nie przekręcała mi buforu. Ale tak czy siak się to czasami zdarza z jakiejś przyczyny, ale jest to tak z 1 na 500 odczytów, ale częstotliwość wysyłania to czasami 60Hz więc i tak względnie często wciskały się błędy... Więc gdy wartość "%" - moja wartość startowa ramki, jest nie tam gdzie powinna, program synchronizuje "strumień danych" z buforem, robi to przez zmniejszenie chwilowe wielkości bufora odczytanego, przez co zmienne w nim się zaczynają przekręcać na pozycjach, i gdy te będą na właściwych miejscach, ponownie rozmiar bufora jest ustawiany na standardowy.

I tyle, teraz mam 99% ramek przesłanych poprawnie, można by powiedzieć że mało, ale w moim wypadku wystarczająco.

Dziękuję wszystkim, i każdemu z osobna, za pomoc, jakoś się udało