I would rather have multiple, clean drivers than one that is so complicated myself. Maybe if there was a way to structure the mspec’s such that you could re-use or re-combine them ( ie have multiple mspecs that in some combinations generate different drivers ).
On August 25, 2020 at 19:11:34, Łukasz Dywicki (l...@code-house.org) wrote: I come to a point where I need to brainstorm a little bit. I started my inspection of CANopen and it looks like a whole new thing which is built on top of CAN. What's worth to remember is fact that CANbus has many flavors and transport layer can be pretty much anything. Anything means serial interface (slcan), socketcan, udp (can over ethernet), wrapping in other transports such as ethercat to end with vendor specific interfaces and SDKs. All above result in creation of CAN frames in slightly different formats. All above interfaces obviously follow all rules which are relevant for CAN. Two versions of CAN frame which are standardized are: - CAN 2.0A with 11 bit identifier and maximum 8 bytes of data - called sometimes standard frame format (SFF) - CAN 2.0B using 29 bit sometimes called extended frame format (EFF) On the bus level EFF identifier is split into 11 bits and then 18 bits. Data length is also 8 bytes max. - CAN FD - not entirely clear on identifiers for me, but it allows up to 64 bytes of data. Most of modern cars already uses it. Reason why I enlist all above is to show you the rich set of transport options which we did not experience for PLCs so far. Most of protocols we have so far is bound to one or maximum two transports. In this case we have standard physical layer, different frames, different interfaces yet all should lead rather to an unified result. The CANopen mentioned early in this mail defines OSI layers which could be seen seen as network, transport, session and application layer. CANopen is not the only one attempt to standardize payloads, there are others which are dedicated to narrow areas where standard is used. Implementation of CANopen has one challenge upfront - it divides 11 bit identifier into 4 bit function code and 7 bit node identifier. There are also some attempts to make use of CAN 2.0B/EFF identifiers there, however my knowledge about that is currently fairly limited. Problem which I face now is impossibility to implement CANopen without relying on a specific transport. Given that we have many, multiplied at some point of time by various frame encoding formats 2.0B/CAN FD we will quickly end in the most over-bloated CAN interface ever found. This brings me to following finding for CAN. We have a clear indication of application layer which is independent from transport itself: CAN transport -> CAN 2.0A frame -> CANopen Now in order to realize above we need few things. First of all - I would say we need to re-parse part of lower layer contents into something new. It is quite opposite to what we know from IP where everything build above layer 3 doesn't care about MAC/network layer at all. CANopen do care, cause it requires access to identifier in order to determine function code. I been thinking how we could arrange that. One idea I got so far is re-wrapping of read buffer and its sections to re-parse it. Second option I see is sticking to pre-defined CAN frame format. While socketcan looks like an natural selection for later option it seems that there is some legitimate reason why so many interface manufacturers still offer their own APIs to access bus. Forcing longer than necessary identifiers might also hurt C and embedded stuff Chris is working on. After all encoding of CAN 2.0A identifiers in 32 bit memory block takes almost 3 times more than it actually needs. Looking forward to your comments and opinions. Cheers, Łukasz
