Go Down

Topic: Building a CAN API for Arduino DUE (Read 138 times) previous topic - next topic


Hello Downtown_sausage, Yes. I wrote two sample sketches based on an Atmel sample for the SAM3X-EK. Currently, I am receiving direct support from Atmel/Arduino. They are adjusting some path needs and setting the correct dependencies before releasing it on github (Arduino libraries). At the end, all the drivers (including the transceiver one) should be into libsam of future IDE releases. Regarding your excellent initiative to build the driver, I don't know how easy could be to start from scratch a can driver for the SAM3X8E. The Atmel CAN controllers are hard-to-tame for me if compared with other (remember that there are a lot of MCUs out there with Cortex-M3 core and embedded CAN controller like STM32F10XX). It requires an orchestrated initialization between PMC, AIC, CLK and CAN controllers. The main idea is to build a consistent CAN library to take advantage as much as possible of features like interrupt/message handling, timing, wakeup/sleep, producer/consumer modes, etc... It's about a short time to have available the library but....it's up to you, feel free to contribute with your skills. And thank you!


I see. I haven't looked at the Atmel CAN example drivers yet, but from my experience, chip manufacturer's code is generally pretty rubbish. If we want legitimate CAN applications for the Arduino, we will need to have an extremely solid base driver interface to work off. Don't want to build a house on a weak (inefficient) foundation.


To clarify my last post, I suggest we don't use Atmel's CAN drivers and instead work them from scratch. But if they are really good, then no need to mess with them. In reality, it will probably be a task of looking what they did and seeing if we can improve upon their driver implementation. If it's anything like the CAN processing on the PIC24/PIC32, you can probably offload much of the CAN receiving messages to a DMA channel, which will be key for efficiency. This could be done with TX too, but may not benefit too many applications. I should probably start reading the Atmel uC manual to see how they implement this stuff.

Massimo Banzi

downtown_sausage we're working directly with the ATMEL engineer who wrote the examples in the first place. I suggest you coordinate with Palliser who we have put in touch with the engineer. there is a good chance to get the info straight from the source.



Dec 16, 2012, 11:26 pm Last Edit: Dec 17, 2012, 05:15 pm by Palliser Reason: 1
For a better understanding of the Atmel CAN controllers inside the SAM3X8E, I have dissected the initialization procedure required to let the

CAN controller interact (synchronize/listen) with the real world (CANH/CANL).

Document Sources:
- Atmel doc 11057.pdf
- Can Library from Atmel ASF.

System controllers used:
- Power Management Controller (PMC)
- Nested Vectored Interrupt Controller (NVIC)
- CAN Controller (CAN)

CAN initialization procedure:

1. CAN controller -> DISABLED after power-up reset.
2. CAN controller clock -> ENABLED by PMC (via Low-Power Peripheral Bridge) for CAN peripheral IDs 43 (CAN0) and 44 (CAN1).
3. CAN controller interrupt line -> ENABLED for mailbox X (API definition - CAN_IER_MBX) through CMSIS definitions (CANx_IRQn) in the embedded NVIC (NVIC_EnableIRQ).
4. CAN controller initialized
  4.1. CAN_BR register (baudrate) -> SET. The following steps are performed:
       4.1.1 Check whether the baudrate prescale will be greater than the max divide value.
       4.1.2 Check whether the input MCK is too small.
       4.1.3 Initialize it as the minimum Time Quantum.
       4.1.4 Initialize the remainder as the max value. When the remainder is 0, get the right TQ number.
       4.1.5 Find out the approximate Time Quantum according to the baudrate.
       4.1.6 Calculate the baudrate prescale value.
       4.1.7 Get the right CAN BIT Timing group.
       4.1.8 Before modifying the CANBR register, disable the CAN controller.
       4.1.9 Write into the CAN baudrate register.

  4.2. 8-CAN message mailboxes -> RESET. (CAN_MB_DISABLE_MODE) The following steps are performed:
       4.2.1 Check the object type of the mailbox. If it's used to disable the mailbox, reset the whole mailbox.
       4.2.2 Set the priority in Transmit mode.
       4.2.3 Set the message ID and message acceptance mask for the mailbox in other modes.
       4.2.4 Set up mailbox in one of the five different modes.
  4.3. Configure a mailbox in reception (or consumer) mode  
  4.4. CAN autobaud listen mode -> SET in CAN_MR register (CAN_MR_ABM == 1)
  4.5. CAN controller -> SET CANEN in CAN_MR register (CAN_MR_CANEN == 1)
  At this stage, the internal CAN controller state machine is reset, error counters are reset to 0, error flags are reset to 0 and starts bus synchronization automatically by
  scanning eleven recessive bits an then start listening to the network (real world).

I want to clarify that, even though the above initial procedure it might look over-elaborated, the nature of the CAN controller so requires. We, mortal thinkerers are used to a higher level language. My aim has been to bring here part of what's cooking regarding the CAN API, now in progress. But don't worry; at the end, a simpler solution to this whole approach will emerge.  

Note: The CAN interruptions in SAM3X8E are implemented through CMSIS definitions in the embedded NVIC inside Cortex-M3 (Not from not existent AIC controller). I got confused because it would seem that some of the CAN controller sections in the SAM3X8E manual (doc11057) were from copy&paste sections of the SAM7X manual. The explanation could be that CORTEX-M3 inherited part of its functionality from the venerable ARM7.

Go Up