Hey Łukasz,
that's quite an an amount of information for me to fully understand.
Right now I'm on vacation with my kids enjoy cycling around my old home
soil, that I've not been to for more the 20 years, it's like time travel.
I guess I'll have some more concrete questions after the easter holidays.
Have a great time and I look forward to discuss that further on.
Take care
Andreas
Am 29.03.21 um 12:22 schrieb Łukasz Dywicki:
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
