CAN bus support

[labusaid]

Having CAN bus supported by the API would be nice for automotive/industrial use. I believe the LPC4330 has support for it with C_CAN0/C_CAN1. Is this on the roadmap anywhere? Has anyone played around with this before? I'm not super familiar with the greatfet firmware or really writing bare metal firmware in general so I have no clue how big of a project this is.

[labusaid]

Also having the greatFET function as a linux socketCAN adapter would be great for using pre-existing tools.

https://github.com/torvalds/linux/blob/master/Documentation/networking/can.rst

[tarikku]

I looked into this some months back, and made a very simple transceiver neighbor - https://github.com/tarikku/canna-greatfet-neighbor, but had not done much on the driver side. My plan was to develop an open source driver and not use the existing ones. Back then I didn't get too far due to too many projects.

There is a silicon error in the LPC used in the GreatFET which effectively makes it impossible to effectively use/control I2C and CAN simultaneously. I was planning on adding an I2C IO expander to the Canna in order to make it more neighborly. This should be OK even with the silicon error, due to the very simple CAN transceivers I chose. The state machine is very simple and I wasn't considering wake-up on CAN so the idea would be to grab I2C to set the transceiver (s) up, release I2C and from then on use CAN only.

It would be great to pool time and work this together if you or anyone else would like. I could probably also lend a hand if you choose to go in another direction too.

[labusaid]

I believe that silicon error you're having is part of the specifications "Use of C_CAN controller
excludes operation of all other peripherals connected to the same bus bridge."
Looking at the block diagram:
C_CAN0 shares bridge 3 with I2C1, the 10 bit DAC, and both 10 bit ADC0 and ADC1.
C_CAN1 shares bridge 1 with PWM, I2C0, I2S0, and I2S1.

I'm not sure I understand the purpose of the TJA1042 chips, are these external CAN controllers connected over serial to try and circumvent the I2C issue? Or are they some kind of supplemental device necessary to let the LPC's internal controllers work?
Ah so the transceiver and controller are two separate devices, still new to this so bear with me. Do you still have some of those PCBs laying around? I'd definitely be interesting in working together on this.

[tarikku]

Right, using a C_CANx actively makes it impossible to use another peripheral on the same bus bridge.

Canna rev1 uses GPIO pins to control each TJA1042T-3 transceiver, which has a standby mode that you can switch to by asserting a HIGH on the STB pin.

The Wikipedia CAN bus article is a good intro to CAN, with the illustration showing the three main parts of a typical CAN node: the MCU talking to a CAN controller (nowadays usually built-in to the MCU, as in the LPC43xx, for protocol control), and a CAN transceiver (for medium access).

I built a Canna prototype but have not tested it through yet. If you are looking into making one, the Canna repository already has everything you need to have your own PCB made (I got mine from JLCPCB).
I should still have enough parts for another board if you get stuck so let me know how you get on.

[antoinevg]

Just a short note to say we'd be happy to assist with reviewing any PR's to add CAN bus support.