I think this fits well into the problem I was having with ADS. Right now the ADS driver will only support TCP, even if most of the stuff is in place for serial.
The reason is that in order to use the serial transport a different base-type and transport-level-logic is needed than for TCP. What I was proposing, was to have the option to provide different layer-2 (2 because it's lower than 3 not because it's actually layer 2 in the ISO model) transport logic depending on the transport being used. Protocols that support encapsulation of other protocols (like EtherCAT) could then also provide dedicated transport modules which other protocols could use. So something like: can-open:ethercat://????????? Could possibly be implemented. Chris Am 26.08.20, 04:38 schrieb "Otto Fowler" <[email protected]>: 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 ([email protected]) 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
