Jag har byggt en fyrkantsvågsgenerator som kan styras från PC'n genom att skicka två byte med data via serieporten till uC'ns uart. uC'n tar hand om datat och ställer om frekvensen därefter.
Istället för att skicka två byte på vinst och förlust tänkte jag implementera något sorts protokoll, om inte annat kan det vara bra att ha för kommande projekt.
Jag har tittat lite på X-modem, och det verkar vara nåt sådant jag söker.
http://www.atmel.fi/dyn/resources/prod_ ... oc1472.pdf
X-modem var dock kanske lite väl avancerat. Finns det flera standarder eller hittar man bara på nåt eget som man tycker verkar bra?
Protokoll PC - uC
-
thepirateboy
- EF Sponsor
- Inlägg: 2109
- Blev medlem: 27 augusti 2005, 20:57:58
- Ort: Borlänge
Finns drösvis med standarder.
Ofta väljer man väl en standard som "passar in" i produkten. Ska du till exempel styra ett labagg så har man antagligen andra behov än om du ska kommunicera med elektroniken i en bil...
Såvida du inte har några kompabilitetskrav (typ att du ska kunna koppla in något annat än just en pc för att styra utsignalen eller att det skall kunna sytras från något visst program) så är det väl bara att kika runt på olika protokoll, välja ett... eller bara hämta inspiration från flera protokoll och koka ihop ett eget.
Ofta väljer man väl en standard som "passar in" i produkten. Ska du till exempel styra ett labagg så har man antagligen andra behov än om du ska kommunicera med elektroniken i en bil...
Såvida du inte har några kompabilitetskrav (typ att du ska kunna koppla in något annat än just en pc för att styra utsignalen eller att det skall kunna sytras från något visst program) så är det väl bara att kika runt på olika protokoll, välja ett... eller bara hämta inspiration från flera protokoll och koka ihop ett eget.
Jag gör sånt själv, X-modem är från de gamla dagar där man ringde upp en BBS och överförda filer.
Protokollets komplexitet beror ju på vad du ska styra, om det enbart är en frekvensgeneretor kan den ju vara mycket primitiv, ska du styra en uppsjö av enheter (nätdelar, generatorer osv) ska den ju vara en del mer utbyggd.
Här fungerar det bra med en STX som markering av "start på block", sedan kan du t.ex. ha frekvensen i "klarspråk", t.ex. "12400" och sedan en ETX som uttryck för att kommandot ska behandlas.
Detta kan man skicka manuellt om man vill, man kan skicka andra data och ändå få rätt funktion osv.
Protokollets komplexitet beror ju på vad du ska styra, om det enbart är en frekvensgeneretor kan den ju vara mycket primitiv, ska du styra en uppsjö av enheter (nätdelar, generatorer osv) ska den ju vara en del mer utbyggd.
Här fungerar det bra med en STX som markering av "start på block", sedan kan du t.ex. ha frekvensen i "klarspråk", t.ex. "12400" och sedan en ETX som uttryck för att kommandot ska behandlas.
Detta kan man skicka manuellt om man vill, man kan skicka andra data och ändå få rätt funktion osv.
X-Modem är väl egenteligen bara ett Protokoll som talar om för processorn när data börjar och slutar.
Det du måste göra är att skriva ett protokoll för de data du vill använda, dvs beskriva vad de data du skickar skall göra, om du sedan använder X-Modem eller nått annat är väl rätt trivialt gissar jag.
Enklast är väl att bara skicka data över linan och använda mjukvaruhandskakning samt 8N1
Det du måste göra är att skriva ett protokoll för de data du vill använda, dvs beskriva vad de data du skickar skall göra, om du sedan använder X-Modem eller nått annat är väl rätt trivialt gissar jag.
Enklast är väl att bara skicka data över linan och använda mjukvaruhandskakning samt 8N1
http://en.wikipedia.org/wiki/IEEE_488
är en typ av instrumentbuss.
Annars så är klartextmeddelanden bättre än binärformat så länge man inte måste spara bandbredd.
Du kan t.ex. använda enter för säga när ett nytt kommando kommer
är en typ av instrumentbuss.
Annars så är klartextmeddelanden bättre än binärformat så länge man inte måste spara bandbredd.
Du kan t.ex. använda enter för säga när ett nytt kommando kommer
Det blir nog lite för komplicerat, bl.a. då man måste ha speciella kretsar som hanterar bussen.
IEEE488 beskriver den elektriska konfigurationen samt vissa grundläggande kommandon för handskakning etc, det är sedan upp till varje implementation att göra vad de vill, följdaktligen finns det i princip ett protokoll för varje instrument som är implementerat.
Lättast är att använda seriel komm i detta fallet
IEEE488 beskriver den elektriska konfigurationen samt vissa grundläggande kommandon för handskakning etc, det är sedan upp till varje implementation att göra vad de vill, följdaktligen finns det i princip ett protokoll för varje instrument som är implementerat.
Lättast är att använda seriel komm i detta fallet
-
thepirateboy
- EF Sponsor
- Inlägg: 2109
- Blev medlem: 27 augusti 2005, 20:57:58
- Ort: Borlänge
Sökte på STX/ETX och hittade detta
http://avrfan.com/AVRlib/docs/html/group__stxetx.html
Det verkar intressant, ska kolla närmare på det. En checksumma och längd på data skulle jag vilja ha med i "paketet".
http://avrfan.com/AVRlib/docs/html/group__stxetx.html
Det verkar intressant, ska kolla närmare på det. En checksumma och längd på data skulle jag vilja ha med i "paketet".
uChip har några App, där de nätverkar en bunt PICar via I2C, där har man även tagit fram ett enkelt protokoll.
STX och ETX betyder bara Start of Transmission och End of Transmission.
Du måste definera ditt telegram (datagram)
Till ex:
Ett datagram kan se ut så här:
Där
STX är Start of Transmission = 8bitar
LEN är datagramlängden utan STX/ETX (eller med dessa)
TYP Typ av datagram
CMD Kommando
DAT data
BCC Checksumma
ETX End of Transmission = 8 bitar.
Du kan haturligtvis skapa datagrammet precis hur du vill, då det inte finns några regler hur det skall se ut, dock kan det vara lämpligt att skicka BCC sist då det är enklast att beräkna då.
Vidare måste du bestämma dig om det skall vara en fast eller variabel telegramlängd, den första är enklast, och då behöver du inte längden.
Har du blandat, fast eller variabel längd, kan det vara bra att använda TYP för att tala om det.
Skall du skicka både kommandon och data är det vettigt att dela upp dessa, därav både CMD och DAT i datagrammet ovan.
BCC dvs checksumman kan du beräkna på flera olika sätt, enklast är att XORa allting, skall du vara mer komplicerad använder du CRC, men det tycker jag är att skjuta lite över målet och komplicera sakerna lite.
XOR är det enklaste och snabbaste sättet.
På sändarsidan XORas alla ord, dvs
BCC = 00 XOR B1
BCC = BCC XOR B2 osv
Samma görs på mottagarsidan och jämförs med den skickade BCC'n
STX och ETX betyder bara Start of Transmission och End of Transmission.
Du måste definera ditt telegram (datagram)
Till ex:
Ett datagram kan se ut så här:
Kod: Markera allt
STX LEN TYP CMD DAT BCC ETX
STX är Start of Transmission = 8bitar
LEN är datagramlängden utan STX/ETX (eller med dessa)
TYP Typ av datagram
CMD Kommando
DAT data
BCC Checksumma
ETX End of Transmission = 8 bitar.
Du kan haturligtvis skapa datagrammet precis hur du vill, då det inte finns några regler hur det skall se ut, dock kan det vara lämpligt att skicka BCC sist då det är enklast att beräkna då.
Vidare måste du bestämma dig om det skall vara en fast eller variabel telegramlängd, den första är enklast, och då behöver du inte längden.
Har du blandat, fast eller variabel längd, kan det vara bra att använda TYP för att tala om det.
Skall du skicka både kommandon och data är det vettigt att dela upp dessa, därav både CMD och DAT i datagrammet ovan.
BCC dvs checksumman kan du beräkna på flera olika sätt, enklast är att XORa allting, skall du vara mer komplicerad använder du CRC, men det tycker jag är att skjuta lite över målet och komplicera sakerna lite.
XOR är det enklaste och snabbaste sättet.
På sändarsidan XORas alla ord, dvs
BCC = 00 XOR B1
BCC = BCC XOR B2 osv
Samma görs på mottagarsidan och jämförs med den skickade BCC'n
-
thepirateboy
- EF Sponsor
- Inlägg: 2109
- Blev medlem: 27 augusti 2005, 20:57:58
- Ort: Borlänge
