Thanks.
You're welcome.
it seems that due to the 'C' in CAN most code is written in C
Well, Linux kernel 2.6.25 with first
SocketCAN implementation was donated by Volkswagen in 2008, so besides much wider user base C also has about 13 years advantage - although we already have some unique and pretty useful error dump and error simulation tools. With FreePascal wrapper all
SocketCAN code can be easily transferred with almost 1:1 translation. Just take a look at demos which do not start with
hl prefix in their name. They are in Pascal but they look almost identical to their C roots. If you take a look at
canconfig.c that I mentioned in previous post, you will see that besides SocketCAN (that is already part of the kernel) only
libsocketcan is used additionally. So, if you create a
libsocketcan wrapper then it should not be too hard to do an almost 1:1 translation, or extract just parts which you need for CAN setup in code. If that is too much, then you can always run
ip command in a process and parse the output.
According to my free time, plan is to support
J1939 (trucks, buses, heavy machinery, marine, military and agriculture),
OBD-II (cars) and
DBC file parsing (for automatic conversion of CAN messages to human readable form). If in the mean time I get some
CANopen (plc, industrial automation, embedded) freelance work then I might consider supporting
CANopen as well. For now, there is no plan to support
libsocketcan.
UPDATE:No errors during compilation, but return code is -1.
Where is my error?
I am not familiar with internals of
libsocketcan so I can not tell. If I had to guess then I would first try to replace
with
If that doesn't work, then I would try to create the most simplest code in C which does the job, and then try to convert that to FreePascal with already mentioned 1:1 conversion method. That would eliminate a lot of unknowns of what works and what doesn't.
Ah, yes... You should also try to start your app as root, and check if
can0 is not already started.