Kommunikationsprotokoll exvis. över CANbus, EIA485 osv.

[toffie]

Hej på er,

Har lite funderingar kring hur själva kommunikationen ser ut, jag vet att det är så kallade paket som skickas över dessa nätverk men hur puttar man ut dem egentligen?

Ett CANbus paket ser ju exempelvis ut något liknande, utan att jag egentligen tar hur det exakt ser ut;

Kod: Markera allt

0x0F 0x3F 0x4C 0x2D 0x55 0xBB 0x7F 0xF4 0xD3 0x3D 0xDD 0x32 0x87 0x99 0xF0

Säg att ett paket ser ut så, hur skickas det ut på nätverket? Om vi skippar helt det elektroniska och hårdvaran, endast mjukvara nu. Skickas det ut som en "text-sträng" som sedan samlas upp av slavarna som sedan klipper upp strängen och lägger i olika arrays för att sedan läsa av och tolka vad som ska göras?

Säg att 0x0F är startbiten, 0x3F till 0xBB är adressen, 0x7F är en kategori-byte, 0xF4 till 0x99 är instruktioner och 0xF0 är avslutningen. Skippar CRCn också, för den förstår jag i sammanhanget

Så, skickas detta som en text-sträng eller skickas det på något annat sätt? Jag menar, om man tar en logikanalysator och lyssnar av nätverket, skulle man exempelvis kunna se 0x0F 0x3F 0x4C ... Är det då detta man skickat ut "rent" från en MCU exempelvis?

Hoppas ni förstår, är lite stressad just nu för att jag ska iväg, så kan nog ha strulat ihop det eller nåt
Men jag hoppas någon förstår och kan klargöra lite för mig

Tack på förhand!


Edit
Har ändrat titeln till "Kommunikationsprotokoll exvis. över CANbus, EIA485 osv.", från tidigare "Kommunikationsprotokoll, CANbus, över EIA485 osv." // toffie

[baron3d]

Titta på:
http://en.wikipedia.org/wiki/CAN_bus
och
http://www.can-cia.org/index.php?id=164

[toffie]

Det besvarar egentligen inte mina frågor om hur man skickar ut informationen, hur det ser ut i koden som finns i MCU'n.. Jag är inte ute efter att få kod, utan snarare vad son faktiskt skickas ut från processorn.. CAN går ju visserligen via en hjälpkrets som ex mcp2515/51.. Men det är väl ändå ren seriell data någonstans?

[eqlazer]

Tycker Kvaser har en bra beskrivning av CAN, http://www.kvaser.com/en/about-can.html

toffie: Tror inte du ska blanda ihop CAN med hur man använder en vanlig UART. För CAN har man en kontroller där du skickar in ID, data och lite flaggor i olika register. Sedan tar kontrollern hand om sändning/mottagning.

[toffie]

Det var väldigt bra förklarat! Man tackar nae, kanske inte blanda ihop dem, men jag har inte lyckats förstå hur data skickas ut i nätverket.

CAN är ju förklarat rätt bra nu, men om man säger modbus då? Det går ju direkt på ett 485 nät, hur skickas data där? Det måste väl ändå vara ren text ex. 0x0F osv.. Eller?

Har kollat på kod men ändå inte lyckats förstå..

Det brukar oftast vara mycket mer kod som jag inte använder eller inte förstått mig på att använda än, så det blir svårt att ta reda på vart den rena "datan"finns, om det finns..

Jag vet ju hur jag kan lösa mitt 485 nät med data, men vill veta om jag gör någorlunda liknande vad riktiga standarder gör. Jag är inte ute efter att göra det kompatibelt med ex modbus. Men jag vill ju givetvis ta idéer

[H.O]

MODBUS finns i två varianter (tre om du räknar TCP), ASCII och RTU. I ASCII så skickas alla värden etc som läsbar text, dvs om en sensor raporterar värdet 100 så skickas det tre bytes innehållande ASCII värdet för ett, noll, noll (kan vara leading zeros, jag har inte kollat och aldrig syslat med ASCII-varianten). Om du kopplar MODBUS ASCII direkt till en terminal så kan du direkt läsa vad som skickas - "i klartext".

I MODBUS RTU skickas värdet som ett 16-bitars ord inehållande värdet 100, alltså två bytes. MODBUS RTU är således betydligt effektivare än ASCII-varianten eftersom det går åt färre bytes att överföra "samma" information.

Rent elektriskt, "på linjen", så är ju en nolla en nolla och en etta en etta. En byte=8bitar osv.

Men CAN är en helt annan sak än RS485, i CAN finns inbyggd prioritet etc så även om två enheter sänder samtidigt så är det meddelandet med högst prioritet som når fram, det kör liksom över det andra meddelandet, vilket också detekteras av sändaren av det lägre prioriterade meddelandet så att den kan sända om.

[sodjan]

> Det måste väl ändå vara ren text ex. 0x0F osv.. Eller?

Vad menar du egentligen med "ren text" ???
Notera att en mikrokonotroller eller en kommunikationslösning
inte har en susning om begrepp som t.ex "text".

Sen ger du "0x0F" som exempel på text, vilket ju knappast är text alls.
Om vi talar ASCII så är det styrtecknet SI ("shift in"). Men det kan ju
vara vad som helst med en annan valfri tolkning.

Eller menar du att man skickar "nolla-lillax-nolla-F" ?
Det ser ju också lite märkligt ut.

[toffie]

Först och främst, superbra svar båda två!

H.O
Det är precis det jag menar, har lite svårt att få fram vad jag är ute efter känner jag hehe

ASCII är vad jag menade med "ren text", där varje tecken består av en byte, 8 bitar och där man i slutändan om man kopplar direkt till en terminal kan få ut läsbar text i så kallad "klartext". (Borde skrivit ASCII från början )

I Modbus RTU skickas det ju då istället som hexadecimalt, korrekt? Det är väl 16-bitars ord? Så där det blir ett värde på "100" i decimalt, som är samma som ASCII? Så blir det 0x64 i hexadecimalt, det stämer väl?

Så summan av de två meningarna blir att antingen kan man skicka ut 100 rent på bussen med ASCII eller så skickar man ut 0x64, right? Men det är det senare, dvs 0x64, som jag undrar hur man skickar ut redan mjukvarumässigt. Eftersom Sodjan menar att det ser lustigt ut med att skicka ut 0x64 som ren text, dvs nolla-lillaex-sexa-fyra så förmodar jag att det inte är så man gör.

Menas det istället att man gör om 0x64 till decimalt, dvs 01100100 och sedan lägger ut det i en ren elektrisk signal på nätverket? Alltså, låg-hög-hög-låg-låg-hög-låg-låg ? Om det är så fallet är så förstår jag det helt och fullt, för det är ju rätt smart.

Men...!
Är det inte det RS232/485 kretsar egentligen gör? Jag menar, det är väl ganska så, egentligen, rejält, väldigt, svårt att göra i mjukvaran på ett UART interface som är det man använder för att kommunicera med RS232/485 kretsarna..? Jag menar, det är ju mer eller mindre ren text som är det enda som går att skicka ut från en UART, eller har jag fel?

Så om man då ska skicka ut hexadecimalt 0x0F, hur gör man det då över UART? Ska man åsidosätta UART rutinen och börja bit-banga ut information på pinnarna? Fast det å andra sidan är ju också vad rutinen för UART gör, den tar ju min rena text och gör om till 1-or och 0-or och sedan finns det en mottagare som gör om 1-or och 0-or till ren text, dvs ASCII igen?

Det känns verkligen krångligt att förklara, ni kan ju allt, men jag försöker förstå
Säg att jag vill skicka ut just följande kod med Modbus RTU protokollet;

Kod: Markera allt

0x0F 0x3F 0x4C 0x2D 0x55 0xBB 0x7F 0xF4 0xD3 0x3D 0xDD 0x32 0x87 0x99 0xF0

Man skickar det inte då som en loop av ASCII tecken ut på UART'en?


Känner att jag behöver ett avslut liknande Sodjans, "eller menar du"..
Eller tänker ni på hårdvaru-nivå nu, alltså hur det elektriska ser ut? Signalen på ett skåp?

Vi kan skippa CAN helt och hållet eftersom det verkar vara ett mer eller mindre klart fack-verk där man har olika hål där man pluttar in data som adress, innehåll osv, medan det sedan ligger utanpå fack-verket ett helt system som lägger på massa annan information för att skapa paketen?


Hur som helst, det känns som jag har fått mer klarhet i hur det fungerar, om jag nu fått mina påståenden ovan rätt förstås

Hoppas jag inte gjort det mer snurrigt nu


Edit..
Just ja, en annan fråga om det här med kommunikationen, kan man på något sätt mäta hastigheten med antingen ett skåp eller möjligen en frekvensräknare? Jag tänker mig att man skickar ut ett.. ja helt paket kanske så snabbt man kan i en loop. Skulle det då gå att se hur snabbt det blir på något sätt? Eller kommer den räkna på varje 1-a och 0-a, då kommer man ju få en illusion av att det går mycket snabbare än vad det egentligen gör, inte sant?

[sodjan]

> I Modbus RTU skickas det ju då istället som hexadecimalt, korrekt? Det är väl 16-bitars ord?
> Så där det blir ett värde på "100" i decimalt, som är samma som ASCII? Så blir det 0x64
> i hexadecimalt, det stämer väl?

Jag vill påstå att du har helt fel uppfattning om vad "hexadecimalt" är...

> Menas det istället att man gör om 0x64 till decimalt, dvs 01100100...

För det första så är 0x64 och 01100100 *exakt samma sak* !
Och inget av dessa format är "decimalt" !

Du måste skilja på faktiska värden (som t.ex 0x64 och 01100100) å ena sidan
och *representation* av dessa (som "hexadecimalt", "decimalt", "binärt", "ASCII" o.s.v)
å andra sidan.

> Jag menar, det är ju mer eller mindre ren text som är det enda som går att skicka ut från en UART, eller har jag fel?

Ja, det har du.
En UART har så klart inte en susning om vad "ren text" är !
En UART skickar enbart de 8-bitars bytes som den blir ombedd att skicka.
Att du och jag sedan välja att *TOLKA* detta som ASCII (eller "ren text") har
inte ett smack med UART'en i sig att göra.

Du måste styra upp tankearbetet lite kring detta, annars blir det aldrig något ordning på det.

> Så om man då ska skicka ut hexadecimalt 0x0F, hur gör man det då över UART?

Vad vill du skicka ? 00001111 ? Eller "0F" (alltså "nolla-F") ?
Oavssett vkilket så skriver man det till UART'ens sänd-register. I princip...

> den tar ju min rena text...

Nej, nej, nej, nej, nej, nej, nej, nej......

> som gör om 1-or och 0-or till ren text, dvs ASCII igen?

Nej, nej, nej. Det är *DU* som tolkar det som text/ASCII.

> Man skickar det inte då som en loop av ASCII tecken ut på UART'en?

Nej, du skickar exakt det som du visade via UART'en.
Glömt allt som har med "text" eller "ASCII" att göra.

> Just ja, en annan fråga om det här med kommunikationen, kan man på något sätt mäta
> hastigheten med antingen ett skåp eller möjligen en frekvensräknare?

Ja visst! Titta på signalen på ett skop och räkna om tiden för en bit till bit/sek.

[H.O]

För att bygga på sodjans excellenta svar...
Om du skickar en byte med din UART, vad är det för skillnad på 'A', 65, 0b01000001 och 0x41?
Just det, ingen skillnad alls - varken för processorn eller UART'en och 'utsignalen' från UART'en kommer vara exakt den samma i samtliga fall. Det är bara OLIKA SÄTT att beskriva samma sak, nämligen värdet 65 (decimalt).

Om din applikation är gjord för att 'tolka' ASCII så 'betyder' 65 just 'A' och det är således vad som kommer skrivas på skärmen om det var exempelvis en terminal. Om du vill skicka ett 'värde' (variabel) från din CPU och presentera det som 'ren text' på en terminal måste du omvandla 'värdet' till dess ASCII representation och sedan skicka.

En byte kan ju innehålla värdet 0-255, låt oss säga att den innehåller just 65. Om du skickar det till terminalen så visar den A medan du egentligen ville visa 65. Du måste alltså få din CPU att via UART'en skicka först en sexa och sedan en femma eller 54 , 53 vilket är ASCII-koderna för tecknet 6 respektive 5. Om värdet av variabeln var 123 så måste du alltså skicka tre bytes för att det ska presenteras som just 123 på terminalen. Skickar du EN byte innehållande värdet 123 får du tecknet {

Så, det gället alltså att båda (eller alla) ändar pratar samma språk så att säga, precis som med MODBUS ASCII vs RTU, det är i princip samma information som skickas men de skickas på olika sätt.

EDIT: 0b10000001 är inte lika med 0x41....

[sodjan]

> vad är det för skillnad på 'A', 65, 0b10000001 och 0x41?

Tja, de menar förrutom att 0b10000001 = 0x81 ?

[H.O]

Oh crap, en nolla för mycket där...jag editerar.
Tack sodjan!

[toffie]

Tack Sodjan och H.O!
Nu känns det otroligt mycket klarare!

När jag skrev 01100100 så var det binärt jag menade, för det stämmer väl? Har gått elektronikutbildning under hösten och
blandar redan ihop allt super! hehe.. Har ju visserligen hållt på med det ett par år redan, så jag blandar förhoppningsvis bara ihop namnen. Jag kan ju iaf räkna emellan dem

Givetvis så har inte UART'en något med vad man skickar och vet självklart inte vad "ren text" är för något. Jag menade bara att man bestämmer ju inte själv när pinnarna där ska gå höga eller låga, mer än att man skickar in data i UART registret som sedan drivaren gör om till 1-or och 0-or.

Vad jag alltså behöver göra är att om jag exempelvis vill skicka ett paket liknande, i ASCII;

Kod: Markera allt

0x0F 0x3F 0x4C 0x2D 0x55 0xBB 0x7F 0xF4 0xD3 0x3D 0xDD 0x32 0x87 0x99 0xF0

Så behöver jag skriva kod för att plocka isär de bitarna till binärt exempelvis och använda värdena därifrån, både i min AVR (förlåt Sodjan ) och i ett program på datorn. Visserligen så kan de ju använda i stort sett om inte exakt samma kod för nedbrytningen av paketet.

Om jag istället skickar det rent av som bytes, så behöver mottagarprogrammet i processorn och på datorn kunna tolka det rätt och inte omvandla det automatiskt till ASCII värdet av den mottagna byte'n?

Jag tror det är lite av anledningen till min förvirring, eftersom jag är ganska ny på denna del av programmeringen så vet jag ju inte riktigt hur jag ska konfigurera ett terminalprogram. Så när jag egentligen har skickat en byte som jag tror ska komma fram som en byte, så har jag istället fått ASCII värdet och då blivit förvirrad


Någon idé om något terminalprogram för windows som klarar av att visa inkommande bytes och inte automatiskt omvandlar till ASCII kod? Har kört lite med Putty men har inte listat ut ifall det går att göra där.

[thepirateboy]

Du kan använda bray terminal så kan du titta på data som ASCII, dec eller hex. Kanske klarnar det då.
https://sites.google.com/site/terminalbpp/

Du kan även skicka "hex-data" genom att sätta ett dollartecken framför, t ex $0F$3F$4C$2D$55$BB$7F$F4$D3$3D$DD$32$87$99$F0
för att skicka strängen ovan.

[toffie]

Underbart!
Tack thepirateboy!