CANbus networking support

[NSD76]

Hello,
I would like to use Circle as basis system for project on RPI 3B and later boards needing CAN bus networking (using usual RPI MCP2515 -based HAT). Is there anything already started by someone for such feature ?

Otherwise I may start to write some driver port for this system. I'm not used to program for Circle (this is my first project with this library), but used to develop low-level drivers for almost any kind of usual embedded peripherals based on devices datasheets/users manuals.

[rsta2]

I'm not aware of any CAN bus support with Circle, but it would be great to have it. Let me know, when you need support for this.

[rsta2]

I had a look into your files. I think, that's OK so far. I cannot speak much about CAN bus, because I'm not familiar with it, but from Circle point of view, you should have a look at the following classes, which are abstractions for the hardware, which must be accessed for the CAN bus HAT, as I understand it:

• CSPIMasterDMA (DMA-driven SPI access, polling for short packets supported)
• CGPIOPin (/INT input from MCP2515)
• CGPIOManager (necessary to generate interrupts from CGPIOPin)
• maybe CTimer (for timeouts etc.)

These classes are described here. IRQ-driven SPI access is not supported by Circle, but not necessary, because with DMA it can run completely in the background for larger transfers.

Please note, that throughout Circle GPIO numbers are SoC numbers (e.g. /INT is connected to GPIO25 here, while its pin 22 on the GPIO header).

BTW. The Discussions in your repo are not enabled yet.

[NSD76]

Hello,
thanks for feedback. I forgot the point about DMA support in Circle, agree that it should definitely help if multiple successive SPI transfers can use it making no need of irq for SPI. GPIO pins and manager for sure are needed, I already started to look at them, as well as IRQ support (not for SPI but to handle the incoming IRQ line of the CAN device).
If the concept of having a generic HAL on one side and Wrapper to Circle that would be the 'visible part' of the lib on Circle side is ok for you then I will go on that way. For the CAN HAL itself I believe I don't need much support, as I m used since long time to program such kind of stuff on different MCU, but for the Circle side for the wrapper most probably I will need some help at some point.

For the moment I'm working on UML model file (.xmi file in my repo) to structure the whole thing based on the concept I exposed in the 3 first specifications files (sorry for my old school way of doing programming, usually spending long time on paper or on such modelling systems before starting to write fisr line of code).
->I think I will need about up to 1 month to complete this preparation phase. Once it is ready the code will be generated automatically form this UML model for all structures, objects and functions prototypes. I created this .xmi file with Umbrello (available on kde.org) but I will put also the export as html page on the repo to allow looking at it without installing Umbrello.

For info I activated also discussions on my repo.

[rsta2]

Understood. A quick note on IRQ generation: Because the IRQ line of the CAN device is connected via a GPIO pin, it has to be handled by the class CGPIOPin in Circle. This includes the IRQ handling, which requires also to use the class CGPIOManager. Normally you do not need to care about IRQ vectors etc. here. This is all handled by these classes for GPIO interrupts.

[rsta2]

I have installed Umbrello here today, so I can view the .xmi file, without the need of converting it to .html. I did not use UML that far for my projects and not for generating code, but if you prefer this, it's OK of course. I think I can read your models, where it is necessary. I'm fine with, what I have seen so far.

[NSD76]

Thanks for info, currently there are only 2 classes and 1 interface (the HAL), I will progress on this in the coming weeks.
I Will anyway post again some notice once I have a much more advanced status that could be reviewed.