Skip to main content

CANbus on the Omega2

Omega2S
Omega2+

If you are as big a fan of the Omega2 as I am I'm guessing you want to do as much with the platform as possible. Recently I've been looking to get a low cost Linux system on a CANbus, to sniff on some traffic. What are the options for adding a CAN interface to your Omega2, either when you are designing a solution or looking to easily add it to an existing system?

eLinux has a great guide on a number of CANbus adapters that I'd recommend to anyone looking to integrate CAN into their system.

Interface Typical use case Available on Omega2 / Omega2S
serial (via SLCAN) Design-in/Add-on Simple protocol but not considered reliable, efficient or fast by Linux CAN developers.
SPI Design-in Not usable, the Omega2 (MT7688 cpu) is only half duplex SPI
Software SPI Design-in Higher cpu load than hardware SPI
USB Design-in/Add-on Available (Omega2 has one USB host port)

Note that all of the design-in options could be used for prototyping with extra effort. This would consist of:
  • Finding the SPI lines for your micro
  • Some way to connect the SPI lines to your CAN controller, like a breakout or devel board
  • Wiring the SPI lines to the SPI lines of the CAN controller
Comparing this to plugging in a USB adapter and you can see why, for this comparison, I'm indicating that the non-usb interfaces are more suitable for a design-in approach.

slcan / serial

The slcan protocol, documented at http://www.can232.com/docs/can232_v3.pdf, is a simple command set for wrapping CAN functionality over a serial connection.

Limitations of slcan are:
  • Controllers with slcan protocol support, such as the SJA1000T, are 10+ years old and no CAN-FD support is anticipated
  • Serial ports can operate up to 2MBit over short distances. CAN-FD can support 5MBit+.
  • slcan does not currently support CAN-FD features and afaict there are no CAN-FD slcan devices.

SPI

Many CAN controllers, such as the popular MCP251x series of controllers, interface via SPI. A number of these controllers, such as the MCP2517FD support CAN-FD.

SPI may also be more suitable from a system design standpoint as it is a bus. It's possible to connect a number of devices to a SPI bus using per-device chip select signals. Compare this to the single USB host port on the Omega2 / Omega2S. If the USB CAN device isn't your only usb device 
you'll have to add a USB hub to have more than one USB device connected to your Omega2 at the same time.

SPI sounds like a reasonable interface until you find out that Mediatek MT7688 processor used in the Omega2 has a design error that causes full duplex SPI to be inoperative. The Linux drivers for the common MCP251x controller appear to be designed for full duplex SPI functionality. In addition, in my brief review of the MCP251x data sheets, it appears that full duplex SPI is required for proper functionality.

Bitbanged / software SPI

The Linux kernel contains drivers that support GPIO, or bit banged, SPI. A driver called 'spi-gpio-custom' was created and added to OpenWRT, the base distribution used in the Omega2, to expose this software based SPI interface.

Downsides to software gpio drivers are high cpu usage under high SPI bus loads. Secondarily is the potential that the bus load and system load will result in data being dropped if the CANbus load results in SPI loads that the processor can't keep up with.

USB

Usb is hands down the easiest approach. Typically it is as difficult as plugging the adapter in. I highly recommend the canable adapter due to its low cost and solid performance.

The Omega2 has a single USB interface. This means that you'll need a USB hub if you would like to use a USB CAN adapter AND have one or more USB ports available. These aren't too costly but adding a USB hub is for sure more costly than if the Omega2 had a working full duplex SPI available (see above).



Labels:

Comments

Post a Comment

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr
5 comments
Read more

Graco Swing By Me - Battery to AC wall adapter modification

If you have one of these Graco battery powered swings you are probably familiar with the cost of C batteries! The swing takes four of them and they only last a handful of days. I'm not sure if the newer models support being plugged into the wall but ours didn't. If you are a little familiar with electronics and soldering, here is a rough guide on how you can modify yours to plug in! I wasn't sure how exactly to disassemble the swing side where the batteries were. I was able to open up the clamshell a bit but throughout this mod I was unable to determine how to fully separate the pieces. I suspect that there is some kind of a slip plate on the moving arm portion. The two parts of the plastic are assembled and the moving arm portion with the slip plate is slid onto the shaft. Because of the tension in that slip plate it doesn't want to back away, and because of the mechanicals that portion of the assembly doesn't appear accessible in order to free it. I was
Post a Comment
Read more

Memory efficient queuing of variable length elements

In embedded environments memory can be a critical driver of the design of data structures and containers. Computing resources have been expanding steadily each year but there are still a wide range of systems with far less than a megabyte of memory. On systems with tens of kilobytes of memory, structures are often designed to be compact to maximize data density. Rather than splurging on memory aligned elements that would be faster for the processor to access, a developer will typically use types with minimal sizes based on the known range of values that the element is intending to hold. Fixed sized buffers At my day job a fixed size pool of messages was implemented to hold message data. While this achieved one design goal of using statically allocated buffers, avoiding dynamic allocations that might fail at runtime, it isn't efficient if there is a wide range of message sizes. It isn't efficient because each message uses a message buffer. With small message sizes the buff
2 comments
Read more