Stránka 2 z 2
Napsal: 11 bře 2017, 21:16
od paycz
Cowley píše:Treba pokud se data ztrati ci jinak preslechnou, tak ztratis synchronizaci.
tak to stačí data poslat zpátky a porovnat je mezi sebou ne ??
Napsal: 11 bře 2017, 21:19
od Cowley
Je lepsi pouzit a poslat definovany startbyte, potom poslat data a nakonec poslat CRC kod.
Napsal: 11 bře 2017, 22:14
od frpr666
Nemusí se ani ztrácet bajty.
Ke ztrátě synchronizace dojde už jen tím, že "vysílání" z PC se zahájí v jeden okamžik a arduino "přijem" v druhý okamžik.
Tuším, že arduino, na "pozadí" v přerušení, všechny příchozí bajty schovává do kruhového bufferu (64bajt?) a jakmile je plný, tak se zapisují zase od začátku.
Serial.read(), který uživatel volá v loop(), vrací jeden znak z tohoto bufferu.
Serial.read() Returns
the first byte of incoming serial data available.
Napsal: 12 bře 2017, 21:05
od paycz
nakonec jsem to udělal tak že pošlu data z PC a data pošlu zpět pokud se data rovnají tak pošlu string write a v arduinu mám
Kód: Vybrat vše
if(Serial.readString() == "write")
{EEPROM.write......
}
else if ((Serial.readString() == "error")
{
bytes = 0;
memset(recdata, 0, sizeof(recdata));
bool read = true;
}
if(read == true && bytes <=9)
{
....
}
a když pošle C sharp "error" tak počká 5 sekund aby se arduino vrátilo zpět na čtení a odešle data znovu... funguje to uplně bombově
Napsal: 15 bře 2017, 13:03
od mtajovsky
Tak se to nedělá. Jednak je tu zbytečný přenos dat zpět, zbytečné povely "write" a "error" a tohle všechno se taky může přenést s chybou. A čekání 5 s je strašně dlouhá doba, to se všechno při rušení přenosu šíleně zpomalí.
Samotný přenos přes RS232 je jen fyzická vrstva a pro zabezpečení je potřeba nějaký protokol. Protože jde o přenos bod bod v režimu master-slave, vystačíme si s jedinou linkovou (logickou) vrstvou. V nepříznivém případě - data je třeba vždy přenést spolehlivě a při přenosu se vyskytují chyby, je možný následujcící scénář:
- na začátek dat master vloží startující znak, nejčastěji STX = 0x02; pro binární přenos se může vynechat
- následuje variantně délka dat pro binární přenos
- následují buď binární data v indikované délce nebo textová data ukončená znakem ETX = 0x03
- nakonec je vložena konrolní suma pevné délky
- přijímač pomocí délky dat nebo příchodem ETX pozná, kde je konec zprávy a může zkontrolovat CRC
- přijímač v přerušení nebo poolováním přijmá znak po znaku až dosáhne konec zprávy
- na začátku příjmu si nastaví časovač, který hlídá maximální dobu přenosu, například 100 ms nebo si přijímač hlídá dobu přenosu průběžně při příjmu dat
- po příjmu zprávy přijímač časovač resetuje; pokud časovač vypršel dříve, znamená to, že se přenos nějak zaseknul nebo že přijímač začal přijímat uprostřed rozvysílané zprávy
- v tomto případě odpoví na vysílací stranu chybovým kódem - nedokončená zpráva
- pokud je zpráva přijatá celá, ale nevyšla CRC odpoví se příslušným kódem
- v případě úspěšně přijatých dat přijímač data zpracuje a odpoví potvrzovacím kódem - tím myslí se buď krátká potvrzovací zpráva nebo nějaká data získaná zpracování přijatých dat
- vysílač ošetří příjem odpovědi stejným způsobem jako přijímač, ale v případě chyby vypršení svého časovače neposílá chybovou repliku, nýbrž zprávu opakuje. Zprávu opakuje i při příjmu chyby typu CRC nebo nedokončená zpráva.
- pokud by bylo na závadu opakování stejných dat, je třeba vysílaná data opatřit inkrementálním čítačem s přetečením, aby přijímač ignoroval opakovanou zprávu v důsledku nepřijetí potvrzení vysílačem. Opakovaná zpráva má stejný čítač, nová data mají inkrementovaný.