Pablo C
Guest
Wed Oct 06, 2004 4:50 pm
jak tworzycie ramkę danych i weryfikujecie transmisję?
powiedzmy, że chcę przesłac do uC aktualny czas z komputera albo jakieś
ustawienia dajmy na to jakieś wartości np. aktualną cenę kilku walut,
oprócz tego ustawić kilka opcji a potem odczytać kilka danych z przebiegu
pracy urządzenia. w moim urządzeniu jest program główny i kilka przerwań.
fajnie by było aby transmisja niezakłócała pracy całego urządzenia w tym
sensie, żebym nie musiał zatrzymywać głównego programu na czas transmisji.
od dłuższego czasu próbuję ale ciągle coś jest nie tak. nie chodzi mi o
konkretne rozwiązanie w jakimś języku tylko o ideę. jak się np. przesyła
dane z kasy fiskalnej do peceta? skąd program wie, że to idzie akurat ta
wartość a nie inna i że nie została urwana w połowie. mi wychodzi
strasznie skomplikowana procedura analizująca dane. ja dla utrudnienia
albo ułatwienia (symulowania zakłóceń) zrobiłem łącze w podczerwieni i
muszę wyliminować przekłamania poza tym nie mam dodatkowych linii
informujących o gotowości uC do odbioru danych.
pozdrawiam
PC
p.s.
procesor AT89s53
Fish
Guest
Wed Oct 06, 2004 6:02 pm
W artykule news:ck1bfn$dnt$1@nemesis.news.tpi.pl,
niejaki(a): Pablo C z adresu <pch[ciach]@poczta.onet.pl> napisał(a):
Quote:
jak tworzycie ramkę danych i weryfikujecie transmisję?
Najprościej byłoby wydzielić 1 znak na rozpoczęcie ramki danych i drugi na
zakonczenie.
Do tego dane trzeba zabezpieczyć sumą kontrolną albo nawet lepiej CRC.
Dla szczególnie ważnych danych zastosować kod korekcyjny umozliwiający
odtworzenie poprawnych danych z błędnej transmisji.
Quote:
fajnie by było aby transmisja niezakłócała pracy
Zorganizować bufor na dane, taki żeby zmieściła się w nim cała ramka danych.
Odbiór danych i dodawanie do bufora zrobić na przerwaniach.
Dzieki temu mozna, dopiero po odebraniu całej ramki, przekazać głownemu
programowi informację, że ramka gotowa jest do analizy.
Quote:
zrobiłem łącze w podczerwieni i muszę
wyliminować przekłamania poza tym nie mam dodatkowych linii
informujących o gotowości uC do odbioru danych.
To trochę komplikuje sytuację i zwiększa szanse na powstawanie przekłamań
ale i na to są metody
Trzeba dodać potwierdzenie otrzymania danych - a jednoczesnie informację czy
dane zostały przetransmitowane poprawnie czy nie.
Dzięki temu nadawca wie że odbiorca otrzymał dane i może w razie potrzeby
powtórzyć transmisję.
--
Janusz
Pablo C
Guest
Wed Oct 06, 2004 6:16 pm
Quote:
zrobiłem łącze w podczerwieni i muszę
wyliminować przekłamania poza tym nie mam dodatkowych linii
informujących o gotowości uC do odbioru danych.
To trochę komplikuje sytuację i zwiększa szanse na powstawanie
przekłamań
ale i na to są metody
Trzeba dodać potwierdzenie otrzymania danych - a jednoczesnie informację
czy
dane zostały przetransmitowane poprawnie czy nie.
Dzięki temu nadawca wie że odbiorca otrzymał dane i może w razie
potrzeby
powtórzyć transmisję.
póki co obciążyłem kontrolą peceta. odbieram dane a potem je odsyłam i na
tej podstawie stwierdzam czy są poprawne. ale to jest mało wydajne. co do
łącza wybór padł na podczerwień z powodu łatwego symulowania zakłóceń a
chcę zapewnić 100% pewności. jeżeli okaże się, że jest błąd to ignoruję
dane i niewysyłam potwierdzenia.
PC
Fish
Guest
Wed Oct 06, 2004 6:33 pm
W artykule news:ck1gb2$cu8$1@atlantis.news.tpi.pl,
niejaki(a): Pablo C z adresu <pch[ciach]@poczta.onet.pl> napisał(a):
Quote:
jeżeli okaże się,
że jest błąd to ignoruję dane i niewysyłam potwierdzenia.
Ja bym wysłał w takim przypadku informację "Otrzymałem dane. Dziekuje ale
były fatalnie przekłamane i nic nie zrozumiałem." :-)
Dla nadawcy informacja, że odbiorca żyje i coś otrzymuje z tego co do niego
wysylamy, może być czasami bardzo cenna. W odróżnieniu od sytuacji kiedy nie
przyjdzie żadne potwierdzenie co może sugerować np awarię łącza.
Na dodatek otrzymując informację, że dane były przekłamane, nadawca może
powtórzyć transmisję bezzwłocznie a nie dopiero po zakończeniu czasu
oczekiwania na potwierdzenie.
--
Janusz
asdfg2
Guest
Thu Oct 07, 2004 4:50 am
Użytkownik "Pablo C" <pch[ciach]@poczta.onet.pl> napisał w wiadomości
news:ck1bfn$dnt$1@nemesis.news.tpi.pl...
Quote:
jak tworzycie ramkę danych i weryfikujecie transmisję?
powiedzmy, że chcę przesłac do uC aktualny czas z komputera albo jakieś
ustawienia dajmy na to jakieś wartości np. aktualną cenę kilku walut,
oprócz tego ustawić kilka opcji a potem odczytać kilka danych z przebiegu
pracy urządzenia. w moim urządzeniu jest program główny i kilka przerwań.
fajnie by było aby transmisja niezakłócała pracy całego urządzenia w tym
sensie, żebym nie musiał zatrzymywać głównego programu na czas transmisji.
od dłuższego czasu próbuję ale ciągle coś jest nie tak. nie chodzi mi o
konkretne rozwiązanie w jakimś języku tylko o ideę. jak się np. przesyła
dane z kasy fiskalnej do peceta? skąd program wie, że to idzie akurat ta
wartość a nie inna i że nie została urwana w połowie. mi wychodzi
strasznie skomplikowana procedura analizująca dane. ja dla utrudnienia
albo ułatwienia (symulowania zakłóceń) zrobiłem łącze w podczerwieni i
muszę wyliminować przekłamania poza tym nie mam dodatkowych linii
informujących o gotowości uC do odbioru danych.
pozdrawiam
PC
p.s.
procesor AT89s53
A ja wymyśliłem to sobie tak, że przy odebraniu pierwszego bajtu uruchamiam
timer, przerwanie od każdego kolejnego baju ładuje do timera stałą
wartość(np. czas transmisji 2 bajtów), zwiększa licznik bajtów. Koniec
transmisji(ramki) powoduje przepełnienie timera i wywołanie przerwania. W
buforze mam kompletną ramkę. Dalej można zweryfikować rozmiar, crc itd.
Krzysztof Rudnik
Guest
Thu Oct 07, 2004 6:40 am
asdfg2 wrote:
Quote:
Użytkownik "Pablo C" <pch[ciach]@poczta.onet.pl> napisał w wiadomości
news:ck1bfn$dnt$1@nemesis.news.tpi.pl...
jak tworzycie ramkę danych i weryfikujecie transmisję?
powiedzmy, że chcę przesłac do uC aktualny czas z komputera albo jakieś
ustawienia dajmy na to jakieś wartości np. aktualną cenę kilku walut,
oprócz tego ustawić kilka opcji a potem odczytać kilka danych z przebiegu
pracy urządzenia. w moim urządzeniu jest program główny i kilka przerwań.
fajnie by było aby transmisja niezakłócała pracy całego urządzenia w tym
sensie, żebym nie musiał zatrzymywać głównego programu na czas
transmisji. od dłuższego czasu próbuję ale ciągle coś jest nie tak. nie
chodzi mi o konkretne rozwiązanie w jakimś języku tylko o ideę. jak się
np. przesyła dane z kasy fiskalnej do peceta? skąd program wie, że to
idzie akurat ta wartość a nie inna i że nie została urwana w połowie. mi
wychodzi strasznie skomplikowana procedura analizująca dane. ja dla
utrudnienia albo ułatwienia (symulowania zakłóceń) zrobiłem łącze w
podczerwieni i muszę wyliminować przekłamania poza tym nie mam
dodatkowych linii informujących o gotowości uC do odbioru danych.
Proponuje zerknac do zrodel i opisow podstawowych protokolow
transmisji szeregowej np. Kermit, X/Y/Zmodem itp.
Quote:
A ja wymyśliłem to sobie tak, że przy odebraniu pierwszego bajtu
uruchamiam timer, przerwanie od każdego kolejnego baju ładuje do timera
stałą wartość(np. czas transmisji 2 bajtów), zwiększa licznik bajtów.
Koniec transmisji(ramki) powoduje przepełnienie timera i wywołanie
przerwania. W buforze mam kompletną ramkę. Dalej można zweryfikować
rozmiar, crc itd.
Timer zwykle jest potrzebny - kazdy protokol ma jakis timeout,
ale zwykle dziala na wyzszej warstwie (np. czas oczekiwania
na potwierdzenie ramki). Timer na poziomie bajtow (wykrywanie 'ciszy')
ma te wade, ze polaczenie musi byc bezposrednie - moga byc klopoty
jesli np. system wielozadaniowy na moment wstrzyma zadanie na jednym
z komputerow, transmisja idzie przez jakies urzadzenie buforujace
(np. modem albo RS na USB).
Krzysiek Rudnik
Waldemar Krzok
Guest
Thu Oct 07, 2004 11:11 am
Pablo C wrote:
Quote:
jak tworzycie ramkę danych i weryfikujecie transmisję?
powiedzmy, że chcę przesłac do uC aktualny czas z komputera albo jakieś
ustawienia dajmy na to jakieś wartości np. aktualną cenę kilku walut,
oprócz tego ustawić kilka opcji a potem odczytać kilka danych z przebiegu
pracy urządzenia. w moim urządzeniu jest program główny i kilka przerwań.
fajnie by było aby transmisja niezakłócała pracy całego urządzenia w tym
sensie, żebym nie musiał zatrzymywać głównego programu na czas transmisji.
od dłuższego czasu próbuję ale ciągle coś jest nie tak. nie chodzi mi o
konkretne rozwiązanie w jakimś języku tylko o ideę. jak się np. przesyła
dane z kasy fiskalnej do peceta? skąd program wie, że to idzie akurat ta
wartość a nie inna i że nie została urwana w połowie. mi wychodzi
strasznie skomplikowana procedura analizująca dane. ja dla utrudnienia
albo ułatwienia (symulowania zakłóceń) zrobiłem łącze w podczerwieni i
muszę wyliminować przekłamania poza tym nie mam dodatkowych linii
informujących o gotowości uC do odbioru danych.
ja mam taki prosty protokół komunikacyjny z prockiem wysyłającym pakiety
danych cięgiem. W tym przyparku nie jest mi potrzebna każda informacja,
ale jak jest błąd, to muszę to wiedzieć. Dane z procka są kodowane na 7
bitach, tylko pierwszy bajt pakietu ma ustawioną 1 na MSB. Tak znajduję
początek pakietu. Potem wiem, że idą jeszcze 23 bajty (zero i 7 bitów
znaczących). Ten majdan dekoduję i mam 20 bajtów informacji (już 8
bitowe bajty) oraz jeden bajt CRC.
Waldek
Mister
Guest
Thu Oct 07, 2004 12:00 pm
Quote:
początek pakietu. Potem wiem, że idą jeszcze 23 bajty (zero i 7 bitów
znaczących). Ten majdan dekoduję i mam 20 bajtów informacji (już 8
bitowe bajty) oraz jeden bajt CRC.
Sprytne !
Mister
ziel
Guest
Thu Oct 07, 2004 12:42 pm
On Behalf Of Mister
Quote:
Sprytne !
Hi, hi!
Może i sprytne, ale nie napisał ile różnych specyfikacji
przeczytał i przetestował, zanim napisał własny niezawodny.
Specyfikację można wymyśleć dowolną (no prawie dowolną),
skuteczność transmisji siedzi w kodzie.
Możesz napisać samemu w/g powyższych wskazówek, a procent
błędów może być większy od prostego przesyłania bajt po bajcie
i to z prostym CRC.
Ja mam trochę procedurę, którą opanowałem.
I tu jest pies pogrzebany ;-)
pzdr
Artur
--
Archiwum grupy:
http://niusy.onet.pl/pl.misc.elektronika
neuron
Guest
Thu Oct 07, 2004 6:34 pm
Quote:
ja mam taki prosty protokół komunikacyjny z prockiem wysyłającym pakiety
danych cięgiem. W tym przyparku nie jest mi potrzebna każda informacja,
ale jak jest błąd, to muszę to wiedzieć. Dane z procka są kodowane na 7
bitach, tylko pierwszy bajt pakietu ma ustawioną 1 na MSB. Tak znajduję
początek pakietu. Potem wiem, że idą jeszcze 23 bajty (zero i 7 bitów
znaczących). Ten majdan dekoduję i mam 20 bajtów informacji (już 8
bitowe bajty) oraz jeden bajt CRC.
Waldek
wszedzie gdzie jest to mozliwe stosuje ciagla wymiane bloku danych z suma
kontrolna , dwoma bajtami
startowymi (np CR LF) i pewna nadmiarowoscia polegajaca na zalozeniu ze 90
procent ramek moze zginac.
obsluga rsa ma blok danych przeniesc z PC do uC i vice versa. A wlasciwy
program operuje na bitach czy zmiennych ktore sa duplikowane do odbiorcy nie
zawracajac sobie glowy tym jak to dzieje.
Oczywiscie taka transmisja nie nadaje sie do transferu wielkich porcji
danych (np programator) ale do sterowania
urzadzeniami czy pomiaru temperatury to jest dbest
Proponuje przyjrzec sie blizej standardowi modbus .
wojtek
----------------------------------------------------------------------------
-------
GolemSLR - system licząco rejestrujący.
Nowy wymiar systemów SCADA
www.neuron.com.pl