przesył danych po rs'ie



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomo¶ć
Spis tre¶ci
From: "Goju" <emdz_at_nospam_poczta.onet.pl>
Subject: przesył danych po rs'ie
Date: Tue, 1 Mar 2005 20:57:45 +0100


Witam.

Zrobiłem urządzonko na Atmedze8535 do którego parametry pracy przesyłam za
pomocą rs'a. Danych tych jest ok 20 bajtów.
Stąd moje pytanie w jak kontrolować poprawny przesył danych?

Po przyj¶ciu pierwszej danej zapisywana jest w pamięci i inkrementowany jest
rejestr pełniący funkcje licznika.
Gdy przyjdą wszystkie dane to licznik ten jest zerowany, dodatkowo po
przyj¶ciu 1 danej włączam timer,
gdy przepełni się i nie przyjdzie następna dana to cały pakiet danych jest
pomijany. to od strony uC.

Natomiast program komputerowy po każdym wysłanym bajcie czeka na dane
zwrotne wysłane przez uC je¶li
zgadzają się to wysyłany jest następny bajt, je¶li natomiast nie to
transmisja jest przerywana.

Ja to rozwiązałem tak i nie wiem czy jest to poprawne, a zależy mi na
poprawnej transmisji.

Proszę o pomoc i pozdrawiam.
Goju.




Poprzedni Następny
Wiadomo¶ć
Spis tre¶ci
From: Krzysztof Rudnik <rudnik_at_nospam_kki.net.pl>
Subject: Re: =?ISO-8859-2?Q?przesy=B3?= danych po rs'ie
Date: Tue, 01 Mar 2005 21:19:28 +0100


Goju wrote:

Witam.

Zrobiłem urządzonko na Atmedze8535 do którego parametry pracy przesyłam za
pomocą rs'a. Danych tych jest ok 20 bajtów.
Stąd moje pytanie w jak kontrolować poprawny przesył danych?

Najlepiej zobaczyc jak to sie robi np. w ZModemie itp.


Po przyj¶ciu pierwszej danej zapisywana jest w pamięci i inkrementowany
jest rejestr pełniący funkcje licznika.

Skad wiesz ktora dana jest pierwsza? Musisz rozpatrzec jak
pracuje urzadzenie po kilku godzinach pracy, a nie czy przesle
pierwszy rozkaz.

Proponuje timeout (solidny) - brak danych np. minute - co by nie
przyszlo traktowane jest jako poczatek.

Gdy przyjdą wszystkie dane to licznik ten jest zerowany, dodatkowo po
przyj¶ciu 1 danej włączam timer,
gdy przepełni się i nie przyjdzie następna dana to cały pakiet danych jest
pomijany. to od strony uC.

Widze ze masz timeout - ok - pomijajac pakiet wyzeruj licznik bajtow.



Natomiast program komputerowy po każdym wysłanym bajcie czeka na dane
zwrotne wysłane przez uC je¶li
zgadzają się to wysyłany jest następny bajt, je¶li natomiast nie to
transmisja jest przerywana.

Wysylanie echa to nie najlepszy pomysl. Nie bardzo kontrolujesz
co jest grane jesli w przesylanych danych bedzie kilka razy ten sam bajt.
Lepiej odsylac np. licznik. No i co to znaczy transmisja jest przerywana?
Przeciez pewnie chcialbys by po bledzie trznsmisja mogla byc
wznowiona bez resetowania.
Jak bardzo ci zalezy na pewnosci dodaj do kazdego pakietu sume kontrolna
(prosciutkie - to tylko 20 bajtow danych), i wysylaj potwierdzenie
(ACK lub NAK) po kazdym pakiecie. No i oczywiscie timeout od
strony PC tez by sie przydal.
No i numerowanie pakietow i potwierdzen - wystarczy '1-bitowy
licznik', o ile nie zakladasz kolejkowania pakietow gdzies
'w sieci' (np. w modemach).

Dobrze jest tez jakos zakodowac dane, tak by poczatek pakietu mozna
bylo znalezc w dowolnym ciagu przesylanych bajtow.

Krzysiek Rudnik


Poprzedni Następny
Wiadomo¶ć
Spis tre¶ci
From: "Pablo C" <pch[ciach]_at_nospam_poczta.onet.pl>
Subject: Re: przesył danych po rs'ie
Date: Wed, 2 Mar 2005 08:45:34 +0100


Ja zrobiłem co¶ a'la uproszczony modbus. Ramka wyglada tak:

X dd dd dd dd CC

- start transmisji
X - komenda
dd dd dd dd - 4 bajty danych hex
CC - suma kontrolna poprzednich znaków

Proste i skuteczne. Pewnie, że są lepsze sposoby ale ten mi działa
znakomicie.

Pozdrawiam
PC




Poprzedni Następny
Wiadomo¶ć
Spis tre¶ci
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: =?ISO-8859-2?Q?przesy=B3_danych_po_rs=27ie?=
Date: Wed, 02 Mar 2005 09:30:58 +0100


Pablo C wrote:
X dd dd dd dd CC

Ja również stosuje takie sztuczki. Grunt w transmisji strumieniowej
(jaką jest RS232) jest znak odddzialający i mówiący "tu zaczyna się
ramka danych". Problem z timeoutami jest do¶c trudny w rozwiązaniu na
zwykłym PC i nie polecam - 100x lepiej jest przy tak małej ilo¶ci danych
(20 bajtów to jest nic) na po¶więcenie troche czasu i wysłanie ramki w
hex'ach albo innym pomy¶le kodowania bajt->2bajty. No i CRC to podstawa
dyskusji o kontroli błędów. Projektuje własnie protokół i rozwiązuje na
bierząco takie sprawy. Transmisja "2-bajtowa" okazała się jedynym
sensownym sposobem do realizacji w sposób szybki i wygodny bez timeoutów.

--
Sebastian Bialy - heby_at_nospam_poczta.onet.pl