New documentation for MicroPython CAN

We have recently been developing an API for CAN under MicroPython for the new CANPico board from Canis Automotive Labs. There are some really neat features of the CAN support under MicroPython:

• Getting started is real quick: there are pre-defined ‘profiles’ for CAN so there is no need to mess around trying to work out the fairly complex bit rate settings.
• The drivers are free of priority inversion: when a high priority frame is queued then it goes ahead of other lower priority frames in the queue (this is provided directly in hardware by the Microchip MCP2518 CAN controller).
• There is a FIFO option for transmitting frames in FIFO order for special cases where it is needed (e.g. when there is a block message composed of multiple CAN frames with the same ID).
• The receive FIFO is huge - 128 frames - so a script written in MicroPython can poll for frame arrival (there is even support for noting where frames have been dropped if there was a receive FIFO overflow).
• There is support for microsecond-accurate 32-bit timestamps. These apply to transmmitted CAN frames as well as received ones, which lets a system sync events to a global clock (by sending a frame, then sending a follow-up CAN frame with the sender’s timestamp so that receivers can compare and compute an offset).
• Up to 32 ID acceptance filters can be set so that frames are accepted or discarded based on their ID - and are tagged with the acceptance filter number when accepted. This can massively reduce the CPU load on a busy bus by screening out the frames that aren’t needed.

The API consists of four classes:

• CAN for the CAN controller
• CANFrame for CAN frames
• CANID to define CAN IDs
• CANIDFilter to define hardware acceptance and tagging filters

The CAN API is documented in the MicroPython SDK Reference Manual (PDF).

The firmware will be released shortly when we have run a soak test against the first batch of CANPico boards (which are being assembled).

We will release a binary firmware image first, then work out how best to release the source for anyone to compile and build firmware. Unfortunately, that’s a bit complex: We had to reach into the guts of the Pico MicroPython build because of the way GPIO interrupts are defined. The firmware is built against the latest v1.14 release of MicroPython so we will probably produce a patch or a pull request against that specific build.