New Raspberry Pi Zero 2W

o_lampe

@t3p3tony said in New Raspberry Pi Zero 2W:

@PCR using that CAN-FD bus IC & transceiver with a Pi (either directly on a Pi 2/3/4, or using a 2040 + USB to a PC) could certainly allow for bus monitoring and protocol diagnosis, independent of using an oscilloscope so that could be interesting.

I read more about Pico's PIO state machines and there is a sample code about a logic analyzer (16 channel IIRC). Just thought it was worth mentioning it in this context.

dc42

While the PIO state machines look very useful, the amount of instruction memory (32 instructions) and scratchpad memory (2x 32 bits) are nothing like enough to implement a protocol with the complexity of CAN-FD.

o_lampe

@dc42 I felt the same, when I studied the CanHack.py program. So we'd need both Can chips to make it work.

zapta

@dc42 said in New Raspberry Pi Zero 2W:

While the PIO state machines look very useful, the amount of instruction memory (32 instructions) and scratchpad memory (2x 32 bits) are nothing like enough to implement a protocol with the complexity of CAN-FD.

@dc42, I am not familiar with CAN bus. What does the PIO need to do other than serializing bits in/out or detect collisions? Those PIO instructions are very capable (they have multiple fields and can do a few things in one instructions) and work well with the the hardware FIFOs, DMAs, and MCU interrupts.

o_lampe

@zapta The CanHack program lists many subroutines for testing and demonstration purposes and some real life routines. They are usually only a few lines of code. In C++ they might even be more compact.
But for compatibility reasons beween Pico(with state machines) and Z2W(no state machines), the Can-Hat should have both Can chips anyway...

zapta

@o_lampe, I see here two pdf schemas, one with a can controller and one with just the transceiver. What's the difference between them? Can the one without the MCP2518FD still support CAN functionality? Why two versions?

https://github.com/kentindell/canhack/tree/master/pico

o_lampe

@zapta I'm no CAN expert either, but it seems it has some FiFo buffers, filters and CRC check of the SPI bus. The 40MHz crystal is another feature for better CAN-performance and reliability.

o_lampe

@ALL
there's a dual CAN-FD Hat for RPi from Seeedstudio
Does anyone see a reason, why this wouldn't work for SBC-purposes? (pins or I/O channels already in use)

@PCR
would it still make sense to design our own version?

jay_s_uk

@o_lampe the raspberry pi shield might be a way to add CAN-FD in setups where it's not natively available, such as duet 2 + SBC and the STM/LPC port

PCR

@jay_s_uk Yep problem is that the Shield is using SPI i think?

o_lampe

@jay_s_uk said in New Raspberry Pi Zero 2W:

the STM/LPC port

The super8 has a Can-Port, but it's not (yet) supported? OTOH, I wouldn't know how to link a RPi?

jay_s_uk

@o_lampe it does but it's only CAN over serial for the klipper guys

o_lampe

@pcr said in New Raspberry Pi Zero 2W:

@jay_s_uk Yep problem is that the Shield is using SPI i think?

There are two different versions. As it seems they both use SPI.
Which I/O protokol would be best? UART, I2C, SPI?

o_lampe

@jay_s_uk said in New Raspberry Pi Zero 2W:

the raspberry pi shield might be a way to add CAN-FD in setups where it's not natively available, such as duet 2 + SBC

That's the idea, although I don't think we'll see a Duet2 with a Duet3-toolboard. There's latency between Duet <=> RPi and RPi <=> toolboard

dc42

@zapta said in New Raspberry Pi Zero 2W:

@dc42 said in New Raspberry Pi Zero 2W:

While the PIO state machines look very useful, the amount of instruction memory (32 instructions) and scratchpad memory (2x 32 bits) are nothing like enough to implement a protocol with the complexity of CAN-FD.

@dc42, I am not familiar with CAN bus. What does the PIO need to do other than serializing bits in/out or detect collisions? Those PIO instructions are very capable (they have multiple fields and can do a few things in one instructions) and work well with the the hardware FIFOs, DMAs, and MCU interrupts.

Lots of things. When receiving it has to generate a local clock that can handle variation and jitter in the received clock. It has to decode the initial ID byte format to determine whether it uses an 11-bit or 29-bit address, whether the node is interested in that ID, whether it is a CAN-FD or plain CAN packet, and whether bit rate switching is enabled (I guess you could avoid some of that by restricting the types of packet supported). It has to handle bit stuffing, and it has to calculate the CRC of the received message in real time so that it knows whether to assert the ACK bit at the end of the message.

zapta

@dc42, yes, it sounds a lot of things. As you say, some could be addressed by focusing on message types that exist in a duet system but I am not sure about the CRC, how complex it is or what is the time to respond. On the other hand, the PIO provide room for creative solutions and possibly may be able to use a few state machines in parallel to divide the work, and there is also the second MCU core that is sitting idle and can be dedicated for the CAN decoding, and then there is an official API to overclock everything ...

o_lampe

@zapta @dc42
It would be interesting to know: are all of these functions hardwired in a Sammy-C21?

dc42

@o_lampe said in New Raspberry Pi Zero 2W:

@zapta @dc42
It would be interesting to know: are all of these functions hardwired in a Sammy-C21?

Yes.

zapta

@o_lampe said in New Raspberry Pi Zero 2W:

@zapta @dc42
It would be interesting to know:

To set the record straight, I know almost nothing about CANBUS and the little I know is mostly from this thread.

BTW, I do have some experience with another automotive bus call LINBUS that you can find in modern cars but is seldom mentioned. This product for example is based on a public domain design that I published on github http://t-design9.com/memory_module_porsche.html .