Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
news:l5jsfc$q3j$1@node1.news.atman.pl...
> 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...
>
Jest jeszcze taka możliwość, że jeden dopasowuje swoją prędkość do drugiego
mierząc długość bitu w transmisji przychodzącej.
P.G.

do góry

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

> Okazuje się, że nadmierne zaufanie do dataszitów połączone z optymizmem
> mści się okrutnie. Otóż taka jest historia ;
> [....]
> Wg. dataszita, w temperaturze -20 st. powinienem mieć ok. 8.2Mhz, zamiast
> defaultowych 8Mhz w temp. pokojowej.

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.

do góry

Dnia Sat, 09 Nov 2013 12:12:16 +0100, Dariusz Dorochowicz napisał(a):
> 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.

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

J.

do góry

W dniu 2013-11-09 18:32, J.F. pisze:
> Dnia Sat, 09 Nov 2013 12:12:16 +0100, Dariusz Dorochowicz napisał(a):
>> 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.
>
> Uzyc cztery czy dwa bity w bajcie i tez bedzie lepiej :-)

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

do góry

On 09.11.2013 18:57, Dariusz Dorochowicz wrote:

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

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.

do góry

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

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 !

do góry

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

> Teoretycznie dobry uart synchronizuje się wraz z każdym zboczem -

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.

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

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

do góry

Dariusz Dorochowicz <_...@w...com> wrote:

> Np typu PWM (to się nawet jakoś nazywa, ale nie o tej porze dnia i
> tygodnia) - szerokość impulsu decyduje o wartości.

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

--
"zanim nastala era internetu, kazdy wiejski glupek siedzial w swojej wiosce"
http://www.chmurka.net/

do góry

Użytkownik "Dariusz Dorochowicz" <_...@w...com> napisał w wiadomości
news:l5lt1n$sl8$1@node2.news.atman.pl...
>>
>> Uzyc cztery czy dwa bity w bajcie i tez bedzie lepiej :-)
>
> Kwestia bitów startu, stopu... Tu chyba byłby problem tak czy siak.

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.

do góry

On Tue, 12 Nov 2013 12:09:16 +0100, Piotr
Gałka<p...@c...pl> wrote:
> Nie widzę powodów do problemu.
> Kolejne bity są próbkowane w coraz błędniej dobranym środku bitu.

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?

--
Marek

do góry