Using the CAN bus

[v8dave]

I am just about to start doing some development work on the CAN bus as part of my project and I have looked through the source and the documentation.

It seems that the supplied libraries don't allow me to control the sampling position based on the actual CAN bus I am running and instead accepts only a data rate as the setup parameter.

Does anyone know if I can call this to setup all the other parts of the CAN bus, such as initialising the CAN driver, interrupts etc and then I poke the registers myself with the correct settings. I am talking about the Propagation Segment, Phase 1 and 2, Sync Jump Width etc. I need to use the same settings to match with the 75% sampling point I am currently using with the other devices (SJA1000 and MCP2515) on the same bus.

Just wondering if anyone else has used CAN on the Netburners and if you have any thoughts or things to watch out for?

Thanks
Dave...

[roland.ames]

My experience with CAN has been with MOD5234 & MOD5282, which each have slightly different CAN controllers.

Have a look at c:\nburn\MODXXXX\system\canif.cpp. Specifically the function CanCalcClks(), which is called from CanInit(). You may have to write your own version of this function.

There is a Freescale document AN1798 which is worth reading.

[v8dave]

Thanks Roland,

I'll away and download the data from the Freescale website. I am considering writing my own functions or to add functionality as required. Once I see the register arrangement for the CAN perphheral I can work it out.

Cheers for the heads up on the App Note.

Dave...

[oleg_osov]

Hello!

In order not to create excess topics I would like to ask in this one. I need to develop a highly portable/cross-platform library (or program) with pure ANSI C to communicate with devices via CANopen protocol. My employer insists on using NetBurner hardware with Ethernet port. My idea is to implement CANopen stack in my program and communicate with NB module via TCP (or UDP?). And NB module should simply forward requests from Ethernet interface to CAN interface and vv. Is this correct architecture? Which module is most suitable for this goal? Mod5234, Mod5282 or CB34EX? Is such a functionality as forwarding Ethenet <==> CAN is implemented already in NB modules or should I implement it myself? Is it hard to communicate with CAN bus? I have only general knowledge about CAN/CANopen protocols, and want to know more about it. Some additional CAN-related questions:
1. Who should calculate CRC of CAN-frame? Application or the CAN-adapter?
2. Who should care about bit stuffing?

Or an application should supply only "Arbitration field (COB-ID + RTR bit)" + "Data field" and all remain work will be fulfilled by the CAN-adapter? Arbitration field is 12 bits long (11 bits header + RTR bit) and I don't know how to send 12 bits. Should I send 16 bits (2 bytes)? All additional fields like SOF, EOF, ACK, Control etc are created by CAN-adapter or by the application itself?



Could anyone provide me a short fragment of code which composes and sends a CAN-frame if it's not prohibited by a license agreement.

I'm potential user of NB software/hardware and should make a decision about programming man-hours.

P.S. Sorry for these newbie questions and for my bad english - it's not my mother language.

[v8dave]

1. Who should calculate CRC of CAN-frame? Application or the CAN-adapter?
2. Who should care about bit stuffing?

Or an application should supply only "Arbitration field (COB-ID + RTR bit)" + "Data field" and all remain work will be fulfilled by the CAN-adapter? Arbitration field is 12 bits long (11 bits header + RTR bit) and I don't know how to send 12 bits. Should I send 16 bits (2 bytes)? All additional fields like SOF, EOF, ACK, Control etc are created by CAN-adapter or by the application itself?

Hi there,

You don't need the worry about the CRC or bit stuffing etc. The CAN controller takes care of that for you. All you have to do is load up the registers with the required data bytes (up to 8), then length of your data, 0 to 8 bytes and the ID. The RTR bit is only needed it you are doing a remote request. After you do this and tell the controller to send the data, off it will go trying to send the data for you. It will handle the error and retries etc.

The real issue you will have is and I suggest you learn this bit first, is getting your head around the PHASE SEGMENTS, JUMP WIDTH, SAMPLING POINT etc as once you know how this works you will be able to programme your CAN controller to match the intended bus speed and format you are using. It took me a fair bit of reading and understanding to fully understand how this works but well worth the effort in the end.

As for code, there are a number of library functions within Netburner that will do all the sending and receiving for you. Maybe one of the Netburner staff could send you one of the CAN bus samples as a way to understand how it works.

I am busy writing code to make it work on my Netburner and so far it has been trouble free but then I have worked hard to understand how CAN actually works.

Good luck with your project.

Dave...

[lgitlitz]

Take a look at the run-time library documentation (http://www.netburner.com/downloads/ndk/ ... raries.pdf)
Chapter 3 shows the available CAN functions and there are a few code snippets. Actually there are an additional 2 or 3 functions that need to be added to this document that relate to sending and receiving RTR messages. The NetBurner CAN library is meant to be able to communicate on the CAN peripheral without having to write code that interfaces with the peripheral registers. It is still a very low level CAN driver and does not implement any of the higher level CAN standards such as CANOpen. Real Time Automation, a NetBurner partner, does have a complete CANOpen solution if you wish to go that route (http://www.netburner.com/products/indus ... nopen.html).

I would probably go with one of the 5234 products. These are newer processors then the 5282. The 5234 products have 4x the flash memory, 2.5x faster CPU and consume less power. The CAN peripheral has also had some changes since the 5282. Freescale usually keeps the peripherals pretty consistent between processors so I assume they had a good reason for the changes. Unless there is something specific on the MOD5282 that you need such as A/D there really isn't any benefit.

The MOD5234 and CB34EX have the same CPU, RAM, flash and Ethernet PHY. The same base code is easily compiled on both products. The CB34EX advantages are that it has an enclosure, a built in switching power supply with a wide input range, industrial connectors and 232/485/CAN line drivers. If the CB34EX provides everything you need hardware-wise then this will be the easiest and fastest path to a final product. The advantage of the MOD5234 is that it brings out many of the CPU pins directly to the 100 pin header. If you want to add a module to a larger circuit design then you need to go the module route. The module route allows you to interface directly with other digital devices through the parallel data bus, I2C, SPI, digital UARTs, eTPU, GPIO... ext. You also can then take advantage of the flash file system included in the NNDK to interface with SDHC or Compact Flash cards.

-Larry

[oleg_osov]

Hi, Dave!

You don't need the worry about the CRC or bit stuffing etc. The CAN controller takes care of that for you.

Glad to hear it. Is it feature of all CAN-adapters or only NB-shipped adapters have this feature?

All you have to do is load up the registers with the required data bytes (up to 8), then length of your data, 0 to 8 bytes and the ID. The RTR bit is only needed it you are doing a remote request.

Ok, it's clear for me except RTR bit. How should I transmit it?

Example - sending SDO request to slave node 1:
"COB-ID" = 0x601 (110 0000 0001) = zero padded (0000 0110 0000 0001)
"Data" - up to 8 bytes

I suppose that COB-ID should be transmitted in two bytes. In the previous example arbitration field is equal to COB-ID, but how to add RTR bit? Shift all bits to 1 position left?

The real issue you will have is and I suggest you learn this bit first, is getting your head around the PHASE SEGMENTS, JUMP WIDTH, SAMPLING POINT etc as once you know how this works you will be able to programme your CAN controller to match the intended bus speed and format you are using.

Hmm, it's pretty low level knowledge. It worth using it but at my 1st step I have more than enough to learn =)

Good luck with your project.

Thank you very much for your time and your help. You look very competent in this area, don't you mind if I ask you several questions when I begin my concrete work? The main problem of my situation is - I'm more than 6000 km away from the device, so the only way for me - is to work via internet.

*************************************************

Hi, Larry!

Take a look at the run-time library documentation (http://www.netburner.com/downloads/ndk/ ... raries.pdf)
Chapter 3 shows the available CAN functions and there are a few code snippets.

Thank you very much for this doc! I looked through code fragments and now it's clear for me how to set RTR bit =)

It is still a very low level CAN driver and does not implement any of the higher level CAN standards such as CANOpen.

I understand this - my aim is to implement CANopen by my own.

Real Time Automation, a NetBurner partner, does have a complete CANOpen solution if you wish to go that route (http://www.netburner.com/products/indus ... nopen.html).

Very interesting company, thank you for the clue, but I have implemented tens of industrial communication protocols and I have to implement CANopen myself. CANopen is a quite hard to implement due to its speed, a complex structure of its object dictionary and unsolicited messages. Except these things it's like other industrial buses.

I would probably go with one of the 5234 products. ...

Thank you for such a detailed explanation!

************************************

Some CANopen related questions:
1. Should I read device's object dictionary, or provided EDS file will be enough?
2. What is the function of RX-PDO? It's all clear for me with TX-PDO, but RX-PDO? Are they used only to exchange data between two slave modules?

[oleg_osov]

It is still a very low level CAN driver and does not implement any of the higher level CAN standards such as CANOpen. Real Time Automation, a NetBurner partner, does have a complete CANOpen solution

I thought about CANopen on NB and came to a conclusion that a correct solution is to implement CANopen on a NetBurner itself, not on a remote machine which communicates via UDP/TCP with NB hardware.
I read about a CANopen solution from RTA, but I don't understand an architecture of their software. CANopen is implemented on NB, and what? How they transfer data on remote machines? Via other simpler protocols like OpenModbus/TCP? If I'm right then it's a sort of non-universal solution IMHO.

[oleg_osov]

Hello, hardware gurus!

I'll try to ask here too as this question is very important to me.

First of all - I'm using NNDK-MOD5234-KIT.

I would like to get an explanation of a CAN example:

Code: Select all

int chan1 = RegisterCanRxFifo( NormToNbId( 0x123 ), &fifo );

In all examples and in canif.cpp I see this 0x123 id. I'm a bit puzzled - which Id should I use to receive all messages from the bus? 0x0 or 0x7FF ?

And a couple other questions:
If I have main loop where I read all messages with the code:

Code: Select all

CanRxMessage can_msg( &fifo, TICKS_PER_SECOND * 5 );

what is the best way to send RTR message? Create a new CanRxMessage instance with:

Code: Select all

CanRxMessage( DWORD id, WORD timeout );

like

Code: Select all

CanRxMessage rtr_msg( 0x482, 5 );

Is it a good approach? And why do I need to wait until I get a response on my RTR message? I think it's better when I have a main loop where I read *all* messages from the bus?

[v8dave]

Hi Oleg,

I am not sure what protocol you are using this with but you don't need to send any RTR message unless the device on the bus requires this. Depending on the protocol used, most devices will simply send their data as required.

For instance, the bus system I use here for power monitoring I have both time triggered data on the bus and on change data. The on change data gets transmitted as it aquires a new pulse form the Kw meter. The time triggered events are used to broadcast temperauture every 500ms. Other event messages are used to switch power on and off.

Can you give us more information about the devices on your network? Is this CANOpen or DeviceNet etc? Or is it a home grown system?

Dave...