[trochę NTG] komunikacja rs ale od strony softu

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

Reply to
Pablo C
Loading thread data ...

W artykule news:ck1bfn$dnt$ snipped-for-privacy@nemesis.news.tpi.pl, niejaki(a): Pablo C z adresu <pch[ciach]@poczta.onet.pl> napisał(a):

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.

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.

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

Reply to
Fish

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

Reply to
Pablo C

W artykule news:ck1gb2$cu8$ snipped-for-privacy@atlantis.news.tpi.pl, niejaki(a): Pablo C z adresu <pch[ciach]@poczta.onet.pl> napisał(a):

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.

Reply to
Fish

Użytkownik "Pablo C" <pch[ciach]@poczta.onet.pl> napisał w wiadomości news:ck1bfn$dnt$ snipped-for-privacy@nemesis.news.tpi.pl...

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.

Reply to
asdfg2

Proponuje zerknac do zrodel i opisow podstawowych protokolow transmisji szeregowej np. Kermit, X/Y/Zmodem itp.

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

Reply to
Krzysztof Rudnik

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

Reply to
Waldemar Krzok

Sprytne !

Mister

Reply to
Mister

On Behalf Of Mister

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

Reply to
ziel

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

formatting link

Reply to
neuron

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.