An intro to the CANPico board
Вставка
- Опубліковано 29 вер 2024
- A short introduction to the Canis Labs CANPico CAN hardware for the Raspberry Pi Pico. Demonstrates sending CAN frames with the MicroPython CAN API and a logic analyzer with a CAN protocol decoder.
Useful links for things mentioned in the video:
- The CANPico board can be bought from SK Pang here: www.skpang.co.uk/products/canpico-board
- The firmware, reference manuals, schematics and Kicad design files are all on the YesWeCAN GitHub repo: github.com/kentindell/canhack
- How to install firmware on the Raspberry Pi Pico: projects.raspberrypi.org/en/projects/getting-started-with-the-pico/3
- The Thonny IDE: thonny.org
- The Canis Labs open source logic analyzer CAN protocol decoder: kentindell.github.io/can2
- The canpico.py Python examples file: github.com/kentindell/canhack/blob/master/pico/micropython/canpico.py
HI
Can i use this CANpico With a Sparkfun Thing Plus RP 2040 ?
THX
I don't think the Sparkfun Thing has the same pin layout, but I'm pretty sure if you deal with that with jumper leads then it should work: the CANPico interfaces via SPI and a couple of GPIO pins.
Amazing videos, I'm certainly looking forward to getting stuck into this. Out of interest is there out of the box support for higher level protocols such as J1939? Thanks
Working on some support for the trigger API so that it can trigger on specific J1939 CAN ID fields. Hope to have something released soon.
Hi Doc, I just purchased some of the boards and pico's but the can chips are out of stock for the next year or so, is there a Maxim or TI equivalent as I am excited to get them going .
Hi! You can use MCP2517FD CAN controllers instead of MCP2518FD - they're functionally almost identical (the firmware runs wiht both).
Playing with mine today from SKPang - just one thought for v2.0 - just include mounting capabilities, either corner holes or move the tracks away from the Pico's own mounting holes :) Great stuff though!
Good idea, will add to the list!
@@kentindell Thanks :) glad to see you planning for the future too!
impressive board with CAN capability, only issue is price but hopefully cost will comedown in the future
Very nice work on this. I wish ask you about the MicroPython SDK. I don't have the CANPico board, rather some cheep CAN board (SN65HVD230) and RP pico. How can I initialize all the CAN functions with my choice for pins? Thanks.
That's a CAN transceiver, not a CAN controller. So only the CANHack functions will work. You can breadboard up a CANHack solution, as described here:
kentindell.github.io/2021/02/06/canhack-pico/
@@kentindell I see, thanks for help. :)
Have you considered using the PIO functionality to build up an internal CAN controller?
i think we cant
The CANHack board has a transceiver but no controller and uses software on the RP2040 to bit bang the CAN protocol. It's primary purpose is to demonstrate CAN protocol attacks. You can run this software on the CANPico board because we designed it to have direct access to the TX and RX pins of the transceiver.
It's possible to use the PIO to provide the raw CAN bitstream but there's a lot more to the protocol than just the bits, and the second CPU core would have to be dedicated to the job.
Do you have C libraries if I don't want to use Thonny/Python?
It's on the list to do. The MCP2517FD drivers are separate in the firmware source code and in C (they consist of SPI drivers for the bottom half and the remaining driver for the top half). The intention is to cut them into a C SDK and then refer to them in the MicroPython firmware so it's a common code base.
Oh, I forgot: if you don't want to use Thonny you can use rshell (pip install rshell). It's a command line interface to MicroPython that handles the file system as well as jumping in to REPL.
@@kentindell Good to know
halllo
I am trying to initialise a can (c = CAN ) but i receive this Error
RuntimeError: Cannot put MCP2517/18FD into config mode
what can i do to fix that
THX
That's an error message to say that the CAN controller chip refuses to be reset. It shouldn't normally happen.
It sets the C1CON register REQOP field to 4 (request configuration mode) and then reads the OPMOD field to see if it went into configuration mode. Out of reset this it the default, so it should always be OK after power on. This means either the SPI interface isn't working or the CAN controller chip isn't working. One possibility is that the power supply is below voltage and the controller isn't coming out of reset cleanly. Does it do this on a powered USB hub?
A thought: can you also try adding hard_reset=True parameter to the initialization call?
@@kentindell yes it is usb powered
@@kentindell i do it but i have de same error
Hi,
Enjoying the boards.
I've been experimenting with two transmitting to each other.
Just as a casual observation I found that the RX board always buffers 1 sent frame into a frame list, then all the following sent frames are available in the following buffer/frame list. Say 6, 8 bytes frames are sent, I always get 1(list) + 5(list).
..Starting the loop
|- Frames has length: 1
|- Decoded message: __hello_, Timestamp: 2436748169, Arbitration ID: 291, CAN ID: CANID(id=S123), DLC: 8, Index: 0, Tag: 0, Is Extended: , Is Remote:
|- Frames has length: 5
|- Decoded message: message4, Timestamp: 2436748399, Arbitration ID: 291, CAN ID: CANID(id=S123), DLC: 8, Index: 0, Tag: 0, Is Extended: , Is Remote:
|- Decoded message: message3, Timestamp: 2436748621, Arbitration ID: 291, CAN ID: CANID(id=S123), DLC: 8, Index: 0, Tag: 0, Is Extended: , Is Remote:
|- Decoded message: message2, Timestamp: 2436748843, Arbitration ID: 291, CAN ID: CANID(id=S123), DLC: 8, Index: 0, Tag: 0, Is Extended: , Is Remote:
|- Decoded message: message1, Timestamp: 2436749065, Arbitration ID: 291, CAN ID: CANID(id=S123), DLC: 8, Index: 0, Tag: 0, Is Extended: , Is Remote:
|- Decoded message: __world_, Timestamp: 2436749289, Arbitration ID: 291, CAN ID: CANID(id=S123), DLC: 8, Index: 0, Tag: 0, Is Extended: , Is Remote:
Is this expected behaviour? Thanks
That's to be expected: the code is spinning round recv(), a frame comes in (via an ISR), it goes off to process it. The time taken to print is actually very slow, and in that time another 5 frames arrive. They're all processed together, the next time round the loop, that printing is very slow, and so on.
Instead of printing the whole frame, try printing just the number of frames. And then try removing even that print and simply appending the length to a list, and at the end of the test run printing that list.
You'll get another strange effect on transmitting: if you transmit a list of frames, starting low priority and going up to high priority, the frames will likely be transmitted in priority order except for the first one: the first one starts transmitting as soon as it's put into the controller (assuming the bus is mostly idle) then the subsequent frames are stacked up, with the controller choosing to send the highest priority first.
@@kentindell thanks for the info and support, I’ll take onboard your feedback and experiment some more.