Witam,
Mam mały problem Używam atmegi 32 , listwy ledowej ws2812 60 diod, oraz wykorzystuję uart do odbioru danych z komputera.
Zanim zacznę tłumaczyć co się dzieje parę linijek kodu:
main.c

oraz w przerwaniu ISR( USART_RXC_vect )

dodatkowo w pliku mkuart.c :

oraz mkuart.h


Wszystkie biblioteki mistrza ramka wygląda następująco " $123#123#123#123#123#123#* "

Wszystko ładnie działa, zmiana danych w ramce zmienia kolory na taśmie, ale.. po paru sekundach diody przestają świecić jak powinny i zaczyna się meksyk na diodach listwy, czasem trwa to pół sekundy czasem 10 sek i troszkę smutno

Atmega napędzana z kwarcu 12MHz (fusy przestawione), prędkość transmisji 9600 (przy 38400 to samo), do komunikacji używam PL2303, czy dane wysyłam z konsoli czy z programu PC jest jedna chwała, i tak po pewnym czasie to samo.

Docelowo będę chciał używać o wiele większej ramki (22 razy większej więc mile widziane jakieś sugestie), oraz chciałbym to robić z możliwie największą prędkością.

i tu moje pytanie, czym to może być spowodowane ?

Prawie wszystkim co robisz odnośnie obsługi RS232 niestety .... po prostu masakra na każdym etapie komunikacji

- począwszy od egzotycznego taktowania 12 MHz ( pomimo tego że już od Bluebooka wspominam o kwarcach przyjaznych RS232)
- poprzez - co już jest tragedią obsługę przerwania (bez żadnego buforowania) ... a znowu wspomnę, że w Bluebooku kładę duży nacisk aby to zrozumieć i korzystać
- aż po to co się dzieje w pętli głównej programu - to już jest katastrofa - armagedon niestety


jeśli jest jakiś większy disaster niż armagedon to pewnie to właśnie zobaczysz przy takim podejściu wtedy


Dlatego napisałem wyżej analizę tego co przedstawiłeś - a sugestia ?

jest oczywiście - zacznij od początku komunikację RS232, od PODSTAW z Bluebooka - przede wszystkim buforowanie (bufory cykliczne) i komunikacja ASCII bo taka tu wystarczy ... Jedyne co będziesz musiał sobie dopracować nie mając Greenboka to odbieranie stringów .... No chyba że masz też Greenbooka - to tam masz wszystko jak odbierać stringi ale nie tylko - tam jest coś znacznie ważniejszego - jak odbierać i parsować te stringi w oparciu o ZDARZENIA ! .... Przy podejściu z Greenbooka okaże się nie tylko, że kod ci się nagle uprości o 99% i uporządkuje to jeszcze będzie działać niezawodnie - pewnie nawet przy 9600 jeśli nie robisz ekranu telewizyjnego z odświeżaniem 30 fps

_________________
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 ]

- kwarc mogę zmienić na 20Mhz, i według noty błąd 0.2%
- z tego co widziałem to ludzie odbierają tak dane w projektach GPS (to samo co do pętli głównej tyle że niektórzy zamykają to w funkcje czy event'y), ale ok, postaram się poczytać więcej na ten temat i napisać jakiś nowy kod ponownie.

co do ekranu telewizyjnego to prawie strzał w dziesiątkę

Ty lepiej zajrzyj do pierwszej lepszej noty PDF dowolnego procka AVR, wejdź na ostatnią stronę rozdziału UART i tam są tabelki. Poprzeglądaj je i sprawdź sobie dla jakich częstotliwości taktowania prawie wszystkie albo wszystkie pola "Procent błędu" mają wartość = 0 .... i wtedy może zrozumiesz o czym ci pisałem wyżej


No no - to nawet nie ma o czym mówić skoro ludzie tak odbierają - to powodzenia

_________________
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 ]

z tego co wiem to najmniejszy procent błędów jest przy kwarcach np. 18.4320MHz czyli "z ogonkami" że się tak wyrażę bo nie wiem jak się to fachowo nazywa( bodajże zeragarowe ).

Takie kwarce określa się mianem "przyjaznych RS232"

Na prawdę polecam ci poczytaj Bluebooka piszę tam i o tym i opisuję właśnie to buforowanie cykliczne itp - zobaczysz jak się do tego podchodzi prawidłowo ....

_________________
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 ]

Kupiłem bluebook'a i przeczytałem to o czym Pan mówił. Parę rzeczy się rozjaśniło, parę rzeczy wiedziałem ale do rzeczy.
Obecnie czekam na przyjazny kwarc RSowi ale "tymczasowo" program działa.
Napisałem nowy program:


Dla sprostowania tak wygląda część przerwania ISR( USART_RXC_vect )


Aktualnie wszystko fajnie odbiera i wyświetla. Parsowanie ramki napisałem sam za pomocą wiedzy z internetu gdyż nie wyrobię z $ aby kupić greenbook'a dlatego jeżeli jest coś co powinienem wiedzieć to słucham

I teraz, z tego co liczę ciężko mi będzie wyrobić się z pamięcią FLASH aby odebrać całą ramkę wielkości 541 znaków (liczby i znaki oddzielające) sparsować przypisać do ws_rgb_leds i puścić na taśmę.

W zamyśle mam zamiar np. wysyłać z mikrokontrolera 1 do komputera, komputer odczytuje 1 i wysyła 1 część całej ramki, mikrokontroler odbiera ramkę, dzieli i przypisuje do tablicy, następnie mikrokontroler wysyła 2 do komuptera i tak w kółko aż do 45 ostatniej części ramki, po odebraniu i podzieleniu następuje wysyłanie do konkretnych taśm, konkretnych kolorów, i od początku cały proces. Tylko mam dziwne przeczucie że zgranie tego wszystkiego dość drastycznie przełoży mi się na czas realizacji 1 całego cyklu. Czy może lepiej było by zainteresować się jakąś pamięcią zewnętrzną np. karta SD?