działa, ale nie do końca

8.5% / 3.5% błędu przy tej prędkości i kwarcu 8MHz, czyli najwyższy możliwy jaki się tylko dało przy tej prędkości :).

Higher error ratings are acceptable, but the Receiver will have less noise resistance when the error ratings are high, especially for large serial frames

Zerknij sobie w tabelki 53 i 54 w pdfie:

Być może powinieneś zacząć od zmiany kwarcu na jakiś uartowy żeby wyeliminować ten problem.

W dniu 2012-12-30 21:02, Jakub Rakus pisze:

Zamienić 8MHz na 11.059MHz.

Pozdrawiam, Paweł

W dniu 2012-12-30 21:02, Jakub Rakus pisze:

Oczywiście. Przy tym kwarcu i tej prędkości - nie jesteś w stanie ustawić prawidłowo timera taktującego uart, tak by w prędkość się idealnie wstrzelić - błąd jest na tyle spory, że po kilkunastu bajtach kolejne już nie trafiają w swoje "okna czasowe" i się rozjeżdża treść.

Zmień kwarc lub prędkość transmisji, tu masz ładną ściągę:

W dniu 30.12.2012 21:12, Sebastian Biały pisze:

Oooo, wstyd, patrzyłem na te tabelki, wydawało mi się że te kilka procent to nie powinno robić takiego syfu, ale tego zdania o długich ramkach jakoś nie doczytałem. To może dużo wyjaśniać, jak dorwę jutro jakiś bardziej odpowiedni kwarc to obadam.

Jakub Rakus snipped-for-privacy@op.pl napisał(a):

Pamiętaj, że pod względem wielkości błędu lepszy kwarc to nie kwarc szybszy, tylko ten, którego częstotliwość ładnie dzieli się przez prędkość transmisji. Dlatego bardzo lubię kwarce 3686400 Hz.

Nigdy z atmega nic nie robilem, tylko PIC, ale nie da się w atmedze używać usarta z wew. oscylatorem? To ma być jakieś zegarek, że kwarc wymagany? Dla niektórych to co teraz powiem to herezja, ale ja z picami nigdy kwarca nie używałem, a większość urządzeń jakie robilem komunikuja się że sobą przez usart (inny mcu, PC, moduly gsm, mcu z usb na wew. osc.) i nigdy żadnych problemow (przekłamań) komunikacyjnych nie miałem. Ba, nawet kiedys popełniłem moduł komfortu na CANie do samochodu kolegi, zaprojektowany owszem z kwarcem, ale rok temu potajemnie koledze wyłączylem kwarc w module przełączając mcu na wew. oscylator, tak z ciekawości czy będzie coś się działo. I nic, rok już jeździ z tym modulem i żadnych problemow nie zauważył (i zima przy

-20 i latem przy 30) więc, po co komu kwarc? ;) Nie wierzę, że ten problem z usartem związany jest z kwarcem, no chyba ze wlasnie problem w tym, że zostal użyty;).

A tak ja poważnie, to chętnie bym się przyjrzał dyskusji na temat zasadnosci stosowania kwarca w projektach hobistyczno-polprofesjonalnych. Nawet sam Microchip w serii J np.18f25j50 podpial wew. oscylator do taktowania USB jako jedna z opcji (poprzednie wersje 2550 wymagały kwarca, jeśli chciało się użyć usb bo wew. oscylator nie mógł taktowac usb), więc można. I faktycznie w J działa usb bez problemu na wew. osc.

W dniu 31.12.2012 14:11, Marek pisze:

Tylko z tego co kojarzę układ "przygotowania" i rozprowadzania sygnału zegarowego w PICkach ;) jest trochę inny od tego w AVR - IMHO pewniejszy, dokładniejszy i bardziej "elastyczny" dla użytkownika.

W datasheetach PICkow w większości przypadków (nie kojarzę w tej chwili innych wartości) podawane jest dokładność wew. oscylatora 1%. Ale jestem zdziwiony, że atmega różni się "technologicznie", dotąd i atmegi i picki traktowałem jako konkurencyjne procesory: oba tak samo dobre.

W dniu 30.12.2012 21:30, Grzegorz Niemirowski pisze:

Wypróbowałem dzisiaj kwarce 11,0592 i 14,7456. Z tym 11,0592 jest tragicznie, prawie same błędy. Przy 14,7456 jest tak samo jak było do tej pory, pierwsze kilkanaście bajtów jest w porządku, potem się wszystko rozjeżdża.

Tu nie chodzi o dokłądność oscylatora. Chodzi o to, że do taktowania UARTu musisz ustawić dzielnik (a w zasadzie wartość startową licznika). Ustawić do jego rejestru możesz wszystko z zakresu 0-255, i dla niektórych ustawień - nijak nie wychodzi równy podział, bo np wpis 4 = o wiele za szybko, a wpis 5 - już znacznie za wolno...

Jakub Rakus snipped-for-privacy@op.pl napisał(a):

Więc to nie jest wina kwarca. Sprawdź fusebity, czy ta ATmega z tego kwarca w ogóle korzysta. Pokaż też kod odpowiedzialny a UART. Albo go źle inicjalizujesz albo źle obsługujesz nadchodzące dane, np. przepełnia Ci się bufor.

Ale przecież bgr ze swoimi dzielnikami musi umożliwić prawidłowa częstotliwość taktowania dla częstotliwości dla jakich mcu został zaprojektowany lub częstości zalecanych. Czy nie wystarczy użyć kwarcu na częstotliwość taka dla jakiej znajdziemy odpowiedni dzielnik dla bgr dla oczekiwanej prędkości usarta?

Użytkownik "Jakub Rakus" snipped-for-privacy@op.pl napisał w wiadomości news:kbq6kf$6nh$ snipped-for-privacy@node2.news.atman.pl...

Oprócz wymiany kwarca na taki, którego częstotliwość dzieli się łatwo przez

115200Hz, spróbuj wysyłać bajty z dwoma bitami stopu zamiast jednym. To pozwoli odbiornikowi łatwiej złapać synchronizację (odbiornik jak najbardziej może mieć ustawiony 1 bit stopu dla odbioru). Pamiętaj też o tym że wybraleś dość szybką transmisję i kolejny bajt pojawia się co około 87us, więc może procedury "nie wyrabiają".

a) nie zapomniales o masie ?

b) wina softu. robisz przerwania czy w petli?

no to spróbuj wstawić generator zamiast kwarcu i sprawdź...

Dla dowolnych? Niestety, ale nie. Dowolna to od 0 do np 16MHz, ale dzielnik (licznik) da się tylko dla niektórych par (prędkość bps,kwarc) dobrać idealnie, dla niektórych w granicach błędu, a dla niektórych nie da się.

W dniu 01.01.2013 13:43, Sebastian Biały pisze:

Nie. Masy są połączone.

Całość mam napisane w Bascomie. Program działa tak, że wysyłam z mcu jeden bajt (komenda żądania konkretnych danych), a następnie kilkadziesiąt razy powtarza się sekwencja: wysłanie bajtu o wartości FF na co urządzenie odpowiada mi kolejnym pojedynczym bajtem danych. Całość wykonuje się w pętli umieszczonej w pętli głównej programu. W tzw. międzyczasie mcu obsługuje dwa kanały ADC (obsługa w przerwaniu timer0) i zespół wyświetlaczy 7seg (obsługa w przerwaniu timer1 - zespół ma swoją "logikę" i wysyła się mu liczbę do wyświetlenia, numer wyświetlacza, a potem zatrzaskuje). Na czas wysyłania uart-em bajtu FF i odbioru bajtu profilaktycznie wyłączam przerwania, ale zauważyłem że nie ma to wpływu na komunikację.

Jak sprawdzasz podczas wyslania, ze wolno już zapisac nowe dane do UDR? Czekasz na odbiór i wtedy wysylasz ? Morze podziel sie petla komunikacyjna.

Jak na jakosc wplynie wstawienie opoznienia podczas wysylania pomiedzy znakami?

Podczas odczytu sprawdz bity Frame Error i Data OverRun i wystaw na jakies ledy w celu upewnienia sie czy to wina hard czy software.

Oczywiście ze nie dla dowolnych, po prostu nie rozumiem czemu po prostu nie użyć kwarcu dla którego uzyska sie oczekiwana prędkość usarta z jak najmniejsza stopa błędów.