Teensy 3.1 and CAN Bus

BenW

New member
Hey guys,

I am using an Arduino Uno R3 with a CAN BUS Shield in my project.

I am about to replace the Arduino + Shield with the Teensy 3.1

I was wondering about any progress for CAN Support for Teensy 3.1
The technical specification says that 'A new library to support Teensy 3.1's CAN controller is planned.'

I would need it in near future - so I need to know if there is something like a planned release date for this library.

Otherwise, i would have to use additional hardware like this to get CAN Bus Support for Teensy?

Any suggestions to achieve CAN Bus Support for my Teensy?

Thanks in advance,

B
 
So far, the only work I've done involves building up test hardware (and reading quite a bit about CAN). Here's a photo, so you can at least see some I've got a collection of hardware together here....

can_hardware_test.jpg


Realistically, unless someone contributes a lot of code, I believe April is a likely time frame for a usable CAN library on Teensy 3.1. But honestly, that's just a wild guess. So far, I have only built up hardware and played with the 2 existing libraries for the MCP2515 and Arduino Due. I have not written a single line yet for Teensy 3.1, so I honestly have no true idea if it will go pretty easily or end up far more work that originally anticipated.

I know that's probably not very reassuring. If PJRC were like most giant corporations, we'd probably make all sorts of great-sounding promises with a very specific release date. I just don't work like that. But I do plan to push the code to github during development, so if you want to contribute or just follow "bleeding edge" development, you certainly CAN.... ugh, get it, "can", bump-d-bump.
 
Dear Paul,

first of all thanks for the Teensy 3.1 - it is a nice, small, affordable yet powerful platform for DIY projects. Now with the CAN library planned it seems to be an ideal candidate for a project that I'm working on. For now I use the 2515 controller + transceiver shield and one of the existing CAN Arduino libraries. That works fine, but to reduce the size and remove the need of SPI communication it would be good to use only a transceiver and build in CAN capabilities, so fingers crossed for the CAN library.

BTW do you have any plans to release in future an adapter (similar e.g. to SD card adapter) with the can transceiver on it?
 
so fingers crossed for the CAN library.

The honest but unpleasant truth is the audio library has gotten all my available engineering time recently. I'm not going to touch CAN until after a 1.0 release on the audio lib.

I do indeed plan to write a CAN library, but I'm just one guy with a LOT of things competing for my time, so please set your time-frame expectations realistically.

BTW do you have any plans to release in future an adapter (similar e.g. to SD card adapter) with the can transceiver on it?

Yes. In fact, the board in the lower left corner of the photo is the prototype.
 
Yes. In fact, the board in the lower left corner of the photo is the prototype.

I see. I was hoping for something a bit smaller - more the size SD card adapter which is pretty compact. But anyway, thanks for sharing and good luck with the audio library ;)
 
About half of that board space is a place to solder a DB9 connector.

At this very early stage, I still don't know if that's even necessary. But in my initial research, I did find many ODBII cables that go from your vehicle to that DB9 connector, so the DB9 seemed like a good idea.

A lot can happen between now and when I actually work on the software side. The hardware part is really much easier.
 
Not sure how large the market is, but serious model railroad layout folks seem to use CAN.
On-railcar sound is a common topic.. steam engines, whistles, horns...

http://openlcb.org/

AVR/Arduino..
http://modelrail.otenko.com/arduino/arduino-controller-area-network-can

from wikipedia...

There is prototype hardware is based on:

* the AVR-based Arduino platform at Hobbyists, including:
* LEDunino, a ATMega328-based compatible from Silicon Railway;
* Railroad Shield from SPCoast;
* Io Developer's Board, an AT90CAN -based compatible from Railstars,
* Io:duino, an Arduino-compatible AT90CAN-based board also from Railstars
used as a platform for a throttle and a command station, and its associated
* CMDArduino, a library for a Command Station, from Railstars;
* the new DevKit from Railstars / NMRA.

* PIC code based on the CBUS platforms is here
 
A complete greenhouse + aquaponic controller could use CAN bus as well.

Reef Angel is Arduino based...but uses janky USB connections.
http://www.reefangel.com/

Greenhouse controller needs distance on cabling.
Also placing small sensor boxes wherever they are needed.

Sparkfun has an Arduino CAN bus shield with DB9
 
Greetings, all! I'm a fairly experienced user of CAN, but only a beginner-intermediate programmer of "real" micros applications (vanilla Arduino code mostly). Picked up a Teensy and am intrigued by the potential.

@PaulStoffregen, for one of my projects I tried using a similar MikroElectronica CAN board with Arduino Uno/Micro and wasn't successful. You are probably much better with SPI than I am, and you may already have a working setup, but if you run into trouble I recommend the SeedStudio CAN board plus arduino UNO plus franksmicro's MCP2515 library. It's all a bit crude, but it works out of the box and should save you the expense of a professional CAN PC interface.

At any rate, I'm interested in volunteering to help develop or test the CAN library as it progresses. I don't presently have enough baseline knowledge to get started, so any reading suggestions for low level Teensy programming or understanding the Freescale processor are appreciated. I've reviewed the datasheet and am beginning to read through the reference manual.

Edit: Accidentally a word.
 
Greetings all! I'm also a fairly experienced user of CAN and have been using the MCP2515 CAN controllers (via SPI) for some time now with Arduino. I'm excited that the Teensy 3.1 brings native CAN controller functionality with some serious processing power. I've also used the ChipKit MAX 32 which have two native CAN controllers for development projects. They might be another place to look for some ideas on CAN libraries (included in MPIDE).

I started designing CAN interface boards for my own selfish reasons a couple of years ago. At the time, the smallest "off-the-shelf" solution out there for a CAN interface was Sparkfun's CAN shield. Although it worked well, in my opinion it was just too big and awkward to be used as anything more than something that could sit on the seat next to you for development purposes. I came across Paul's Teensy 2.0 board and fell in love with the native USB connection, extremely small size, and it's ease of use. Finally, something small and elegant I could hide under the dash of my car near the OBDII connector (or anywhere I wanted, frankly). I designed a MCP2515/2551 CAN shield for the Teensy 2.0, adding a voltage regulator as well so the Teensy could be powered up by the car. It's a small board with the exact same footprint as the Teensy - smaller than what I could find in the aftermarket through MikroElectronica or others.

I just got done designing (and in the test phase) of a dual MCP2515 CAN controller daughter board for the Sparkfun Pro Micro that fits in the Pro Micro's footprint. I had to go down to QFN packages to get it all to fit. I abandoned the DB-9 connector on my daughter boards out of frustration that the connector was as big as the micro itself. I know it's the "standard" connector, but it's not very small and elegant.

I think a neat daughter board for the Teensy 3.1 would be one that would provide a transceiver for the native CAN controller, as well as a secondary MCP2515 & transceiver combination to add a 2nd CAN bus. Or, go all out, and simply add another transceiver to the dual 2515 controller board below and have 3 CAN interfaces.

Most cars now have two CAN networks on the OBDII port (high speed for powertrain control, medium speed for body control functions). Being able to tap into both networks, and also being able to serve as a gateway/bridge between two networks running at different speeds is highly useful in the automotive world and would imagine there are more hobbyists like myself interested in this as well. Even neater yet would be a spot on the bottom side of the 3.1 board for a transceiver and 120 ohm termination resistor, similar to the design principle that's currently used for capacitors, crystals, etc.

So, what can you do with a Teensy with a CAN shield? I turned my pedal bicycle into an OBDII compliant CAN device that I could plug an OBDII/Bluetooth adapter into. Using an off-the-shelf Android App called Torque, with custom defined OBDII PIDs, I was able to read gear position, speed, cadence, bike speed, etc. from my bike with the analog and digital pins on the Teensy, and respond to OBDII request messages on CAN from the Bluetooth adapter. All the information could be logged on my smartphone with GPS overlay, and the phone can also be used also to overlay real-time information with video from the bike.

If there's a way I can collaborate in testing the CAN software or partner in the shield architecture or design, please let me know. I've had great success with the Teensy 2.0 products and can't wait for much more horsepower from the 3.1 board.

Here are a couple images of the CAN interface boards I've designed to date (green = Teensy 2.0 w/ 1 controller, purple = Pro Micro shield w/ 2 controllers). My goal in design has been to make them as compact and functional as possible in the smallest amount of real estate.

-Brian

IMAG1493.jpgIMG_20131228_214535_129.jpg
 
Here are a couple images of the CAN interface boards I've designed to date (green = Teensy 2.0 w/ 1 controller, purple = Pro Micro shield w/ 2 controllers). My goal in design has been to make them as compact and functional as possible in the smallest amount of real estate.

These are really nice! Love their compact size. One suggestion to possible future shield designs - while it is cool to have 2 or 3 CAN controllers on the board it would be also nice to have just a transceiver shield to be used where size/weight/price matters. I'm working on an adapter for a multirotor aerial vehicle, so would love to see a shield as tiny as possible for serving one CAN bus only.
 
Last edited:
Just a quick post.

Does anybody know how to access the internal CAN? Or am I getting something wrong.

The CPU datasheet gives no clues. How am I supposed to "talk" with it?

I admit, I am a newbie in ARM, but in AVR there were registers.. So how on earth does it work? Surely there must be register to indicate it has received some data. Or else what is the purpose of this advertised CAN?
 
Last edited:
If by "quite a capable device" you mean the CAN documentation in the datasheet is insanely complicated, yes I agree!
 
User Guide makes it a bit easier to understand by giving some examples

That is a nice document I wish I knew of yesterday! It is breaking down their loopback demo into sections and explaining them. Here is my work-in-progress attempt at the simplest Teensy 3.1 CAN possible. I just got the RX implemented this day so it can send and receive. A long ways to go yet...
https://github.com/teachop/FlexCAN_Library

(By the way there is one other device on the bus for test purposes right now, made from an Arduino with CAN shield. As I said this is very early...)
 
Last edited:
Realistically, unless someone contributes a lot of code, I believe April is a likely time frame for a usable CAN library on Teensy 3.1. But honestly, that's just a wild guess.

Paul I see postings about CAN needing worked on. This is a just-barely-going driver, that I hope to flesh out this week (filtering and error handling and buffering and...) but keep simple.
https://github.com/teachop/FlexCAN_Library

Can you give any guidance on if/how this could be useful for filling the CAN driver gap?
 
That is a nice document I wish I knew of yesterday! It is breaking down their loopback demo into sections and explaining them. Here is my work-in-progress attempt at the simplest Teensy 3.1 CAN possible. I just got the RX implemented this day so it can send and receive. A long ways to go yet...
https://github.com/teachop/FlexCAN_Library

Nice start teachop. Well done!

I've tried your code it and it seems to work for the transmit part (successfully send a message that was understood by other device), but I have problems with the receive. Although there are messages floating on the CAN bus (confirmed with the digital signal analyzer connected to Teensy's CAN RX pin), the recv method always returns 0. Does the receive part work for you?

P.S. I'm using 1000000 speed.

P.P.S. Attached is a keywords.txt file which you can add for syntax highlighting in ArduinoIDE. Also if you move the example to CANtest subdirectory (but still under examples), it will be visible in ArduinoIDE examples list.
 

Attachments

  • keywords.txt
    96 bytes · Views: 418
Last edited:
Hey thanks for the help. I saw in testing today that the receive filtering needed another register reset to be disabled. When I saw your email I pushed this change (relevant one is in FlexCAN::begin()) to github. If you want to check and see that would be awesome, I am working on testing right now.
 
Hey thanks for the help. I saw in testing today that the receive filtering needed another register reset to be disabled. When I saw your email I pushed this change (relevant one is in FlexCAN::begin()) to github. If you want to check and see that would be awesome, I am working on testing right now.

It is better now (I'm getting something), but some of the messages are lost. Could that be because only one RX MB is used and the data gets overwritten before being read?
 
Thanks again. Yes that is exactly what goes on, I am testing @ 125K and being gentle while getting the basics down. This is my development plan:

0) Prove a basic unbuffered "perfect link" case is totally stable (and get the library laid out correctly, thanks for keywords and directory tree info).

1) Handle "imperfect link" CAN errors and prove that is stable (dragging frayed wire across terminals etc).

2) Implement buffering in tx and rx, a must as you see. Not seeing right now how multiple tx-side buffers in the chip can be configured to guarantee in-order transmission.

3) Come up with a filter table API, use of which will be optional. This will help potentially in your present dropped frame situation too.

Thanks again.
 
You can build a full-featured FlexCAN driver by creating a project with Freescale's Processor Expert software (v10.3), which supports the MK20DX256VLH7. All the FlexCAN options are exposed, all methods and events are handled and the options to generate the driver are in a point-and-click GUI. Porting the resulting driver is perhaps not going to be straightforward but, if anything, it can serve as a reference as they probably got all the nitty-gritty details right.

PE_MCU_DRIVER_SUITE: Microcontrollers Driver Suite v10.3 :

http://www.freescale.com/webapp/sps...R_SUITE&parentCode=null&nodeId=0152103F6BEC92

This thing can generate drivers for just about anything that's on the chips it supports :) It was a free download after I registered to the site.
 
Last edited:
You can build a full-featured FlexCAN driver by creating a project with Freescale's Processor Expert software (v10.3), which supports the MK20DX256VLH7. All the FlexCAN options are exposed, all methods and events are handled and the options to generate the driver are in a point-and-click GUI. Porting the resulting is perhaps not going to be straightforward but, if anything, it can serve as a reference and they probably got all the nitty-gritty details right.

PE_MCU_DRIVER_SUITE: Microcontrollers Driver Suite v10.3 :

http://www.freescale.com/webapp/sps...R_SUITE&parentCode=null&nodeId=0152103F6BEC92

This thing can generate drivers for just about anything that's on the chips it supports :)

Had someone allready try this?
 
Back
Top