komunikacja między 2 procesorami 8051 w trybie asynchro...
komunikacja między 2 procesorami 8051 w trybie asynchro...
Witam mam do wykonania projekt „komunikacja między 2 procesorami w trybie asynchronicznym z kontrolą poprawności transmisji” i szczerze mówiąc nie mam pomysłu jak się za to zabrać i tu prośba o pomoc do użytkowników tego forum. Projekt mogę kupić i będzie po sprawie, ale w ten sposób raczej zaliczę a niczego się nie nauczę. Szukam kogoś kto mi w tym pomoże i wytłumaczy niektóre problemy. Nie będę się tu rozwodził bo niechce zaśmiecać forum. Jeśli ktoś jest w stanie i chce mi pomóc proszę o kontakt
Łatwo zgadnąć, że temat dotyczy dwóch zagadnień: sprzętu i oprogramowania.
Jeżeli chodzi o elektronikę, w najprostszym przypadku wystarczy
skrzyżowanie linii TxD i RxD komunikujacych się ze sobą kontrolerów,
odpowiednio TxD1-RxD2, RxD1-TxD2 oraz uwspólnienie ich mas.
Oczywiście możemy to skomplikować w dowolny sposób, na przykład dodając
optoizolację czy zastępując bezpośrednie (galwaniczne) połączenie
łączem bezprzewodowym (radio, IR).
Osobne zagadnienie to oprogramowanie i tu można rozpatrywać dwa poziomy:
pierwszy to przesyłanie danych z kontrolą ich poprawności (suma kontrolna/CRC),
drugi to obróbka przesyłanych danych i potwierdzanie ich poprawności (sensowności)
z punktu widzenia współpracujących programów głównych.
Fizyczne połączenie kontrolerów to jak gdyby warstwa sprzętowa,
nadawanie/odbiór pakietów danych i kontrola ich technicznej poprawności to łącze danych
(pierwsza warstwa oprogramowania), logika obsługująca tak przesyłane dane/polecenia,
odsyłanie potwierdzeń, że dane zostały zrozumiane i przetworzone to już coś w rodzaju
warstwy aplikacyjnej...a to wszystko zebrane razem przypomina odrobinę coś,
co nazywa się modelem OSI, tylko z wyciętymi warstwami środkowymi,
a to ze względu na proste dwupunktowe połączenie.
To może wydawać się nieco skomplikowane ale zauważ, że wiele zyskuje się
stosując taki cebulkowo-warstwowy model.
Po pierwsze, z punktu widzenia głównego programu nie ma żadnego znaczenia
jak fizycznie zorganizowana jest trasmisja. Jego to nie interesuje i w sumie
nie powinno. Program ma jakieś swoje dane do wysłania, więc wywołuje odpowiednią
funkcję warstwy niższej a potem czeka na zrozumiałą dla siebie odpowiedź.
Warstwa poniżej (łącze) nie musi wiedzieć co dla programu oznaczają te dane,
i co to właściwie jest. Ona tylko konwertuje te dane na format możliwy do wysłania
przez sprzęt (tu: znaki ASCII), dodaje jakieś nagłówki, wyliczone sumy kontrolne
i wstawia do układów nadawczych. I to tyle nadawania.
Odbiór podobnie - po drugiej stronie, zestaw funkcji niższej warstwy odbiera
pakiet danych (ramkę), sprawdza jego poprawność ale z technicznego nie logicznego
punktu widzenia (sumy kontrolne, etc...), potem wyciąga czyste dane i podaje
warstwie wyżej (aplikacji), niech się ona martwi tym co przyszło.
A aplikacja mając te dane, może podjąć już jakieś kroki zależnie co zostało nadesłane,
np. odznaczyć, że jakaś porcja danych została przyjęta, wyświetlić te dane, etc.
Inna sprawa, że w przy takim podejściu, ewentualne błędy w transmisji są obsługiwane
tylko w warstwie łącza, błędy logiczne (czyli dane poprawne, lecz bez sensu) w warstwie
aplikacji. To umożliwia na przykład ponawianie transmisji tego co się gdzieś po drodze
zgubiło, korekcję błędów niejako za plecami programu głównego.
A dla programu głównego zysk taki, że można spokojnie zmienić rodzaj transmisji
na jakiś inny, a on nawet tego nie odczuje - przecież ma swoje wysokopoziomowe
funkcje do wymiany danych, skoro one ciągle (z jego punktu widzenia) działają - to jest ok.
to według mnie nie jest zaśmiecanie forum tylko ułatwienie dla tych,
którzy ewentualnie na post odpowiedzą...zgodzisz się, prawda?
pozdrawiam,
tasza
Jeżeli chodzi o elektronikę, w najprostszym przypadku wystarczy
skrzyżowanie linii TxD i RxD komunikujacych się ze sobą kontrolerów,
odpowiednio TxD1-RxD2, RxD1-TxD2 oraz uwspólnienie ich mas.
Oczywiście możemy to skomplikować w dowolny sposób, na przykład dodając
optoizolację czy zastępując bezpośrednie (galwaniczne) połączenie
łączem bezprzewodowym (radio, IR).
Osobne zagadnienie to oprogramowanie i tu można rozpatrywać dwa poziomy:
pierwszy to przesyłanie danych z kontrolą ich poprawności (suma kontrolna/CRC),
drugi to obróbka przesyłanych danych i potwierdzanie ich poprawności (sensowności)
z punktu widzenia współpracujących programów głównych.
Fizyczne połączenie kontrolerów to jak gdyby warstwa sprzętowa,
nadawanie/odbiór pakietów danych i kontrola ich technicznej poprawności to łącze danych
(pierwsza warstwa oprogramowania), logika obsługująca tak przesyłane dane/polecenia,
odsyłanie potwierdzeń, że dane zostały zrozumiane i przetworzone to już coś w rodzaju
warstwy aplikacyjnej...a to wszystko zebrane razem przypomina odrobinę coś,
co nazywa się modelem OSI, tylko z wyciętymi warstwami środkowymi,
a to ze względu na proste dwupunktowe połączenie.
To może wydawać się nieco skomplikowane ale zauważ, że wiele zyskuje się
stosując taki cebulkowo-warstwowy model.
Po pierwsze, z punktu widzenia głównego programu nie ma żadnego znaczenia
jak fizycznie zorganizowana jest trasmisja. Jego to nie interesuje i w sumie
nie powinno. Program ma jakieś swoje dane do wysłania, więc wywołuje odpowiednią
funkcję warstwy niższej a potem czeka na zrozumiałą dla siebie odpowiedź.
Warstwa poniżej (łącze) nie musi wiedzieć co dla programu oznaczają te dane,
i co to właściwie jest. Ona tylko konwertuje te dane na format możliwy do wysłania
przez sprzęt (tu: znaki ASCII), dodaje jakieś nagłówki, wyliczone sumy kontrolne
i wstawia do układów nadawczych. I to tyle nadawania.
Odbiór podobnie - po drugiej stronie, zestaw funkcji niższej warstwy odbiera
pakiet danych (ramkę), sprawdza jego poprawność ale z technicznego nie logicznego
punktu widzenia (sumy kontrolne, etc...), potem wyciąga czyste dane i podaje
warstwie wyżej (aplikacji), niech się ona martwi tym co przyszło.
A aplikacja mając te dane, może podjąć już jakieś kroki zależnie co zostało nadesłane,
np. odznaczyć, że jakaś porcja danych została przyjęta, wyświetlić te dane, etc.
Inna sprawa, że w przy takim podejściu, ewentualne błędy w transmisji są obsługiwane
tylko w warstwie łącza, błędy logiczne (czyli dane poprawne, lecz bez sensu) w warstwie
aplikacji. To umożliwia na przykład ponawianie transmisji tego co się gdzieś po drodze
zgubiło, korekcję błędów niejako za plecami programu głównego.
A dla programu głównego zysk taki, że można spokojnie zmienić rodzaj transmisji
na jakiś inny, a on nawet tego nie odczuje - przecież ma swoje wysokopoziomowe
funkcje do wymiany danych, skoro one ciągle (z jego punktu widzenia) działają - to jest ok.
Dokładnie opisanie wymagań jakie zostały postawione przed projektemmouse pisze:Nie będę się tu rozwodził bo niechce zaśmiecać forum.
to według mnie nie jest zaśmiecanie forum tylko ułatwienie dla tych,
którzy ewentualnie na post odpowiedzą...zgodzisz się, prawda?
pozdrawiam,
tasza
Dokładny temat projektu to :
Wykonać projekt układu komunikacji między dwoma uP w trybie asynchronicznym z kontrolą poprawności transmisji. Podać schemat układu oraz schemat blokowy programu (RAM i ROM zewnętrzne)
Dane: Mikroprocesor: uK MCS-8051, odległość <20m, łącze światłowodowe, komunikacja dwukierunkowa, szybkość transmisji ok.20kb/sek, typ transmisji 8bit+bit kontroli parzystości
Teoretycznie tak jak pisałaś wystarczy odpowiednio połączyć txd i txr ale niestety nie wiem jak sprawdzić poprawność transmisji. „To może wydawać się nieco skomplikowane ale zauważ, że wiele zyskuje się stosując taki cebulkowo-warstwowy model.”(dla mnie jest nawet troje bardziej niż nieco
)
Ale rozumiem to mniej więcej tak :
Procesor nazwijmy go A jest zaprogramowany i chce wysłać dane. Więc sprawdza sumy kontrolne i wysyła dane po wysłaniu do drugiego procesora B czeka aż procesor B odbierze dane sprawdzi sumy kontrolne i sume kontrolną odeśle do A który sprawdzi czy suma kontrolna z danych wysłanych i odebranych jest taka sama. Jeśli nie to wysyła sygnał do B że transmisje trzeba powtórzyć jeśli sumy się zgadzają to wysyła do B że dane przeszły bez zmian. Niestety coś mi się wydaje że moje rozumowanie jest za proste.
Czy zamiast sprawdzania sum kontrolnych można wykorzystać bit kontroli parzystości j jeśli tak to jak ? dzięki za zainteresowanie i pomoc
Wykonać projekt układu komunikacji między dwoma uP w trybie asynchronicznym z kontrolą poprawności transmisji. Podać schemat układu oraz schemat blokowy programu (RAM i ROM zewnętrzne)
Dane: Mikroprocesor: uK MCS-8051, odległość <20m, łącze światłowodowe, komunikacja dwukierunkowa, szybkość transmisji ok.20kb/sek, typ transmisji 8bit+bit kontroli parzystości
Teoretycznie tak jak pisałaś wystarczy odpowiednio połączyć txd i txr ale niestety nie wiem jak sprawdzić poprawność transmisji. „To może wydawać się nieco skomplikowane ale zauważ, że wiele zyskuje się stosując taki cebulkowo-warstwowy model.”(dla mnie jest nawet troje bardziej niż nieco
)Ale rozumiem to mniej więcej tak :
Procesor nazwijmy go A jest zaprogramowany i chce wysłać dane. Więc sprawdza sumy kontrolne i wysyła dane po wysłaniu do drugiego procesora B czeka aż procesor B odbierze dane sprawdzi sumy kontrolne i sume kontrolną odeśle do A który sprawdzi czy suma kontrolna z danych wysłanych i odebranych jest taka sama. Jeśli nie to wysyła sygnał do B że transmisje trzeba powtórzyć jeśli sumy się zgadzają to wysyła do B że dane przeszły bez zmian. Niestety coś mi się wydaje że moje rozumowanie jest za proste.
Czy zamiast sprawdzania sum kontrolnych można wykorzystać bit kontroli parzystości j jeśli tak to jak ? dzięki za zainteresowanie i pomoc
Dostałeś całkiem ciekawy temat do opracowania.
Co do światłowodu, to może takie transceivery optyczne http://www.tme.pl/arts2/pl/a06/totx197.html ?
O, na przykład TOTX197 jest tutaj: http://www.ortodoxism.ro/datasheets/toshiba/2085.pdf , ale popatrz też na inne.
Co do procesora, na klasycznej zwykłej '51 wiele nie zdziałasz, przynajmniej
w mojej opinii. Głównie ze względu na małą wydajność i ubogie peryferia...
Oczywiście, jeżeli masz już jakiś zestaw uruchomieniowy
(ćwiczeniowy) to trzeba go wykorzystać, ale jeżeli nie to rozważ użycie
na przykład kostek typu DS89C4x0 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4078
ja ciągle o nich wspominam, ponieważ są bardzo komfortowe w użyciu, mają sporo
pamięci flash programowanej w systemie, 1kB pamięci wewnętrznej dostępnej instrukcją MOVX
no i to co tu chyba najważniejsze - wbudowane dwa układy transmisji szeregowej...
To że działają na max. 33MHz to już szczegół... ale zastanów się.
Mając kontroler z dwoma UART, jeden możesz przenaczyć na komunikację optyczną,
drugi wykorzystać do komunikacji z PC, nie trzeba nic dodawać, no może tylko MAX232...
Tą kość możesz wstawić wszędzie tam gdzie pracowało zwykłe '51, nawet jeżeli korzystało
z zewnętrznych pamięci CODE/XDATA
Teraz oprogramowanie.
Skoro spinasz dwa kontrolery ze sobą, to nie musisz się trzymać szybkości
transmisji typowych dla RS232, można wybrać dowolne, aby tylko spełnić ~20kb/s...
Skoro transmisja ma być 8bit+parzystość to tak naprawdę, z punktu widzenia
bloku UART kontrolera, ona będzie 9-bitowa czyli do wyboru mamy tryb 2 lub 3 UART-a:
tryb 2: SM0,SM1 = 1,0 taktowanie UART-a 1/32 lub 1/64 wartości fosc
tryb 3: SM0,SM1 = 1,1 taktowanie UART-a z wyjścia licznika T1
Doczytaj proszę w dokumentacji procesora jak działa UART w tych trybach
i jak go skonfigurować, a teraz tylko to co najważniejsze.
Dla dziewięciobitowej transmisji (8+1), osiem bitów danych wpisujemy/odczytujemy
z rejestru SBUF (jak zwykle), bit D8 (dziewiąty) przy wysyłce wpisujemy
do SCON.3 (inaczej TB8), a przy odczycie szukamy go w RB8 (SCON.2).
Jeżeli bit SM2 (SCON.5) będzie dodatkowo ustawiony na 0 to UART nie będzie
w żaden sposób wnikał w zawartość dziewiątego bitu tylko po prostu go prześle.
(kiedyś, z ciekawości: doczytaj o maskowaniu odbierana znaków, to warto wiedzieć)
sprawdzamy bajt w kontekście parzystości http://en.wikipedia.org/wiki/Parity_bit , czyli liczymy ustawione
jedynki w bajcie, jak wyjdzie parzysta liczba to ustawić TB8 na 1, a jak nie to na 0
i nadajemy pakiet bitów wstawiając rzeczony bajt do SBUF (co zainicjuje wysyłkę) i to tyle.
Po stronie odbiorczej - analogicznie, tylko że w drugą stronę: gdy UART zgłosi
że znaczek jest gotowy do pobrania w SBUF to pobieramy go, pobieramy także
zawartośc bitu RB8 (SCON.2), określamy parzystość pobranej z SBUF liczby
i porównujemy z wartością RB8. I jak nie pasuje to do kosza - znaczek ignorujemy
jako błędny.
Tylko widzisz...z tą parzystością to jest ładnie jak jej obsługą i kontrolą
poprawności zajmuje się sprzęt czyli układ UART sam z siebie.
Taki przykładowo PC16550D http://cache.national.com/ds/PC/PC16550D.pdf i punkt 8.4 Line Status Register,
popatrz proszę na opis bitu 2 tego rejestru - PE (Parity Error indicator).
Błąd parzystości wykrywa sama elektronika, system mikroprocesorowy może z tej informacji
skorzystać jeżeli akurat ma taką zachciewajkę. Ale UART-y w '51 (nawet w tych podrasowanych)
obsługują 9-ty bit danych, owszem tyle że on ustawiany jest przez program, to zwykły dodatkowy
względem pozostałych ośmiu bit danych. Aby pełnił rolę wskaźnika parzystości - trzeba to sobie oprogramować.
Ten kawalątek kodu, który będzie wyliczał parzystość to jednak dodatkowy koszt, dodatkowe
zużycie czasu procesora a to może mieć wpływ na przepustowość łącza.
(choć akurat w przypadku procesorów DS89C4x0 z wydajnością może problemów nie być...)
Kontrola parzystości to taki jakby pierwszy filtr na poprawne dane,
po prostu - co nie pasuje nie wstawiamy do buforów odbiorczych w programie. Oczywiście
to może spowodować, że w buforze odbiorczym znajdą się uszkodzone (niekompletne)
pakiety danych stąd sprawdzanie sum kontrolnych to drugi (i według mnie niezbędny) etap.
Spróbuj zdefiniować sobie jakiś prosty protokół do przesyłania danych.
O, coś takiego:
dana do wysłania - napis 'elportal'
1) zamiana na postać ascii/hex
65 6C 70 6F 72 74 61 6C
2) wyznaczenie długości danych (tu 8 skonwertowanych na hex bajtów)
08
3) dołożenie typu ramki 'D'- data ( będą też 'A' - acknowledgement, 'E' - error )
D
4) wylicznie sumy kontrolnej z danych do wysłania
nie wiem ile to będzie...
AB przykładowo
5) dołożenie nagłówka i stopki ^ - nagłówek, <cr> - (13 dziesiętnie, 0x0D w hex) - stopka
cała gotowa do wysyłki ramka:
^D08656C706F7274616CAB<cr>
jak widać, to czysty tekst, dla każdego znaczka robimy to co pisałam powyżej:
obliczmy parzystość, ustawiamy 9 bit i plum do SBUF...
co do sumy kontrolnej...algorytmów jest wiele, w sieci znajdziesz, można też
coś zaimprowizować...np. dodawać bajty do siebie modulo 0xFF...jakkolwiek.
po stronie odbiorczej - zakładamy, że odbiór znaczków jest w przerwaniach od UART-a,
zakładamy że mamy w pamięci miejsce na bufor odbiorczy oraz kilka zmiennych pomocniczych:
wskaźnik bufora, flagę odbioru ramki, flagę gotowości ramki, drugi bufor na wynikową ramkę:
w pętli programu głównego:
coś tam sobie robimy, co jakiś czas zerkając czy może flaga
gotowości ramki jest ustawiona, jeżeli jest ustawiona oznacza to
że w tym dodatkowym buforze (rozłącznym od tego na którym operuje UART)
są dane i należy coś z nimi zrobić, więc:
nieco inny punkt widzenia to:
No, to taki uproszczony opis w formie słowno-muzycznej, do tego dochodzą
jeszcze uroki timeoutów, czyli że program rozpocznie kompletowanie ramki,
a nie doczeka się końca, rozsądna obsługa i meldowanie błędów...etc/itd...
W sumie najlepiej byłoby zacząć coś szkicować...w C lub w assemblerze, jak wolisz.
Dość dużo można zrobić i wytestować chociażby wysyłając do kontrolera przygotowane
wcześniej, gotowe ramki...komunikować można się przez jakikolwiek program terminalowy...
Fajnie masz.
pozdrawiam,
tasza
Co do światłowodu, to może takie transceivery optyczne http://www.tme.pl/arts2/pl/a06/totx197.html ?
O, na przykład TOTX197 jest tutaj: http://www.ortodoxism.ro/datasheets/toshiba/2085.pdf , ale popatrz też na inne.
Co do procesora, na klasycznej zwykłej '51 wiele nie zdziałasz, przynajmniej
w mojej opinii. Głównie ze względu na małą wydajność i ubogie peryferia...
Oczywiście, jeżeli masz już jakiś zestaw uruchomieniowy
(ćwiczeniowy) to trzeba go wykorzystać, ale jeżeli nie to rozważ użycie
na przykład kostek typu DS89C4x0 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4078
ja ciągle o nich wspominam, ponieważ są bardzo komfortowe w użyciu, mają sporo
pamięci flash programowanej w systemie, 1kB pamięci wewnętrznej dostępnej instrukcją MOVX
no i to co tu chyba najważniejsze - wbudowane dwa układy transmisji szeregowej...
To że działają na max. 33MHz to już szczegół... ale zastanów się.
Mając kontroler z dwoma UART, jeden możesz przenaczyć na komunikację optyczną,
drugi wykorzystać do komunikacji z PC, nie trzeba nic dodawać, no może tylko MAX232...
Tą kość możesz wstawić wszędzie tam gdzie pracowało zwykłe '51, nawet jeżeli korzystało
z zewnętrznych pamięci CODE/XDATA
Teraz oprogramowanie.
Skoro spinasz dwa kontrolery ze sobą, to nie musisz się trzymać szybkości
transmisji typowych dla RS232, można wybrać dowolne, aby tylko spełnić ~20kb/s...
Skoro transmisja ma być 8bit+parzystość to tak naprawdę, z punktu widzenia
bloku UART kontrolera, ona będzie 9-bitowa czyli do wyboru mamy tryb 2 lub 3 UART-a:
tryb 2: SM0,SM1 = 1,0 taktowanie UART-a 1/32 lub 1/64 wartości fosc
tryb 3: SM0,SM1 = 1,1 taktowanie UART-a z wyjścia licznika T1
Doczytaj proszę w dokumentacji procesora jak działa UART w tych trybach
i jak go skonfigurować, a teraz tylko to co najważniejsze.
Dla dziewięciobitowej transmisji (8+1), osiem bitów danych wpisujemy/odczytujemy
z rejestru SBUF (jak zwykle), bit D8 (dziewiąty) przy wysyłce wpisujemy
do SCON.3 (inaczej TB8), a przy odczycie szukamy go w RB8 (SCON.2).
Jeżeli bit SM2 (SCON.5) będzie dodatkowo ustawiony na 0 to UART nie będzie
w żaden sposób wnikał w zawartość dziewiątego bitu tylko po prostu go prześle.
(kiedyś, z ciekawości: doczytaj o maskowaniu odbierana znaków, to warto wiedzieć)
Skoro wiemy jak przesyłać dodatkowy dziewiąty bit to dalej już zwyczajnie.mouse pisze:Czy zamiast sprawdzania sum kontrolnych można wykorzystać
bit kontroli parzystości j jeśli tak to jak
sprawdzamy bajt w kontekście parzystości http://en.wikipedia.org/wiki/Parity_bit , czyli liczymy ustawione
jedynki w bajcie, jak wyjdzie parzysta liczba to ustawić TB8 na 1, a jak nie to na 0
i nadajemy pakiet bitów wstawiając rzeczony bajt do SBUF (co zainicjuje wysyłkę) i to tyle.
Po stronie odbiorczej - analogicznie, tylko że w drugą stronę: gdy UART zgłosi
że znaczek jest gotowy do pobrania w SBUF to pobieramy go, pobieramy także
zawartośc bitu RB8 (SCON.2), określamy parzystość pobranej z SBUF liczby
i porównujemy z wartością RB8. I jak nie pasuje to do kosza - znaczek ignorujemy
jako błędny.
Tylko widzisz...z tą parzystością to jest ładnie jak jej obsługą i kontrolą
poprawności zajmuje się sprzęt czyli układ UART sam z siebie.
Taki przykładowo PC16550D http://cache.national.com/ds/PC/PC16550D.pdf i punkt 8.4 Line Status Register,
popatrz proszę na opis bitu 2 tego rejestru - PE (Parity Error indicator).
Błąd parzystości wykrywa sama elektronika, system mikroprocesorowy może z tej informacji
skorzystać jeżeli akurat ma taką zachciewajkę. Ale UART-y w '51 (nawet w tych podrasowanych)
obsługują 9-ty bit danych, owszem tyle że on ustawiany jest przez program, to zwykły dodatkowy
względem pozostałych ośmiu bit danych. Aby pełnił rolę wskaźnika parzystości - trzeba to sobie oprogramować.
Ten kawalątek kodu, który będzie wyliczał parzystość to jednak dodatkowy koszt, dodatkowe
zużycie czasu procesora a to może mieć wpływ na przepustowość łącza.
(choć akurat w przypadku procesorów DS89C4x0 z wydajnością może problemów nie być...)
Kontrola parzystości to taki jakby pierwszy filtr na poprawne dane,
po prostu - co nie pasuje nie wstawiamy do buforów odbiorczych w programie. Oczywiście
to może spowodować, że w buforze odbiorczym znajdą się uszkodzone (niekompletne)
pakiety danych stąd sprawdzanie sum kontrolnych to drugi (i według mnie niezbędny) etap.
Spróbuj zdefiniować sobie jakiś prosty protokół do przesyłania danych.
O, coś takiego:
dana do wysłania - napis 'elportal'
1) zamiana na postać ascii/hex
65 6C 70 6F 72 74 61 6C
2) wyznaczenie długości danych (tu 8 skonwertowanych na hex bajtów)
08
3) dołożenie typu ramki 'D'- data ( będą też 'A' - acknowledgement, 'E' - error )
D
4) wylicznie sumy kontrolnej z danych do wysłania
nie wiem ile to będzie...
AB przykładowo
5) dołożenie nagłówka i stopki ^ - nagłówek, <cr> - (13 dziesiętnie, 0x0D w hex) - stopka
cała gotowa do wysyłki ramka:
^D08656C706F7274616CAB<cr>
jak widać, to czysty tekst, dla każdego znaczka robimy to co pisałam powyżej:
obliczmy parzystość, ustawiamy 9 bit i plum do SBUF...
co do sumy kontrolnej...algorytmów jest wiele, w sieci znajdziesz, można też
coś zaimprowizować...np. dodawać bajty do siebie modulo 0xFF...jakkolwiek.
po stronie odbiorczej - zakładamy, że odbiór znaczków jest w przerwaniach od UART-a,
zakładamy że mamy w pamięci miejsce na bufor odbiorczy oraz kilka zmiennych pomocniczych:
wskaźnik bufora, flagę odbioru ramki, flagę gotowości ramki, drugi bufor na wynikową ramkę:
Kod: Zaznacz cały
w INT dla każdego nowego znaczka:
1) badamy parzystość i porównujemy z 9 bitem
2) jeżeli coś nie pasuje: wychodzimy z procedurki
3) jeżeli znaczek jest nagłówkiem (^) to:
inicjujemy wskaźnik bufora ustawiając go na jego początek
profilaktycznie kasujemy flagę gotowości ramki
ustawiamy falgę odbierania ramki
wychodzimy z procedurki
5) jeżeli ustawiona jest flaga odbioru ramki to:
5a) jeżeli znaczek jest <CR> to oznacza koniec ramki, wtedy:
kopiujemy nasz roboczy bufor do wynikowego,
ustawiamy flagę gotowości ramki, aby nią zajął się program główny
kasujemy flagę odbierania ramki, czyli zaczajamy się ponownie na ^
wychodzimy z procedurki
5b) każdy inny znaczek :
wkładamy do bufora,
odpowiednio inkrementując wskaźnik
i wychodzimy
w pętli programu głównego:
coś tam sobie robimy, co jakiś czas zerkając czy może flaga
gotowości ramki jest ustawiona, jeżeli jest ustawiona oznacza to
że w tym dodatkowym buforze (rozłącznym od tego na którym operuje UART)
są dane i należy coś z nimi zrobić, więc:
Kod: Zaznacz cały
patrzymy na typ ramki:
jeżeli zerowy znak jest 'D' (dane) to:
wyciągamy ich długość (znaczki 1 i 2) '08', zmieniamy z hex na dec (i tu przykładowo
wychodzi nam 8)
np. osiem razy powtarzamy operację:
pobierz dwa kolejne znaczki (n, n+1)
przelicz na dec
coś z nimi zrób (np. skompletuj wynikowy napis)
skończyły się znaczki z danymi, teraz wyciągamy CRC
pobieramy dwa następne znaki (tu: 'AB')
przeliczamy na dec
wyliczamy tym samym algorytmem co przy nadawniu CRC z tego
co skompletowaliśmy w petli wyżej.
porównujemy CRC obliczoną i pobraną z ramki
gdy CRC są równe:
odsyłamy ramkę ^A<cr> (potwierdzenie że chyba jest cacy)
w przeciwnym przypadku:
odsyłamy ramkę ^E0<cr> - informacja że tym razem klapa, kod błędu - 0
kasujemy flagę gotowości, aby zauważyć następną ramkę
jeżeli zerowy znak jest 'A' - potwierdzenie:
robimy cokolwiek mądrego, może wysyłamy następną ramkę?
jeżeli zerowy znak jest 'E' - error
wyciągamy kod błędu
reagujemy na błąd zależnie od kodu
np. podsyłamy ostatnią ramkę jeszcze raz, a może podsyłamy inną ramkę
nieco inny punkt widzenia to:
Kod: Zaznacz cały
system_1 system_2
^DLLXXXXSS<cr> ---------------->
przetwarzanie i walidacja
^A<cr>
<----------------
ramka poszła ok
^DLLYYYYYSS<cr> ---------------->
przetwarzanie i walidacja
^E0<cr>
<----------------
ramka ma błędne CRC
jeszcze uroki timeoutów, czyli że program rozpocznie kompletowanie ramki,
a nie doczeka się końca, rozsądna obsługa i meldowanie błędów...etc/itd...
W sumie najlepiej byłoby zacząć coś szkicować...w C lub w assemblerze, jak wolisz.
Dość dużo można zrobić i wytestować chociażby wysyłając do kontrolera przygotowane
wcześniej, gotowe ramki...komunikować można się przez jakikolwiek program terminalowy...
Fajnie masz.
pozdrawiam,
tasza
Za ogromną pomoc dziękuje. Ale przygotuj się wkrótce więcej pytań
Widzisz mam tak fajnie... a ja tego jakoś nie umiem docenić
[ Dodano: 2006-12-18, 23:08 ]
Z transceiverami optycznymi jest mały problem ( w moim przypadku ) dokładnie taki że są za dobre. Znaczy że ma transfer do 6Mb/s co niestety nie spełniło oczekiwań … wspaniałego prowadzącego . Przekopałem trochę Internet popytałem dziadka gogle i lipa nic ni znalazłem w sensie żadnego trasnceivera czy konwertera o gorszych parametrach.
Co do poprawności transmisji to wole nie dokładać żadnych dodatkowych scalaków dopisanie kilku kolejek kodu będzie prostsze i mniej skomplikowane. Ale mam pytanie czy jeśli podczas sprawdzania bitu parzystości wykryjemy błąd to wywalamy do kosza całą ramkę czy tylko 1 bajt czy wywalamy już całą ramkę?
Znasz może jakąś stronne gdzie jest wyjaśniona sprawa ramek ? bo tak szczerze mówiąc to nie bardzo kumam jak można wysłać transmisje 9 bitową w 32 bajtowej ramce . przechodzi 24 bajty z resztą.. nie do końca to łapie. Przejdzie 28 i zostaną 4 bity…. Czy ramka jest w
ogóle ważna? Czy po prostu transmisja sobie leci a procesor sprawdza i ewentualnie wywala uszkodzone? Może to prosty projekt ale ja się podłamałem.
Widzisz mam tak fajnie... a ja tego jakoś nie umiem docenić
[ Dodano: 2006-12-18, 23:08 ]
Z transceiverami optycznymi jest mały problem ( w moim przypadku ) dokładnie taki że są za dobre. Znaczy że ma transfer do 6Mb/s co niestety nie spełniło oczekiwań … wspaniałego prowadzącego . Przekopałem trochę Internet popytałem dziadka gogle i lipa nic ni znalazłem w sensie żadnego trasnceivera czy konwertera o gorszych parametrach.
Co do poprawności transmisji to wole nie dokładać żadnych dodatkowych scalaków dopisanie kilku kolejek kodu będzie prostsze i mniej skomplikowane. Ale mam pytanie czy jeśli podczas sprawdzania bitu parzystości wykryjemy błąd to wywalamy do kosza całą ramkę czy tylko 1 bajt czy wywalamy już całą ramkę?
Znasz może jakąś stronne gdzie jest wyjaśniona sprawa ramek ? bo tak szczerze mówiąc to nie bardzo kumam jak można wysłać transmisje 9 bitową w 32 bajtowej ramce . przechodzi 24 bajty z resztą.. nie do końca to łapie. Przejdzie 28 i zostaną 4 bity…. Czy ramka jest w
ogóle ważna? Czy po prostu transmisja sobie leci a procesor sprawdza i ewentualnie wywala uszkodzone? Może to prosty projekt ale ja się podłamałem.