Svenska ElektronikForumet

På själva CAN nivån, så är ACK bara en bit i meddelandet.
Om en nod accepterade meddelandet så sätts ACK biten under denna
tid. Om det är flera noder så blir det ingen skillnad, men det måste
vara minst en nod, annars får sändaren ett "ACK-error", så vitt jag förstår.

Det skulle betyda att det normalt måste finnas *minst en* mottagare
av varje sänt meddelande.

ACK-fel genererar *inte* automatiskt omsändning, det hade ju varit lite
onödigt eftersom ingen "lyssnar" i alla fall...

Sen går det att sätta CAN modulen i "silent mode", då den enbart
lyssnar men skickar inga (t.ex) ACK eller error-frames, men det är ett
specialfall...

Omsändning sker automatiskt när ett "error" har detekterats.
Kan vara kollision, CRC eller liknande fel.

> Om inte sändaren vet vilka som skall ha meddelandet så vet den ju heller
> inte vilka den skall ha ACK ifrån.

Det ligger inte på "CAN-nivån", utan det är upp till överliggande applikationer
att hantera det. D.v.s ACK's på applikationsnivån.

Det ligger inte på "CAN-nivån", utan det är upp till överliggande applikationer att hantera det. D.v.s ACK's på applikationsnivån.

Hmmm. Men då måste ju istället applikationsnivån hålla rätt på vilka som ska ha dom olika meddelanden för att hålla koll på ACK. Då tappar man ju fördelen med ID:n för att inte behöva hålla rätt på vem som ska ha olika data. Jag tycker det blir samma sak fast bara en nivå upp.

Alltså, i de flesta fall kan sändaren skita i om någon "lyssnar" eller inte.
Den sänder ut t.ex en temperatur, och de noder som vill lyssnar.

Hur skulle du hantera om det är t.ex 5 noder som lyssnar på ett meddelande ?
Skulle det vara 5 *olika* ACK, ett från varje mottagare ?
Skulle det spela någon roll för sändaren om det bara är 3 st mottagare
som är "on-line" ?

Jag ser inte riktigt vad den ACK som du beskriver skulle ha för nytta.

Notera dock att man får ett "ACK-fel" om *ingen* nod lyssnar på ett visst
meddelande. Detta anses dock inte som ett allvarligt fel, eftersom
det inte triggar en *automatisk* omsändning. Ett antal andra fel (som
t.ex CRC) ger automatiska omsändningar...

Det sändaren kan göra är att tillfälligt stoppa sändningen av det
aktuella meddelandet (om den får ACK-fel) och starta igen när
det kommer ett "start-meddelande" för det aktuella datat. D.v.s att
en nod som vill lyssna på detta meddelande får sända ett start
meddelande när den startar upp (t.ex vid spänningstillslag eller reset).

I de fall där en node t.ex begär en uppgift från en annan nod, så
blir ju "ACKen" detsamma som att svaret kommer. Men notera att
svaret också bara är ett "meddelande" som skickas ut på bussen
för alla att lyssna på (om de vill). CAN ser alltså ingen skillnad
på "fråga" eller "svar", de är bara meddelanden (med olika ID).

ACK ska försäkra sändaren om att data har kommit fram till alla enheter som ska ha det och därför inte behöver sändas om. Om en mottagare får ett CRC-fel och felaktig data så vet den givetvis att den ska skippa den felaktiga datan. Men hur ska sändaren veta att den behöver skicka det igen? Det är ju bara mottagaren som vet säkert om den fått ett CRC-fel. Visst kan sändaren medlyssna på bussen och själv kontrollera checksumman men det är inget säkert tecken på vad som händer i andra änden av bussen.

Det här med att sända till flera olika enheter är just det som är intressant med den här tekniken. I dom flesta bussystem så sänds data separat med eget ACK till varje enhet somska ha det. Detta blir naturligtvis ineffektivt om många enheter skall ha informationen. Samtidigt så måste man ju försäkra sig om att data verkligen har kommit fram.

Att sändaren får felsignal om _ingen_ lyssnar säger ju egentligen inte ett smack eftersom den inte vet hur många som ska ha meddelandet. Kanske är det verkligen ingen som ska ha det och då är det inget fel. Eller så ska 5 enheter ha det och bara 4 har tagit emot det riktigt. Då är det ett fel trots att det inte indikeras som det.

> Om en mottagare får ett CRC-fel och felaktig data så vet den givetvis att
> den ska skippa den felaktiga datan. Men hur ska sändaren veta att den
> behöver skicka det igen?

(Vore kanske enklare att *läsa* lite om CAN...)

En mottagare som får t.ex ett CRC fel genererar automatiskt en "error-frame".
Denna "ser" sändaren (tillsammans med alla andra noder) och sänder om
meddelandet. Detta sker helt automatiskt inom/mellan CAN modulerna.

Se t.ex kapitel 23.14 i datablad 39637...

Sedär. Det var ny information för mig. Jag HAR läst en del övergripande om strukturen och hur CAN fungerar och där stod ingenting ö.h.t om det här. Det är ju definitivt viktig info som har med strukturen och uppbyggnaden att göra så man kan ju tycka att det iallafall borde stått något om det.

Jaja. Strunt samma. Tack för infon iallafall!

Jag tycker att CAN delen av databladet som jag nämnde
ger en bra intro till hur det (i alla fall i PIC'arna) är implementerat.
Och jag har svårt att tro att just t.ex detta om error-frames kan
avvika från CAN-standarden. PIC'arna måste ju rimligtsvis kunna
kommunisera med andra CAN implementationer.

I princip allt jag har refererat här kommer från ECAN kapitlet i :
http://ww1.microchip.com/downloads/en/D ... 39637c.pdf

Nej, det är säkert inget som avviker. Jag kanske skulle tittat specifikt på information till PIC:ar med CAN-buss istället för generell info. Min tanke vara att det borde vara bättre att börja förstå det generellt innan man går in på speciella enheter. Eller helt enkelt hittat bättre generell info!

Egentligen har jag inte haft så himla mycket tid att engagera mig i CAN ännu, utan det har mest varit att skrapa på ytan. Det här med ACK var då en grej som slog mig eftersom jag jobbar mycket med protokoll och kommunikation annars.