ATNEL tech-forum

Re: Transmisja szeregowa, protokoły - teoria

2016-08-03T10:13:39+01:00

Znacznik końca rozumiem właśnie jako CR.
Sporo się rozjaśniło Dziękuję Panie Mirku.
Pozostało mi jeszcze tylko zrozumieć zdarzenia, ale myślę, że w tym pomogą mi poradniki i analiza IR z GB.

Statystyki: Napisane przez Jatsekku — 3 sie 2016, o 10:13

Re: Transmisja szeregowa, protokoły - teoria

2016-08-03T05:51:24+01:00

znak enter zamieniany jest na zero właśnie po to żeby powstał czysty c-string jak piszesz .... nie wiem co masz na myśli pisząc o jakimś znaczniku końca. W C stringu końcem jest zero

Statystyki: Napisane przez mirekk36 — 3 sie 2016, o 05:51

Re: Transmisja szeregowa, protokoły - teoria

2016-08-03T00:54:00+01:00

Chyba powoli łapie, czyli na przykład tak:
Tworzę sobie strukturę, gdzie umieszczam interesujące mnie rzeczy (adres odbiorcy/ ew.nadawcy (dla multi master), funkcje, dane, crc itp). Stringi to po prostu tablice, więc po zarejestrowaniu zdarzenia, wykorzystuję funkcję uart_get_str i odbieram sobie z tego bufor, potem już tylko przepisuje do poszczególnych miejsc w strukturze wybrane bajty danych. Dobrze to rozumiem?

Natomiast nie łapie po co w funkcji uart_get_str występuje linijka *buf = 0;
Coś czuje, że to jakiś banał i muszę sobie przypomnieć co nieco o wskaźnikach.

Dobra chyba to też łapie, ale proszę mnie sprawdzić:
W momencie przekazania bufora do funkcji, wskaźnik ustawia się na adres pierwszego elementu C-stringa, potem dalej w funkcji pod wskazany adres wpisuje się wartość pobrana z bufora cyklicznego, potem działa postinkrementacja i tak w kółko aż do znaku CR, za if'em wartość ostatniego elementu tj CR zostaje zmieniona na zero, i tym sposobem formowany jest czysty C-string, bez znacznika końca, tak?

Statystyki: Napisane przez Jatsekku — 3 sie 2016, o 00:54

Re: Transmisja szeregowa, protokoły - teoria

2016-08-02T16:50:38+01:00

Jatsekku napisał(a):

Czy sensownym będzie podział ramki na dane i komendy za pomocą pętli for?

Pętla for nie ma nic wspólnego z dzieleniem ....

do parsowania tokenów służą specjalne wbudowane w C funkcje przede wszystkim podstawowa: strtok()

a jeśli masz ramkę o stałych długościach pól to po choinkę czymś dzielić po odczycie ? toż wystarczy odczytać bajty z odpowiednich miejsc w odpowiedniej ilości zgodnie z budową ramki

Statystyki: Napisane przez mirekk36 — 2 sie 2016, o 16:50

Re: Transmisja szeregowa, protokoły - teoria

2016-08-02T15:56:32+01:00

Hmm, przejrzałem jeszcze raz ten temat i się troszkę rozjaśniło Czy sensownym będzie podział ramki na dane i komendy za pomocą pętli for? - takie kopiowanie uwzględniające kolejność informacji zawartch w ramce, dobrze kombinuje ?

Statystyki: Napisane przez Jatsekku — 2 sie 2016, o 15:56

Re: Transmisja szeregowa, protokoły - teoria

2016-08-02T06:26:24+01:00

Jeśli masz komunikację ASCII gdzie ramka zakończona jest ENTERem to właśnie na tym oparte jest omawianie komunikacji RS232 w Greenbooku ... Tzn przykład poszerzony jest o komendy AT ale u ciebie sprawa dużo prostsza ... I nic nie trzeba poszukiwać w buforze cyklicznym on nie do tego służy ....

w pętli głównej masz zdarzenie
[syntax=c]char buf[100]; // bufor na odebrane stringi z bufora cyklicznego

int main( void ) {

// rejestracja własnej funkcji parsującej
register_uart_event( parsuj_ramki );

sei();

// pętla główna programu
while(1) {
UART_EVENT( buf ); // zdarzenie UART
}
}

// własna funkcja parsująca
void parsuj_ramki( char * abuf ) {

// tutaj robisz co chcesz z odebraną ramką do której masz wskaźnik w abuf

}[/syntax]

czy może być coś prostszego ? .... Zdarzenia i callbacki nie są po to żeby utrudniać tylko żeby MEGA UŁATWIAĆ życie. To podejście do obsługi RS232 na zdarzeniach .. co w tym może być trudnego odwrotnie!... Rejestrujesz swoją funkcję (własną przez ciebie napisaną parsuj_ramki() w bibliotece) a w pętli głównej programu umieszczasz zdarzenie UART_EVENT(buf) ... i to zdarzenie samo wywoła po prostu ZAWSZE twoją funkcję gdy tylko nadleci pełna ramka. Zdarzenie samo wyjmie ją z bufora cyklicznego i wywołując twoją funkcję przekaże ci ślicznie całą gotową ramkę już bez znaku enter na końcu. Czysty string. Teraz go tylko podzielić .... No co może być trudnego w takim podejściu ?

Statystyki: Napisane przez mirekk36 — 2 sie 2016, o 06:26

Transmisja szeregowa, protokoły - teoria

2016-08-02T01:38:57+01:00

Witam

Właśnie próbuje sobie wymyślić założenia do nowego projektu, którego podstawą jest sieć złożona z jednego mastera i kilku slave'ów. Ramkę chciałbym sobie przyjąć na wzór modbusa ale jestem otwarty na propozycje. Generalnie to potrzebuje jakiegoś impulsu, żeby ruszyć dalej. Załóżmy, że ramkę mam taką :

Opis Hex ASCII l.bajtów
1.START 0x3A ":" 1
2.Adres 0xXX "XX" 2
3.Funkcja/Komenda 0xXX "XX" 2
3.Dane 0xXX... "XX..." n
4.LRC 0xXX "XX" 2 //Suma kontrolna z pominięciem znaczników START i STOP
5.STOP 0x0D "/CR" 1

No i teraz o ile dosyć łatwo byłoby coś takiego wysłać, to pytanie jak odebrać ?
Dajmy na to powstanie taka ramka :

0x3A 0x00001 0x0001 0x01 LRC CR

Odebrałem, mam w buforze cyklicznym i co potem?
Opieram się na tym źródle:
http://ktc.wieik.pk.edu.pl/kurs_avr/avr ... bsluga.pdf
Tylko nie specjalnie wiem jak dodać to przeszukiwanie bufora.
A może są jakieś lepsze metody?
Czy w GreenBooku są opisane jakieś patenty na to ? Widziałem, że jest tam parsowanie danych ale nie jestem pewny czy to to samo, poza tym jeszcze nie jestem na etapie eventów, callbacków itp a czas nagli ;/
Byłbym wdzięczny za jakiekolwiek wskazówki .

Statystyki: Napisane przez Jatsekku — 2 sie 2016, o 01:38