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

Sat Nov 09, 2013 9:40 pm   

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 !

Mon Nov 11, 2013 9:02 pm   

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

Tue Nov 12, 2013 12:09 pm   

Użytkownik "Dariusz Dorochowicz" <_dadoro_@wp.com> napisał w wiadomości
news:l5lt1n$sl8$1@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.

Tue Nov 12, 2013 12:15 pm   

Dariusz Dorochowicz <_dadoro_@wp.com> wrote:


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/

Tue Nov 12, 2013 1:47 pm   

On Tue, 12 Nov 2013 12:09:16 +0100, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:

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

Tue Nov 12, 2013 3:23 pm   

On 12.11.2013 12:09, Piotr Gałka wrote:


Ale w którym miejscu jest synchronizacja*? Przy każdym bicie startu, czy
przy pierwszym w "paczce" ?
Bo jeżeli na początku paczki to moje błędy też podpadają: kilka
początkowych bajtów jest zawsze w porządku, później bywają zjedzone, ale
najczęściej już ich po prostu nie ma do końca transmisji. Następna
przychodzi przeważnie poprawna. Nie dostałem też ani jednego błędnego
bajtu - kontrola parzystości działa.

* no dobra z tym każdym zboczem to chyba moje pobożne życzenia.

--
Mirek.

Tue Nov 12, 2013 5:16 pm   

Użytkownik "Mirek" <i_tak@zaspamowany.adres> napisał w wiadomości
news:l5tdk9$ju0$1@node1.news.atman.pl...

Standardem jest synchronizacja na pierwszym zboczu każdego bitu startu.
Nadajnik może nadawać z dwoma bitami stopu, a odbiornik może być ustawiony
na jeden bit stopu i też zadziała.
Gdyby synchronizacja była na paczkę to:
- tak by nie działało,
- tolerancja na odchyłki częstotliwości byłaby jeszcze mniejsza niż jest.
Czy są rozwiązania niestandardowe - nie mam pojęcia.


A może nadajnik urywa transmisję.
P.G.

Tue Nov 12, 2013 5:23 pm   

W dniu 2013-11-12 12:09, Piotr Gałka pisze:

No tak, tak jest OK. Myślałem o podwójnych bitach: aabbccdd, a nie o
abcd1111. Podoba mi się, tylko trzeba dać dłuższy bit stopu niż jest
faktycznie (chyba właśnie jedynki na końcu) - będzie dobrze.

Pozdrawiam

DD

Tue Nov 12, 2013 6:30 pm   

Użytkownik "Mirosław Kwaśniak" <mirek@uv.ikem.pwr.wroc.pl> napisał w
wiadomości news:l5tnoe$4fl$1@dont-email.me...



Gdy standard powstawał, takie rozwiązanie było chyba ekonomicznie
nieuzasadnione.
P.G.

Tue Nov 12, 2013 6:34 pm   

Hello Mirosław,

Tuesday, November 12, 2013, 6:15:58 PM, you wrote:


Prawidłowe implementacje próbkują raz po czasie połowy bitu, czy to
faktycznie był bit startu.

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

Tue Nov 12, 2013 7:15 pm   

Piotr Gałka <piotr.galka@cutthismicromade.pl> wrote:

Chyba ubogim standardem. Sam miałem problem kiedyś z taką dziwną parą:
- odbiorca synchronizował na zboczu
- nadawca przed zboczem bitu startu czasami wysyłał szpilkę
i było wesoło :(

Prawidłowe implementacje nadpróbkowują np 16x i decyzja op poziomie sygnału
zapada na podstawie wartości większości z tych 16-tu próbek.

Tue Nov 12, 2013 8:56 pm   

SPI używam do czego innego, poza tym ten UART poza komunikacją
Atmeg8<>Atmega128 spełnia też rolę połączenia z PC (ten sam port).

Sat Nov 16, 2013 12:43 pm   

On 12.11.2013 17:16, Piotr Gałka wrote:


Nie urywa. Podłączyłem równolegle pod komputer i testowało się dobę - na
komputerze wszystkie transmisje są prawidłowe. Po stronie linuksa mam
kilka pozjadanych bajtów - jak zwykle. Teraz pytanie jak wygląda tam
uart - jeśli ma "bufor" jednobajtowy, a reszta odbywa się po stronie
sterownika linuksowego to może on gdzieś gubi.
Przez przypadek zrobił się też inny test - miałem kiepski zasilacz i
dawał na avr 5,6V i zaczęły się pojawiać błędy w transmisji: "A"
zamieniało się na "@" , "=" na "<" itp. czyli tutaj pewnie kwarc by
pomógł, ale napięcie i tak było dla avr za wysokie.

--
Mirek.