używajcie kwarców !

Akurat mam podobny problem - jeden procek to atmega8 bez kwarcu, drugi ... nie mam na niego wpływu, bo to płytka z linux embedded. Wszytko działa, ale powiedzmy raz na godzinę, dwie... czasem potrafi i dobę pochodzić bez problemów - są pojedyncze braki w transmisji tzn. od strony linuxa wygląda to na "zjadanie" bajtów, przy czym zwykle występuje seryjnie - zjada klika pod rząd albo jeden... potem kilka prawidłowych i znów kilka zjedzonych. Transmisja odbywa się kilka razy na minutę, więc błędów to będzie jakiś ułamek procenta... Ale to wygląda raczej na zakłócenia? Tak czy inaczej - czy generalnie zasadą jest w przypadku procek - procek via rs-232 (w jednym urządzeniu, nawet ja jednej płytce) - stosowanie protokołu typu: "nie zrozumiałem, powtórz"?

Jak oba procesory mają kwarc, to w zakresie temperatur -25 / + 25 ( w górę jeszcze nie sprawdzałem), wszystko śmiga bezbłędnie. Nawet się zastanawiałem, czy w programie robić "powtórzenia", ale na razie, z braku czasu, zaniechałem, i wszystko jest "a vista". I działa.

A bez kwarcu na Atmedze, jak już pisałem - dupa blada, i żadne powtarzanie nie pomoże, bo niby jak, skoro się nie dogadują sprzętowo prędkości. Można by niby zrobić negocjowanie prędkości - żeby "przejechać" i zobaczyć, na której działa. W moim przypadku to było oryginalnie 38400, a w tej -20st. to się okazuje, że 40800 :)

No, ale to już są jaja, na które sobie nie mogę pozwolić. Więc kuśwa teraz przytykanie g.... do twarogu mnie czeka. Rozkręcanie i lutowanie tych kwarców... No żesz kuśwa.

W dniu 2013-11-09 00:32, sundayman pisze:

Te¿ kiedy¶ mia³em podobny pomys³, jednak podszed³em sceptycznie do tego co pisz± w dataszicie (jak siê okazuje na moje szczê¶cie) i od dawna mam zasadê: tam gdzie jest transmisja asynchroniczna zawsze musi byæ kwarc.

I to znakomity powód na przysz³o¶æ aby dorzuciæ wspólny zegarek dla obu. Czy przypadkiem to nie wystarczy³oby (drut z jednego XTAL do drugiego XTAL)?

Dziwne, problem jest raczej rozwi±zywalny w software jesli *faktycznie* to ten problem.

W dniu 2013-11-09 01:47, sundayman pisze:

Mo¿esz jeszcze rozwa¿yæ kalibracje ATmegi8 z pomoc± tej z kwarcem. Zawsze pro¶ciej wymieniæ soft ni¿ przerabiaæ ile¶ tam p³ytek...

Dnia Sat, 09 Nov 2013 00:32:20 +0100, sundayman napisa³(a):

Jest jeszcze wersja ze drugi procek karmisz zegarem z pierwszego.

A nie przyszlo ci do glowy ze w szrodku nie ma nic co moze dokladne czestotliwosci trzymac ? Tylko krzem.

P.S. Kwarc to w sumie tez tylko tlenek krzemu, masowo stosowany w ukladach scalonych :-)

J.

lutowanie

A Atmega nie ma rejestru kalibracji wew. osc.? Ewentualnie ten drugi mcu z kwarcem nie mógłby pożyczyć swojego zegara?

W dniu 09.11.2013 11:15, Marek pisze:

Ma i można go bardzo fajnie do tego celu wykorzystać. W swoich konstrukcjach gdzie spokojnie gadały po RS-ie dwie ATmegi bez kwarców robiłem tak, że uC inicjujący transmisję wysyłał preambułę z kilku bajtów 0xAA lub 0x55 (czyli generował kawałek fali prostokątnej). uC który odbierał wykorzystywał preambułę do wykalibrowania swojego oscylatora RC tak aby prędkośći się zgrały. Bo w sumie często nie ważne jest aby transmisja była dokładnie np. 19200bps, a żeby w nadajniku i odbiorniku była taka sama.

Pozdrawiam Grzegorz

W dniu 2013-11-09 01:47, sundayman pisze:

No to jeszcze pytanie ile danych tam przerzucasz i jak bardzo możesz dociążyć kontrolerki. Bo może wystarczy zmienić protokół na odpowiedniejszy? Np typu PWM (to się nawet jakoś nazywa, ale nie o tej porze dnia i tygodnia) - szerokość impulsu decyduje o wartości. Możesz dać na tyle duże różnice szerokości, żeby nie było problemu z rozsynchronizowaniem zegarów.

Pozdrawiam

DD

Użytkownik "sundayman" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:l5jsfc$q3j$ snipped-for-privacy@node1.news.atman.pl...

Jest jeszcze taka możliwość, że jeden dopasowuje swoją prędkość do drugiego mierząc długość bitu w transmisji przychodzącej. P.G.

Użytkownik "sundayman" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:l5jsfc$q3j$ snipped-for-privacy@node1.news.atman.pl...

Twoje twierdzenia tak dalece odbiegają od tego co według mojej pamięci wynikało z dataschita że postanowiłem sprawdzić czy mam aż taką sklerozę, czy może Atmel coś poprawił. W ostatniej karcie katalogowej Atmega 8 jaką miałem u siebie (z 2007 roku) jest jak pamiętam. No to pobrałem aktualną kartę katalogową 02/2013. Według mnie w tym temacie nic się nie zmieniło. Na stronie 30 jest , że jak przepiszesz calibration byte do OSCCAL to masz skalibrowaną częstotliwość z dokładnością 3% (VCC=5V, t=25 st) (dla 8M to jest 7,76 do 8,24). Z figure 170 (str 270) wynika, że przy -20 st. f jest o jakieś 0,225M większa niż przy 25 st (czyli mamy 7,985 do 8,465). Z figure 171 wynika, że czułość f na odchyłki VCC to jakieś 0,2M/1V. Typowe stabilizatory mają 4%, lepsze 2% dokładności (w temperaturze 25 st). Zakładając, że masz ten 4% czyli VCC od 4,8 do 5,2V to daje możliwość dodatkowej odchyłki w obie strony o 0,04M czyli mamy już 7,945 do 8,505 Należało by jeszcze sprawdzić zmiany VCC w funkcji temperatury, ale nie mam pojęcia jaki stabilizator zastosowałeś.

Relację łączącą Ciebie z kartą katalogową zdecydowanie nie nazwałbym "nadmiernym zaufaniem".

Ja przyjmuję, że 2,5% to maksymalna różnica wzorców częstotliwości komunikujących się ze sobą RS232 urządzeń. Nawet mając pewność, że urządzenie będzie pracowało w 25 st. nie zaakceptowałbym tego calibrated RC oscillator bo ma 3%. Chyba, że stosując run-time calibration (wspomniane na stronie 30) dające dokładność 1%. P.G.

Dnia Sat, 09 Nov 2013 12:12:16 +0100, Dariusz Dorochowicz napisał(a):

Uzyc cztery czy dwa bity w bajcie i tez bedzie lepiej :-)

J.

W dniu 2013-11-09 18:32, J.F. pisze:

Kwestia bitów startu, stopu... Tu chyba byłby problem tak czy siak. Nawet za bardzo nie wiem jak by działał układ po ustawieniu dwóch bitów stopu, a startu chyba i tak nie zmienisz, a i skutek niekoniecznie musi być pozytywny. Szczerze mówiąc nie doczytywałem się jak działa UART w AVR i jak tam wygląda próbkowanie bitów, ale generalnie transmisja tego typu jest zwyczajnie wrażliwa na rozsynchronizowanie zegarów i im dłuższe transmisje tym gorzej to działa. Ktoś już pisał - to się potrafi od czasu do czasu zsynchronizować, ale przez większość czasu zwyczajnie stoi.

Pozdrawiam

DD

Teoretycznie dobry uart synchronizuje się wraz z każdym zboczem - właściwie nie powinno być żadnych problemów o ile nie ma bardzo krótkookresowej niestabilności. Zakładając najgorszy przypadek, czyli jakieś 10 bitów jednakowych, to problem może stwarzać dopiero przesunięcie 10-tego o połowę długości*. Oczywiście niestety projektant mógł sobie założyć, że dla danej prędkości nie tolerujemy dłuższego i krótszego bitu niż ... bo nie. Stare modemy zewnętrzne zawsze rozumiały co się do nich mówi - na dowolnie ustawionej transmisji i odpowiadały na takiej samej. Ale to podobno działało dobrze dlatego, że pierwszymi znakami były "AT" lub "at" i to po nich rozpoznawało się parametry transmisji.

• - no tak, wygląda na to, że wszystko się zgadza i dla 8MHz 8,4 juz przesuwa ten ostatni bit o połowę. Trzeba by jeszcze sprawdzić co się dzieje jeśli unikamy bajtów z jednakowymi po sobie bitami.

No więc tak;

Zasilanie jest z LM2675M-5.0 , na MCU mam 4.98V. Testowo zrobiłem tak ;

obniżyłem zegar Atmega8 do 1MHz, a prędkość uart do 4800. I w temperaturze -25 st. jak dotąd się widzą.

No ale już zdecydowałem, że jednak dołożę ten cholerny kwarc - nie mam już zaufania do tego :) Ponadto, nawet jeśli jest dobrze przy -25, to na pewno niżej przestanie być dobrze. A cholera wie, jaka będzie zima :)

Tak czy siak, i tak muszę otworzyć obudowę, przeprogramować oba procesory, więc różnica roboty niewielka, a będzie lepiej.

Pomysł z taktowaniem Atmegi8 z Atmegi128 rozważałem, ale to jeszcze gorzej, bo procesory są na różnych PCB połączonych "tasiemką", więc to dodatkowy kabelek itp. Łatwiej przylutować ten kwarc. Poza tym - jednak bezpieczniej jest, żeby każdy mcu pracował samodzielnie, bo one są 2, żeby jeden pilnował drugiego :)

Zmiana protokołu itp - to imho też będzie więcej zabawy niż lutowanie tego kwarcu. Niechętnie zresztą bym teraz wprowadzał istotne zmiany w programie, bo nie mam czasu na długotrwałe testy po zmianach (urządzenia już są częściowo zainstalowane).

No niestety, sam jestem sobie winien. Nawet dla "zasady" powinienem dać ten kwarc. Albo chociaż kuśwa zrobić miejsce dla niego ! Ale coś mi się ubrdało, że będzie dobrze.

No niestety, człowiek się uczy na błędach ;

testować urządzenie NA WSZYSTKO nawet jak wydaje się, że działa ! testować urządzenie NA WSZYSTKO nawet jak wydaje się, że działa ! testować urządzenie NA WSZYSTKO nawet jak wydaje się, że działa ! ... i tak dalej - przepisać 100 razy !

W dniu 2013-11-09 20:41, Mirek pisze:

Tak bardzo teoretycznie to może. Fakt, że bardzo dawno już nie przyglądałem się UARTom, ale wszystkie, które ileś lat temu widziałem, nie reagowały na zbocza, tylko na poziom, a dokładniej kilka razy na przewidywaną szerokość bitu próbkowały stan linii (bodaj dwie na trzy próbki dawały wartość bitu). Nie bardzo nawet sobie wyobrażam powód, żeby dodatkowo komplikować sobie układ, który i tak jest dość skomplikowany, i na dodatek po prostu działa pod warunkiem zachowania właściwych tolerancji zegara.

MSZ wniosek bez podstaw, ale oczywiście mogę czegoś nie wiedzieć, a nie bardzo mam teraz ochotę wczytywać się w opisy UARTów. Jak coś wiesz konkretnego, to daj znać.

Pozdrawiam

DD

Dobrze sprawdza się Manchester. 01 oznacza jeden stan, 10 drugi.

Użytkownik "Dariusz Dorochowicz" <_dadoro snipped-for-privacy@wp.com napisał w wiadomości news:l5lt1n$sl8$ snipped-for-privacy@node2.news.atman.pl...

Nie widzę powodów do problemu. Kolejne bity są próbkowane w coraz błędniej dobranym środku bitu. Jeśli tylko 4 byłyby ważne to dopuszczalne rozsynchronizowanie będzie 2 razy większe niż przy wykorzystaniu 8 bitów. Pozostałe 4 na jedynkę i między nadawaniem kolejnych bajtów można jeszcze odczekać chwilę na wypadek, gdy to my nadajemy za szybko. P.G.

Dyskusja zmierza w kierunku rozwiązywania problemów nieistniejących w innych systemach :-) - pytanie do autora czemu konieczne użył uart"a zamiast np. spi?