www.elektronik.si

[.:alex:.]

A je mogoče kdo iz foruma že delal kej z CAN-om v arm-ih!Ker bi mi prišla vsaka informacija v zvezi z CAN-om zelo prav!

[commander29]

Kaj te pa zanima?

[janiP]

CAN poznam precej dobro. Ne sicer v ARM-ih ampak logika je podobna.

Imam pa tudi kodo za CANopen, ki je zelo uporabna v raznih aplikacijah z mikrokontrolerji.


LP,
Jani

[.:alex:.]

Zanima me vse kar je povezano z CANom!
Ker sem se sedaj sam srečal z to zadevo in bi mi prov prišal kakšen del kode kjer ste uporabljali CAN!

[ciko]

Živjo!

Samo kodo boš moral nekje najdti na netu, kar se tiče uporabe in pojasnil, ti pa lahko pomagam. Jaz sem CAN uporabljal na PICih in LPCju vendar se razlikuje princip nastavljanja. Predvsem pri uporabi filtrov. Osebno mi je bil pri PICu bolj všeč, ker si resnično nastavil masko, medtem ko pri armu dodaš v tabelo IDje, ki jih želiš sprejemati. Zelo pomembno je, da ne dodaš v tabelo dvakrat isti ID. Pri prvih verzijah LPC2378 je prišlo do napake pri izvajanju kode. Mogoče so pri novejših verzijah to napako odpravili.

lp
Peter

[janiP]

Bom napisal nekaj o CAN-u:

CAN je bil originalno razvit za avtomobilska omrežja, kjer je več manjših senzorjev sporočalo svoje stanje. Eno CAN sporočilo lahko prenese do 8 bytov. Največje hitrosti prenosov so do 1 megabit na sekundo.

V vsakem sporočilu je vključenih še 11 (ali 29) bitov za naslov (identifier) in 15 bitov za CRC (kontrola napake), kar naredi CAN zelo varen in zanesljiv, posebno ker je CRC potrjen s strani vseh ostalih naprav v komunikaciji. Če ena sama naprava (med samim prenosom sporočila) ugotovi CRC napako, vse ostale naprave prezrejo sporočilo in le to gre v ponovno pošiljanje. Najboljše pri vsem tem pa je, da nam kot programerjem mikrokontrolerjev tega ni potrebno podrobno poznati, ker za vse poskrbi CAN modul znotraj mikrokontrolerja.

Še nekaj statistike: Če CAN omrežje dela pri 250 kbps 2000 ur letno, pri povprečni obremenitvi 25%, se neodkrita napaka pojavi enkrat v 1000 letih.

CAN naprave so ponavadi povezane med sabo ena za drugo s parico. Pri 1Mbps je maksimalna dolžina 40m, pri bolj običajnih 125kbps je dolžina 500m, pri 10kbps je nekaj km.

CAN je 'multi-master' omrežje. Katerakoli naprava lahko pošlje sporočilo kadarkoli. V primeru istočasnega pošiljanja dveh ali več sporočil, zmaga sporočilo z nižjim naslovom.

Sporočilo je poslano vsem ostalim napravam v omrežju. Od posamezne naprave je odvisno, ali je sporočilo z nekim naslovom zanjo zanimivo ali ne. Če ni, je filtrirano že na strojnem nivoju.

CAN se sedaj, poleg v prevoznih sredstvih, precej uporablja še v industriji, avtomatizaciji zgradb, itd.
Na osnovi CANa je razvitih nekaj više nivojskih protokolov, kot so: CANopen, DeviceNet, J1939, itd.

[vir za nekaj trditev je knjiga: Olaf Pfeiffer - Embedded Networking with CAN and CANopen]


LP,
Jani

[MarkoM]

[janiP]

Pa še nekaj o CANopen, s katerim se kar dosti ukvarjam:

Zamislimo si neko preprosto CAN omrežje: nekaj senzorjev na raznih mestih (vsak je svoja CAN naprava), nekaj aktuatorjev, kakšen krmilnik (ali dva).
Nek senzor je npr. skonfiguriran da periodično pošilja sporočilo o svojem stanju z naslovom 0x181. Drug senzor na naslovu 0x182, itd. En aktuator bo npr. sprejemal ukaz z naslova 0x201. Krmilnik bo sprejemal vse ukaze s senzorjev in pošiljal ukaze aktuatorjem.
Dokaj enostavna zadeva, ki v praksi precej zanesljivo deluje.

V praksi se pa stvari hitro začnejo nadgrajevati oz. komplicirati. Dobro je imeti možnost nastavljanja nekaj parametrov na posameznih senzorjih direktno s CAN vodila. Mogoče želimo nastaviti pogostost pošiljanja vrednosti s senzorja, ali pa naj se pošlje samo ob spremembi stanja. Želimo nastaviti, na katerem naslovu naj se pošilja stanje senzorja, itd.
Če se z napravo kaj čudnega dogaja, naj pošlje 'emergency message'. Naj periodično pošilja 'heartbeat', da druge naprave vejo, da je vse v redu.

Da ne bi z vsemi temi funkcionalnostmi ponovno 'izumljali kolesa', je dobro vedeti, da obstaja CANopen protokol, ki nam vse to omogoča.


CANopen je višenivojski protokol na osnovi CANa. Po eni strani je enostaven v smislu, da ne zahteva veliko nekih pravil za samo izvedbo protokola. Po drugi strani pa ponuja ogromno koristnih funkcionalnosti pri izvedbi omrežja. S svojimi 'device profili' se postavlja ob bok profibusu in tudi različnim industrijskim protokolom na osnovi etherneta.

Nekaj značilnosti:

Jedro CANopen naprave je 'Object Dictionary'. To je imenik spremenljivk, ki se uporabljajo za komunikacijo, za 'device profile' ali pa čisto poljubno znotraj naše aplikacije. Te spremenljivke so čisto navadne kot ji poznamo v C-ju: char, int, unsigned, lahko so arrayi ali celo strukture. Vsaka spremenljivka ima svoj index in subindex. Z nekim 'mastrom' lahko dostopamo do katerekoli spremenljivke na katerikoli napravi v mreži.
PDO sporočila so za prenašanja procesnih podatkov, npr. vrednost senzorja. Vsebujejo samo naslov in podatke, so praktično enaka kot 'navadna' CAN sporočila. Seveda pa jim je možno nastavljati naslov, vsebino, način pošiljanja (oz. sprejemanja).
Nadzor nad omrežjem: NMT in 'Heartbeat' sporočila.
Sporočila o napakah.
Sinhronizacija med napravami.
Na razpolago so razni 'device profili' za različne namene: npr.: za I/O module, za enkoderje, za pogone (nadzor hitrosti, momenta, pozicije, servo), dvigala v stavbah, vetrne turbine, fotovoltaika, itd.

Zdaj sem se pa razpisal
Sicer ne delam reklame za CANopen, sem se pa kar nekaj ukvarjal z njim.

Če koga zanima je na razpolago prosta koda za CANopen:
http://canopennode.cvs.sourceforge.net/canopennode/

Spisal sem jo, ko sem imel še preveč časa
Je pa precej profesionalno napisana in tudi deluje zelo zanesljivo na večih mojih projektih. Zaseda manjši del spomina mikrokontrolerja.

Trenutno je sicer napisana za dsPIC30F in dsPIC33F, je pa enostavno možno dodati tudi druge mikrokontrolerje, sploh LPCje. Seveda sem na razpolago za pomoč.


LP,
Jani

[alessio]

Zdravo Jani,

hvala za nekaj razlage o CANopen.

Delam sicer s CAN-om in LPC2000 na parih projektih z custom low level protokolom,
zaenkrat pa še nisem imel potrebe/zahteve po CANopen. Čeprav se to zna kmalu spremeniti...

Iskal sem url za checkout tvojega stacka-a iz SF CVS-ja, pa ga nisem našel. Ga lahko napišeš tukaj?

Sicer pa sem videl, da si zadevo licenciral z GPL. Mislim, da je to za embedded applikacije lahko faktor, ki bo večino odvrnil od uporabe tega stacka.

[janiP]

[alessio]

[.:alex:.]

Videm da vas je ker neki ki se oz. ste se že ukvrjali z can-om!V mojem primeru morem upoštevati J1939!Sedaj se spravim vse to pretuhtat potem pa vas začnem gnjavit

[ciko]

Še eno opozorilo:

LPC2378 ima napako v zvezi s CAN busom, kako je pa z ostalimi čipi pa ne vem. Če pride do zapolnitve bufferja se CAN bus zaklene in ne komunicera. Meni se je to zgodilo, ko sem debugiral (izvajanje kode je čakalo). Kako hitro se napolni buffer pri realnem izvajanju kode pa ne vem.

Lp

[ciko]

Kot sem že omenil, ima LPC2378 bug pri can busu:

Introduction:
Each CAN controller provides a double Receive Buffer (RBX) per CAN channel to store incoming messages until they are processed by the CPU. Software task should read and save received data as soon as a message reception is signaled.
In cases, where both receive buffers are filled and the contents are not read before the third message
comes in, a CAN Data Overrun situation is signaled. This condition is signaled via the Status register and the Data Overrun Interrupt (if enabled).

Problem:
In a Data Overrun condition, the CAN controller is locked from further message reception.

Workaround:
1. Recovering from this situation is only possible with a soft reset to the CAN controller.

2. If software cannot read all messages in time before a third message comes in, it is recommend to change the acceptance filtering by adding further acceptance filter group(s) for messages, which are normally rejected. With this approach, the third incoming message is accepted and the Data Overrun condition is avoided. These additional messages are received with the corresponding
group index number can be easily identified and rejected by software.

Za prejem sporočil (RX) sem uporabil IRQ z drugo najvišjo prioriteto, vendar mi še vedno pride do overruna.

Ali ima kdo napisano proceduro odpravljanja napak? Sam sem naredil, vendar ne deluje vedno:

[ciko]

Can bus sem uporabil, ker imam veliko prometa, no saj ob inicializaciji. Vzel sem primer od Keil-a, ga predelal. Vse lepo in prav, dokler nisem začel testirati na večjem sistemu. Sedaj se mi pojavljajo različne napake. Malo sem pregledal po datasheetu o can busu in zasledil različne načine delovanja CAN busa, različni mode-i. Posebaj mi je v oko padel FULLCAN mode.

Ali lahko kdo opiše ta način s preprostimi besedami, oz kdaj se ga uporablja. Sam sem imel nekoliko težav z razumevanjem.

Hvala
Lp