Jak unikać problemów z komunikacją procesorów Atmega przy -20 st. C bez kwarcu?

Sat Nov 09, 2013 12:32 am   

....albo będziecie mieli takie kłopoty jak ja...

Okazuje się, że nadmierne zaufanie do dataszitów połączone z optymizmem
mści się okrutnie. Otóż taka jest historia ;

W urządziu, którego sercem jest Atmega128 napędzana kwarcem,
dodałem - w kolejnej wersji - drugi procesor (Atmega8).
Skomunikowane są ze sobą via RS232.

No i fajnie - niby wszystko działa. Do czasu.
Otóż, w Atmega8 użyłem wewnętrzenego generatora RC 8MHz.
I - okazuje się, że w temperaturze -20 st , szybkość tego generatora
wzrasta tak, że całą komunikację szeregową szlag trafia, i procesory
przestają się widzieć.

Wg. dataszita, w temperaturze -20 st. powinienem mieć ok. 8.2Mhz,
zamiast defaultowych 8Mhz w temp. pokojowej.
Ale - niestety wygląda na to, że to jest faktycznie 8.5Mhz, albo coś
koło tego. No, tak czy siak, żadna kombinacja ze zmniejszaniem szybkości
transmisji, spowalnianiem zegara itp. nie dają efektu.

Po ochłodzeniu urządzenia prędkości się rozjeżdżają i dupa blada.
Znaczy, Atmega128 na kwarcu trzyma się ok, a Atmega8 zaczyna bredzić...

I teraz muszę w kilkudziesięciu urządzeniach wstawiać ten cholerny
kwarc... I żebym to z oszczędności go nie dał. Ale nie - po prostu
nie przyszło mi do głowy, że ten wewnętrzny generator jest całkiem do d...

Sat Nov 09, 2013 12:57 am   

On 09.11.2013 00:32, sundayman wrote:


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"?

--
Mirek.

Sat Nov 09, 2013 1:47 am   

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.

Sat Nov 09, 2013 8:55 am   

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.

Sat Nov 09, 2013 10:16 am   

On 2013-11-09 00:32, sundayman wrote:

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.

Sat Nov 09, 2013 10:21 am   

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...

Sat Nov 09, 2013 10:53 am   

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.

Sat Nov 09, 2013 11:15 am   

On Sat, 09 Nov 2013 01:47:44 +0100, sundayman
<sundayman@poczta.onet.pl> wrote:

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

--
Marek

Sat Nov 09, 2013 12:03 pm   

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

Sat Nov 09, 2013 12:12 pm   

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

Sat Nov 09, 2013 12:59 pm   

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

mierząc długość bitu w transmisji przychodzącej.
P.G.

Sat Nov 09, 2013 1:51 pm   

Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w wiadomości
news:l5jsfc$q3j$1@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.

Sat Nov 09, 2013 6:32 pm   

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.

Sat Nov 09, 2013 6:57 pm   

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

Sat Nov 09, 2013 8:41 pm   

On 09.11.2013 18:57, Dariusz Dorochowicz wrote:


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.

--
Mirek.