Hey Andreas, Overall plan I see for CAN is rather straight. There are so many flavors of it that we can't handle all of them. So anyone who knows an flavor is welcome to come and contribute. :) I am not very familiar with automotive CAN / iso-tp / OBD / LIN and so on, thus I can't speak about these. Given that I see CAN FD with bigger payload types as well as CAN XL I would like to let us be open for these.
In order to simplify development of CAN related drivers I believe we need: A) Better separate bus api/transport This will let driver focus on application layer and actual message exchange logic. B) Provide kind of an "raw can" driver, transport + nothing more That part will serve as an simplified CAN API whereas driver caller will be responsible for handling actual exchanges. C) Provide a small set of APIs to build CAN application layer driver So far we got canopen which is working, yet very closely coupled with socketcan transport. Probably somewhere in future if above steps will be made we will still need to have distinct support for FD stuff, yet now it is out of picture. Also for CANopen - what we have implemented is just an "client" level. There is no support for "device" simulation nor proper handling of "object dictionary" (OD) or electronic data sheet (EDS). I am not sure if this would fit into plc4x umbrella since it is specific to canopen and how it works. We have no such issue yet cause we don't parse nor provide support for protocols which have such descriptors (profinet with GSDML, ethercat with their format etc). Kind regards, Łukasz On 29.03.2021 06:43, Andreas Oswald wrote: > Hi Łukasz,, hi everybody, > > that sounds pretty interesting, do you have plans to to implement "higher > level" protocols based on CAN e.g. UDS? Maybe we should exchange ideas as my > daytime job ist about developing a software package that takes care of > Software Versions and parameter sets for electrical vans, where we rely > heavily on UDS. Unfortunately not all of our ECUs implement fine UDS. > > When Chris introduced me to the project I guess a bit more than two years > ago, Slack was the medium to use. > > Maybe someone can give me a hint about how communication is dealt with. > > Good to be back 😉 > > Have a great start for the new week. > > Take care > > Andreas > > Andreas Oswald > Marienstraße 12 > 52223 Stolberg > Germany > > ++49 2402 905 3852 > ++49 172 426 1598 (also Signal) > WhatsApp/Telegram on ++49 157/38459358 > > ________________________________ > Von: Łukasz Dywicki <[email protected]> > Gesendet: Montag, 29. März 2021 02:18 > An: [email protected] <[email protected]> > Betreff: Further updates to CAN stuff in plc4j > > Hey all, > I began to think how to cover basic interactions with CAN bus which > could serve a custom systems or ones which are closer to some narrow > cases. My intention here is to offer simplest possible way to become > CANbus client without any specific application layer protocol. > Results of my thought process are following. > > Driver operations: CAN as protocol is rather event based hence CAN > driver should not support "read" but only write and subscribe. A "read" > in our api indicate rather an synchronous call for which we expect an > answer. This is not a case with CAN where you can keep broadcasting but > never expect any answer back or could have multiple replies. While > downstream protocols can offer such functionality (canopen does) at most > basic level we can't provide any handling for that. Definitely it would > make hard to port driver over different languages. > If this driver gets implemented end users can use it as a very thin > client API which gives them access to the bus and covers very basic > handling of subscriptions for specific COBs (CAN Object Identifier) and > possibly basic IEC types via field handlers. > > Transports: an awful part of CAN is amount of APIs which can be used to > access a bus. The low level stuff is done by microcontrollers and hidden > from applications who interact with a bus. In the end socketcan, slcan, > usb2can or whathever-to-can are just multiple ways to publish CAN frame > onto physical medium. > I did hang on this for a moment, cause driver syntax we have is briefly: > <protocol>:<transport>://<transport-options>?<driver-options> > > Currently connection string for CANopen looks like this: > canopen:socketcan://vcan0?heartbeat=false > Yet for slcan or can2usb it could look like this: > canopen:slcan://dev/ttyUSB0;baud=50000?heartbeat=false > canopen:can2usb://COM4;baud=50000?heartbeat=false > (eventually with baud= parameter in query string). > > Whatever syntax we use to express transport and its configuration the > problem is later shifted to the edge of Driver and Transport. Different > APIs might bring different frame length estimators or discarded byte > handling nor filtering capabilities. Currently driver is one who is > responsible for that, yet in case of CAN - socketcan uses 0x00 to always > pad data while serial bridges do not require it at all. At present I see > no way to fit it without breaking some things. > CAN transport essentially must provide above estimators. Maybe in future > some other features specific to this transprot ie. message filtering > which seems to be very common thing. For driver it must provide a way to > publish "COB + byte[]" and receive "COB + byte[]". > > So far we have support only for socketcan transport. It did the job to > get into CAN, yet it is not the only one. Its not portable over all > platforms. Because of above condition canopen driver actually depends on > socketcan transport and its encoding of frames. > My long term plan in this area is extraction of CANFrameBuilder part out > of canopen driver to plc4j-transprot-can. This transport should define > CAN specific transport APIs. What do you think about that? > > Once this step is made we can bring simplistic CAN driver with very low > effort. It will also open a path for other CAN transports which could > utilize yet another hardware and serve other operating systems. > > Best, > Łukasz >
