Förslag kommunikationsprotokoll...

[persika]

Vad säger den samlade expertisen här på forumet om detta ?
Bara på tankestadiet just nu.
Förslag på enkelt kommunikationsprotokoll,
RS-485 nätverk medmaster o slavar, dock kan masterrollen flyttas.

Kod: Markera allt

----------------------------------------------------
<ny rad><mottagar-adress><,><avsändar-adress><,><data><CRC><ny rad>

<,>
komma är avgränsare.

<ny rad> består av: CR+LF eller CR eller LF
ny rad startar avläsning av inbuffert och sedan tömmer buffert. 

<mottagar-adress>
<avsändar-adress>
adress i hexadecimala ascii-siffror, 'obegränsat' antal siffror.

<data>
varje data-byte som 2 hexadecimala ascii-siffror

<CRC>
16bit-crc i 4 hexadecimala ascii-siffror
ingen avgränsare mellan data och crc, 
så de fyra sista byten innan radslut är crc.

-------------------------
exempel:
sänding till 2 från 1 med 'HEJ' i data och 9999 som fejkad crc

2,1,48454A9999

om mottagning lyckats svarar 2 med 
1,2,[ACK]9999

om mottagning misslyckats pga crc-fel svarar 2 med 
för att undvika vänta på time-out hos 1
1,2,[NACK]9999

om inget svar kommer så blir det time-out hos 1 och sändningen göres om då ett antal gånger.

-------------------------
1 lämnar över masterrollen till 2
2,1,[NUL]9999

svar från 2 enligt exempel ovan
--------------------------

[Micke_s]

titta på http://www.hth.com/snap/

[persika]

Tack för länken. Jag kollade lite på SNAP.
Där är ganska många bitar och moder att hålla reda på.
Jag skulle vilja ha det ytterligare lite enklare.
Jag tänker att det skulle vara bra att ha kommunikationen i klartext (ascii), så man enkelt kan kolla i ett terminalprogram.

[Icecap]

Vilket protokoll som är enklast beror ju på vad du ska överföra och hur snabbt det måste gå.

Jag har själv vald ett textbaserat till mina projekt, jag kollade på SNAP och det är förvisso rimligt ospecifikt så att det duger åt en del saker men jag skulle aldrig använda det just för att det är alldeles för krångligt till simplare saker.

Jag har använt ett protokoll som är ganska enkelt:
STX (0x02) för att markera att "nu kommer det en block, sopa undan allt gammalt" = nollställer input pekaren.
Sedan kommer data med Funktion först, sedan adress (om det behövs), sedan data, allt separerat av ett lämpligt tecken (t.ex. ',') och till sist checksumman i hex.
För att avsluta ett block sänds en ETX (0x03) och när UART-Rx ISR'n "ser" detta tecken läggs allt inkommande i en buffer efter omvandling från text till värden och en "det har kommit ett meddelande"-flagga aktiveras varefter mainloop'en tar hand om detta.

Så det kan se ut som:
STX "14,76,FF" ETX (fast utan mellanslag och ")
Enkelt att se på terminalprogram, enkelt att skriva om man ska testa innan man har en annan enhet den kan kommunicera med (då brukar jag att disable checksum-kollen)

[persika]

Intressant!
Hur syns tecknen STX och ETX i terminalprogram ?
Hur ser det ut när nästa sändning kommer, hamnar den på samma rad ?
Därför tänkte jag att nyrad-tecken skulle funka bra som avgränsare mellan sändningarna. Ska inte ha nån betydelse om det är CR+LF eller bara LF eller CR, eftersom det finns olika inställningar för det i terminalprogram. Om det kommer CR+LF så kommer mottagaren först behandla det mottagna paketet, sen kommer det ett tomt paket mellan CR och LF, men det gör ju inget.
Kommunikationsprotokollet ska inte bry sig om innehållet i datat, mer än att den ska vara i "binär ascii-format".

[Icecap]

Fördelen som jag ser det är att det kan skrivas ut en massa mellan blocken (debug-utskrift) och likaväl kan kommunikationen fungera smärtfritt. Att ha CRLF som blockavdelare fungerar också men det är mer bök att ha 2-tecken avdelare.

STX och ETX ses som ett par små svarta huvuden, starta hyperterminal, välj "Lokalt Eko" och tryck Ctrl-B för STX och Ctrl-C för ETX, då ser du dom.

Jag använder det ganska ofta när man t.ex. bara har 1 serieport i ett projekt och om den kommunicerar med ett PC-program kan man sniffa (har byggt en sån grej) och se debug-utskrift på en annan serieport, väldigt praktisk.

[persika]

Jag provade ctrl-B och ctrl-C i Hyperterminalen, såg en svart gubbe och ett svart hjärta.

Verkar ju vara praktiskt att innesluta meddelande mellan STX och ETX, det går ju ändå att sända CRLF mellan paketerna, i "debug-utrymmet", så blir det lite mindre rörigt på terminalskärmen.

Då skulle det kunna bli så här:

Kod: Markera allt

<STX> <mottagar-adress> <NUL> <avsändar-adress> <NUL> <data> <NUL> <chks> <ETX>

Om man har Nul-tecknet (00h) som avgränsare, så ligger adresserna som färdiga strängar i bufferten.

Hur är det med checksumma jämfört med crc ? är crc så mycket bättre så det är värt mödan att programmera det i microcontroller.
Jag har använt 8-bit checksumma en del vid seriekommunikation (2400baud) mellan PIC och PC, det har funkat utan problem.

[Icecap]

LRC är inte lika "säker" som CRC då LRC kan visa rätt även om samma bit hänger medan CRC inte gör det.

MEN... hur ofta sker det? I gamla dagar då man hade externa UART kunde det fint hända men när det är en inbyggd UART anser _jag_ att sannolikheten för att en bestämt bit "hänger" är icke existerande! Och i det läge är CRC och LRC ganska lika i säkerhet, de visar båda OM paketet är fel eller rätt.

[vfr]

En tråkig sak med checksummor bestående av XOR eller enkla summeringar, är att en 0-byte inte påverkar checksumman ö.h.t. Vi har haft en del problem med det på gamla protokoll. Borttappade 0-byte detekteras inte av checksumman. I dom fallen så har det inte funnits längd med i paketet. Har man det, så kan givetvis inte ingen byte tappas utan att det märks. Men det påvisar ändå på hur bristfällig en sådan checksumma är. Jag skulle aldrig nydesignat ett protokoll utan riktig CRC idag. Jag har själv gjort CRC-16 för både PIC och 68HC11. Så himla komplicerat är det inte. Det finns mycket material att titta på ute på nätet.

[Icecap]

Och det är precis orsaken till att jag inte använder 0x00 som uppdelning av värden, jag använder ',' eller liknande.

[sodjan]

> Om man har Nul-tecknet (00h) som avgränsare...

Jag har alltid vid felsäkning av seriella överföringar sett ett <null> som ett
tecken på att något är fel. Det är inget bra teckan att ha med som en
förväntad del av protokollet. Personligen föredrar jag protokoll byggda
enbart på skrivbara tecken, det underlättar mycket vid felsökning. Jag
avslutar även gärna med <CR>, då rullar det snyggt vid loggning på
en terminal eller mot en fil...

[persika]

Rotade fram denna gamla tråd igen.
Jag letade efter hur CRC fungerar, hittade ett alternativ, Fletcher Checksum.
Någon som använt det ?

Det står så här om det:

In summary, Fletcher's checksum technique provides excellent error detection using a simple algorithm that can be implemented in only a few lines of code. Compared to CRC error detection, Fletcher's algorithm provides a comparable level of data integrity with a fraction of the computational effort. It's an excellent choice where high-link speeds must be achieved while using moderate- or low-performance computer hardware.

Länkar
1
2

Kod: Markera allt

_FLETCHER'S CHECKSUM_
by John Kodis


Example 1:

(a)

        integer i, sum1, sum2;

        sum1 = 0;
        sum2 = 0;
        for i from 1 to message_length do
            sum1 = ( sum1 + message[i] ) modulo 255;
            sum2 = ( sum2 + sum1       ) modulo 255;
        end for.


(b)

        check1 = 255 - (( sum1 + sum2   ) modulo 255);
   message[message_length+1] = check1;
        check2 = 255 - (( sum1 + check1 ) modulo 255);
        message[message_length+2] = check2;

[ie]

Gammal tråd, så det kanske inte är aktuellt längre men...

Det är inget bra att skicka NACK vid CRC-fel i det föreslagna protokollet, då du inte vet vart du ska adressera det. Felet i paketet kan ju ha varit i avsändaradressen. Det kan även ha varit så att paketet var adresserat till en annan nod och att det där gick fram rätt. Skickar du då en (felaktig) NACK så finns risken att du stör kommunikation som annars hade gått fram mellan två andra noder.

Sen beror det också på om det är okay att ett paket tas emot två gånger. Är det inte det (t ex om innehållet betyder ÖKA MED 5). Låt säga att paket 1 går fram korrekt men att ACK-paketet inte går fram, då kommer avsändaren att skicka om paketet. Ett sätt att hantera det är att inkludera någon typ av sekvensnummer på paketen.

Edit: Om jag inte minns fel så hade även SNAP felet att skicka NACK även vid CRC-fel. (Ett sätt att minska risken är att ha en separat CRC på huvudet.)

[persika]

Intressanta synpunkter.

Jag funderar på protokollet lite då o då.
Tänker mig nåt som är enkelt, som bara för över data på ett bra vis till flera olika noder på en lina. Ska vara någorlunda enkelt att programmera (på PIC).
Tanken är att kommunikationsprotokollet inte ska lägga sig i vad för sorts data som överföres, så sekvensnummer av får ligga i datadelen då.
Har funderat på när ett paket tas emot felaktigt så skickas inget svar, för att undvika felet du (ie) nämner.

Hittade nu senast om Fletcher-checksum, det verkar i det närmaste lika bra som CRC men betydligt mindre krävande.

[blueint]

Tipsar om http://en.wikipedia.org/wiki/Digital_Command_Control

Sedan kanske det är bättre med Preamble istället för CR/LF som inledande tecken?
Samt att allt ska ha korrekt CRC för att accepteras oavsett nod, riktning och tillstånd.
Ta en kik på hur Ethernet hanterar kommuniktion på bitnivå.