What about this (http://www.cananalyser.co.uk/index.html). The Windows/Linux SDK for Delphi is free.Unfortunately from what I can see it doesn't address socketcan.
Why are you calling connect and not bind?Even if I call bind (or fpbind) the issue is that the sockets code seems to be oriented towards ip and port numbers.
So in general I get the feeling that to add socketCAN support to FPC will require a fairly extensive modification of the base sockets library.PF_CAN is just a number. In linux sources you can find it defined as AF_CAN, which is defined as 29. So why don't you try that first?
I believe the socketCAN has to address the unix domain via the Linux File system.
if fpSelect(maxHandle + 1, @readSet, nil, nil, nil) >= 0 then begin
(* A message received on the inet domain socket must have a recognisable sender *)
(* since it might be needed for authentication purposes. A unix domain socket *)
(* can be assumed to be protected by local permissions and capabilities. *)
if (UnixDomainSocket() >= 0) and (fpFD_ISSET(UnixDomainSocket(), readSet) = 1) then
dispatchMessage(UnixDomainSocket(), false);
if (InetDomainSocket() >= 0) and (fpFD_ISSET(InetDomainSocket(), readSet) = 1) then
dispatchMessage(InetDomainSocket(), true)
end
...
begin // dispatchMessage(), invoked as above, 2nd param is hasFrom
FillByte(recvBuffer, SizeOf(recvBuffer), 0);
if hasFrom then begin (* Inet domain socket *)
FillByte(sa, SizeOf(sa), 0);
saLength := SizeOf(sa);
messageLength := fpRecvFrom(socket, @recvBuffer, SizeOf(recvBuffer), 0, @sa, @saLength)
end else begin (* Unix domain socket *)
saLength := -1;
messageLength := fpRecv(socket, @recvBuffer, SizeOf(recvBuffer), 0)
end;
(* There is no provision here for concatenated or fragmented messages, which we *)
(* of course shouldn't see since it's a datagram socket. Elsewhere, we try to *)
(* work out the MTU by looking at padded backbone messages. *)
...
(* The result of this may be subsequently retrieved using UnixDomainSocket().
If a .pid file indicates that an existing socket was created by an instance
of this program that no longer exists then delete it. Create a fresh Unix
Domain socket and save the handle, on failure save an error code. Both success
and failure are silent.
*)
procedure CreateUnixDomainSocket(socketName: string);
var
oldPid: longInt= -1;
pidName: string;
pidFile: text;
uid: TUid;
gid: TGid;
begin
if socketName[1] = '~' then begin
Delete(socketName, 1, 1);
socketName := UserHome() + socketName
end;
pidName := socketName + '.pid';
if FileExists(pidName) then
try
Write(StdErr, 'Opening old PID file... ');
Assign(pidFile, pidName);
Reset(pidFile);
try
Read(pidFile, oldPid);
WriteLn(StdErr, 'OK, ' + IntToStr(oldPid))
finally
Close(pidFile)
end
except
WriteLn(StdErr, 'failed');
oldPid := -1
end;
(* If we have managed to read a process ID file then check whether the relevant *)
(* process (an older instance of this program) still exists. If it does then we *)
(* shouldn't be trying to run this program, if it does not and a unix domain *)
(* socket exists then try to delete it. *)
if (oldPid >= 0) and FileExists('/proc/' + IntToStr(oldPid)) then begin
WriteLn(StdErr, 'WatchP0x already running, terminating.');
Halt(9)
end;
if oldPid >= 0 then begin
WriteLn(StdErr, 'Process ', oldPid, ' is not running');
try
if FileExists(socketName) then begin
Write(StdErr, 'Deleting old unix domain socket ', socketName, '... ');
DeleteFile(socketName);
if not FileExists(socketName) then
WriteLn(StdErr, 'OK')
else
WriteLn(StdErr, 'ineffective (critical error)')
end else
WriteLn(StdErr, 'No old socket')
except
WriteLn(StdErr, 'failed');
unixDomainSocketHandle := -Abs(ErrNo) (* Probably ESysEACCESS *)
end
end;
(* Delete old PID file since it might be owned by a different user. *)
if FileExists(pidName) then begin
Write(StdErr, 'Deleting old PID file... ');
try
DeleteFile(pidName);
if not FileExists(pidName) then
WriteLn(StdErr, 'OK')
else
WriteLn(StdErr, 'ineffective (critical error)')
except
WriteLn(StdErr, 'failed');
unixDomainSocketHandle := -Abs(ErrNo) (* Probably ESysEACCESS *)
end
end;
(* Create a new PID file. *)
try
Write(StdErr, 'Creating new PID file... ');
Assign(pidFile, pidName);
Rewrite(pidFile);
try
WriteLn(pidFile, IntToStr(GetProcessID()));
WriteLn(StdErr, 'OK, ', GetProcessID())
finally
Close(pidFile)
end
except
WriteLn(StdErr, 'failed (critical error)');
unixDomainSocketHandle := -Abs(ErrNo) (* Probably ESysEACCESS *)
end;
(* Create the socket. Note that there is no suitable fpBind() for this. *)
Write(StdErr, 'Creating new unix domain socket... ');
unixDomainSocketHandle := fpSocket(AF_UNIX, SOCK_DGRAM, 0);
if Bind(unixDomainSocketHandle, socketName) then
WriteLn(StdErr, 'OK')
else begin
WriteLn(StdErr, 'failed (continuing)');
unixDomainSocketHandle := -Abs(ErrNo) (* Probably ESysEACCESS *)
end;
(* Change socket owner and group to be the same as the executable, on the *)
(* assumption that this is the user that will be executing all programs. *)
// TODO : Bad assumption if setuid.
Write(StdErr, 'Changing socket''s ownership... ');
getOwner(ParamStr(0), uid, gid);
if fpChown(socketName, uid, gid) = 0 then
WriteLn(StdErr, 'OK')
else begin
WriteLn(StdErr, 'failed (continuing)');
// unixDomainSocketHandle := -Abs(ErrNo) (* Probably ESysEACCESS *)
end;
(* Set the socket to be writable by its owner (i.e. any cooperating program) *)
(* and readable by its group (this program). I don't think very much of doing *)
(* this but the computer on which this is running can be assumed to be *)
(* physically secure leaving the major risk being that somebody unauthorised *)
(* logs into it and runs one of this suite of programs. *)
Write(StdErr, 'Relaxing socket''s read/write permissions... ');
if fpChMod(socketName, &766) = 0 then
WriteLn(StdErr, 'OK')
else begin
WriteLn(StdErr, 'failed (continuing), might need CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_NET_RAW=p+e');
unixDomainSocketHandle := -Abs(ErrNo) (* Probably ESysEACCESS *)
end
(* Since we're about to reliquish admin capabilities we won't be able to delete *)
(* the socket at program termination. *)
end { CreateUnixDomainSocket } ;
(* The result of this may be subsequently retrieved using InetDomainSocket().
Assume that any existing socket was deleted when its owner terminated. Create
a fresh Inet Domain socket and save the handle, on failure save an error code.
Both success and failure are silent.
*)
procedure CreateInetDomainSocket(port: integer);
var
sockAddr: TSockAddr;
begin
Write(StdErr, 'Creating new Internet domain socket (UDP, port ', port, ')... ');
inetDomainSocketHandle := fpSocket(PF_INET, SOCK_DGRAM, 0);
try
sockAddr.sin_family:= AF_INET;
sockAddr.sin_port:= hToNS(port);
sockAddr.sin_addr.s_addr:= 0;
FillChar(sockAddr.sin_zero[0], SIZEOF(sockAddr.sin_zero), #0);
if fpBind(inetDomainSocketHandle, @sockAddr, SIZEOF(sockAddr)) = 0 then
WriteLn(StdErr, 'OK')
else begin
WriteLn(StdErr, 'failed, might need CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_NET_RAW=p+e');
inetDomainSocketHandle := -Abs(ErrNo)
end
except
WriteLn(StdErr, 'failed, might need CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_NET_RAW=p+e');
inetDomainSocketHandle := -Abs(ErrNo)
end
(* Assume that this will be deleted automatically at program termination. *)
end { CreateInetDomainSocket } ;
Recall my example from a previous post.
debian@ebb:~$ sudo /sbin/ip link set can1 up type can bitrate 250000 debian@ebb:~$ candump can1 can1 721 [1] 05 can1 1A1 [8] 20 00 FF 0F A8 FD A8 FD
...
So in general I get the feeling that to add socketCAN support to FPC will require a fairly extensive modification of the base sockets library. Is there any interest in this? Who's allowed to change it.
Noting that you seem to have demonstrated that the "plug-in" nature of the Linux network stack functionality is working properly... are you saying that this is purely an FPC issue rather than a kernel one? At that point I'd expect that a patch via Mantis would be appropriate, particularly since this appears to move FPC and possibly Lazarus into an area that it's not previously supported.
MarkMLl
Here's the example. I realize bind should probably be used but it doesn't make it past the socket call.Because you are trying to use "SAddr : TInetSockAddr;" (C sockaddr) with SocketCAN, while you need to use C sockaddr_can. CAN C headers have not yet been translated to FPC. You will at least need sockaddr_can, ifreq and can_frame structures. You can find ifreq structure in \fpcsrc\packages\libc\src\nifh.inc, but the rest only in /usr/src/linux-source-5.8/include/uapi/linux/can.h and /usr/src/linux-source-5.8/include/uapi/linux/can/ (raw.h, bcm.h, error.h ...) waiting for translation.
if fpconnect(socket_result, @SAddr, 0) = -1 then begin
if fpconnect(socket_result, @SAddr, 0) = -1 then begin
Why the third parameter of fpconnect is zero?
So in general I get the feeling that to add socketCAN support to FPC will require a fairly extensive modification of the base sockets library.PF_CAN is just a number. In linux sources you can find it defined as AF_CAN, which is defined as 29. So why don't you try that first?
EDIT: I see now that you are looking at sources of candump. It will be much easier if you use simpler example from here:
https://www.beyondlogic.org/example-c-socketcan-code/
Because I never got past the socket call and had not used bind which is what should be used. Wasn't even worried about fpconnect or the Saddr once I dove down into the socket library and saw that AF_CAN or PF_CAN equal to 29 was not supported which essentially means the socketCAN library working in C or Python also won't work.
if fpconnect(socket_result, @SAddr, 0) = -1 then begin
Why the third parameter of fpconnect is zero?
Well spotted ;-)
For that matter, I have a lot of trouble tying https://www.freepascal.org/docs-html/rtl/sockets/fpconnect.html to anything remotely relevant.
MarkMLl
Awe Crap! That's what I get for leaving a project for 2 months and then jumping back in not remembering where I stopped. In fact both you and Mark are correct that I'm using fpconnect incorrectly.
if fpconnect(socket_result, @SAddr, 0) = -1 then begin
Why the third parameter of fpconnect is zero?
/usr/src/linux-headers-5.10.0-0.bpo.3-common/include/linux/socket.hand I want to update file
fpcsrc/packages/rtl-extra/src/linux/unxsockh.inc
fpcsrc/packages/rtl-extra/src/android/unxsockh.incas well?
For a start, I would like to update fpc's linux kernel header translations with missing AF_CAN, PF_CAN and some other constants.
...
I only intend to test linux...
Those constants are only a start. I searched FPC files for them, and found where they are and what should be updated. I need a little guiding since it is not simple 1:1 header translation and there is a split into several files - probably because of cross platforming. Only when this work is finished, can and j1939 can build on them.For a start, I would like to update fpc's linux kernel header translations with missing AF_CAN, PF_CAN and some other constants.
...
I only intend to test linux...
Noting that the AF_ and PF_ constants are used by user and/or kernel code to express an interest in a particular protocol facet, and that there aren't helpers to extend enumerations and subranges, I think that as a matter of policy they're worth getting into header files etc. as soon as they are standardised by the IETF or whoever's authoritative.
As for the standardization... well, I don't know what to say. Try to search in sources for AF_BLUETOOTH and you will see that in some operating systems it is defined as 31 and in some as 36. It seams to be OS dependent and not tied to some standard...
The issue isn't only the AF_CAN and PF_CAN...That's why I said that updating socket wrapper with new constants is just a first step. Next step would be CAN through SocketCAN (not via socketcand daemon which already allows us to connect to CAN using ethernet), and after that SAE J1939 which is a layer on top of CAN. That's what I'm after. CAN FD is not in my focus, but I will probably add it, too.
My focus will be CANopen with a monitor program that runs equally well on PCs with Windows, LinuxCNC, Pi and Beagles. But I've worked with all sorts of CAN protocols..The issue isn't only the AF_CAN and PF_CAN...That's why I said that updating socket wrapper with new constants is just a first step. Next step would be CAN through SocketCAN (not via socketcand daemon which already allows us to connect to CAN using ethernet), and after that SAE J1939 which is a layer on top of CAN. That's what I'm after. CAN FD is not in my focus, but I will probably add it, too.
Awesome. You've probably already seen this but for convenience here's the link:That is the link I gave in my first reply to this topic. ;)
https://www.beyondlogic.org/example-c-socketcan-code (https://www.beyondlogic.org/example-c-socketcan-code)
I guess for example one would take the C code and create a Lazarus command line version of candump called pcandump to avoid mixing things up.My initial goal would be to make pascal versions of cantransmit, canreceive and canfilter from https://github.com/craigpeacock/CAN-Examples. Then I would probably move to J1939.
But it needs that sockets.pp (I think that was the file) modified to understand the AF_CAN and PF_CAN constants.Already done. With latest trunk you simply include sockets and those constants are available.
https://elinux.org/Can-utils (https://elinux.org/Can-utils)I am familiar with that, too. I am the author of https://github.com/linux-can/can-utils/blob/master/can-j1939-install-kernel-module.md :D
The above link is to an example which has a link to the source which has a link to the doc.
https://elinux.org/Can-utils (https://elinux.org/Can-utils)
The above link is to an example which has a link to the source which has a link to the doc.
I am familiar with that, too. I am the author of https://github.com/linux-can/can-utils/blob/master/can-j1939-install-kernel-module.md :D
Nice write-up on the install of can-J1939. I like the fact that you explain how to fix it when it goes wrong. So many people leave that out of their description. :)Thanks, you're very kind. I'm glad you like it. :)
Hi, can you tell me where I can finde the required can and can.raw units you use in your solutions (Send ,receive, filter)?Translated headers can be found in cantransmit.zip attached to message: https://forum.lazarus.freepascal.org/index.php/topic,39858.msg396883.html#msg396883. In just few days there have been almost 200 downloads. 8-) Since I have updated them a little, I have attached latest version of demos and all translated headers to this message.
Thanks and Best RegardsYou're most welcome. :D
You're most welcome. :D
@Avra: Wonderful! (like always with you ;))You're very kind and you're most welcome. :)
Many thanks.
cansend vcan0 456#DEADBEEF
cansend vcan0 123##1112233445566778899AABBCC
Just kidding :D :D :D. CAN XL is in testing phase and linux is not ready for it yet. But according to specification it should be compatible to CAN FD so we do not have to worry for now...
@Avra: Many thanks.You're most welcome. I'm glad it's of use to others. :P
Wouldn't it be better to upload your work to Bitbucket, Github, ..., and make an own repo for that?This is just a temporary public playground. My final goal is to make SocketCAN header translations and demos integral part of FreePascal, so that CAN works out of the box without downloading anything additional. Like Python and C already have.
I am also interested in the implementation of CAN for Lazarus.Nice to hear ;)
I wonder what the performance difference will be if I use:Any modern PC or SBC CPU is capable of handling CAN without problems. Bottleneck is communication channel. In case of Lawicel/SLCAN/CAN232 it is serial communication - if you use classic AVR ATMEGA328 based Arduino it is 115200 (STM32 or ESP32 based ones may use speeds higher then that so they do not have that problem), you don't use filters and want to see all of high speed CAN traffic then expect to miss frames here and there. Using MCP2518 direct via SPI on Raspberry Pi or PocketBeagle for CAN and CAN FD is solid and comfortable. I haven't used MCP2518 over MCP2210 but I guess that might also skip frames. SocketCAN is just a Berkeley sockets abstraction layer over any Linux CAN hardware, and you use it the same with both SPI MCP2518 and Lawicel/SLCAN/CAN232 (there is no driver for MCP2518 over MCP2210). So, performance does not suffer if you use SocketCAN.
1) This solution via SocketCAN
2) Direct control of IC MCP2518 via SPI bus using Lazarus
3) Direct control of IC MCP2518 via USB using IC MCP2210 (USB to SPI driver) libusb
I'm interested because I want the application to work under both Windows and Linux. When I use MCP2210 and MCP2518, I can control the CAN driver via SPI directly in Windows and Linux. If I use SocketCAN, then I have to implement another solution for Windows.Well, you said it all. Since you want your app to be used on both Windows and Linux, unfortunately you need to give up SocketCAN (unless someone implements it under Windows). Your best bet would be to use some STM32 or ESP32 Lawicel/SLCAN/CAN232 using higher serial speeds, which would probably avoid frame dropping unless you use it on a very, very high traffic 1Mbit CAN.
Just to add, the MCP2210 is a High Speed USB HID driver for the SPI bus with speeds from 1500bps to 12Mbps, so there will be no bottleneck. The only problem is that I need to constantly read the 64 byte register to see if the MCP2518 has received any data, this may cause some CPU usage.It doesn't matter how fast you set it's SPI to talk to CAN chip. It seams to use USB HID, which is limited to 1000 messages per second where each message can have up to 64 bytes. You do the math. Ah yes, and while you are transferring data over USB you can not get new CAN messages.
Thank you for the work to get the CANsocket working.You're most welcome. ;)
I pulled in the files from can.zip and it worked. I am using an older version of FPC on the raspberry Pi. The example worked. I used that code as a template for my Lazarus project.Thank you for the report. I didn't catch time to test on Pi and PocketBeagle yet, so I'm glad to hear it works on Pi. Just for info, could you tell me what CAN hardware did you use during testing?
I needed an Extended ID. Will look at that tomorrow. Might just need to set the extended ID manually before stuffing the value into the frame field.So far I have attached enough for 1:1 translation of various C examples you can find on the net. Right now I am working on bit packed overlays which would allow easy access to individual bits, and some higher level helper methods. After that I will probably add SAE J1939 (for trucks, buses, tractors, boats and heavy machinery) where Extended ID is used, and at the end provide a FPC patch so that we can all use SocketCAN out of the box.
I am running on a Raspberry Pi 4.Thanks for the report. I guess with 3.0.4 you had to manually add missing CAN constants.
Raspbian GNU/Linux 10
FPC version is: 3.0.4+dfsg-22+rpi1
Lazarus: 2.0.0+dfsg-2 2019-03-01
I am using a USB to CAN adapter from www.inno-maker.com.
You do have to enable it with a couple of commands:That's pretty standard for a CAN device that kernel can recognize.
'sudo ip link set can0 type can bitrate 250000'
'sudo ifconfig can0 up'
I did get extended addressing to work. Like I suggested, I just had to set bit 31 to select it before writing the ID into the frame structure.I know. That's why I said "I am working on bit packed overlays which would allow easy access to individual bits". ;)
avra@vm-debian:/mnt/e/can$ ./hlcanerrdump
CAN Sockets Error Messages Dump
Usage: hlcanerrdump <CAN interface> [options]
CAN interface: ( CAN interface is case sensitive )
can1 ( or can2, can3 or virtual ones like vcan0, vcan1...
Options: ( options are not case sensitive )
( ERROR CLASS (MASK) IN CAN ID: )
IgnoreTxTimeout ( filter TX timeout by netdevice driver error messages )
IgnoreLostArbitration ( filter lost arbitration error messages )
IgnoreController ( filter controller problem error messages )
IgnoreProtocol ( filter protocol error messages )
IgnoreTransceiver ( filter transceiver status error messages )
IgnoreNoAck ( filter no ACK on transmission error messages )
IgnoreBusOff ( filter bus off error messages )
IgnoreBusError ( filter bus error messages )
IgnoreRestarted ( filter controller restarted messages )
( DEBUG HELPERS: )
ShowFilterAndMaskBits ( display all filtering bits )
Examples:
./hlcanerrdump can1
( dump all CAN error messages from CAN interface can1 )
./hlcanerrdump vcan0 IgnoreNoAck IgnoreBusOff
( dump all CAN error messages from virtual CAN interface vcan0 except NoACk and BusOff)
avra@vm-debian:/mnt/e/can$ ./hlcanerrsim
CAN Sockets Error Messages Simulator
Usage: hlcanerrsim <CAN interface> [options]
CAN interface: ( CAN interface is case sensitive )
can1 ( or can2, can3 or virtual ones like vcan0, vcan1...
Options: ( options are not case sensitive )
( ERROR CLASS (MASK) IN CAN ID: )
TxTimeout ( TX timeout by netdevice driver )
NoAck ( received no ACK on transmission )
BusOff ( bus off )
BusError ( bus error, may flood! )
Restarted ( controller restarted )
( ARBITRATIONLOST IN CAN ID + BIT NUMBER IN DATA[0]: )
LostArbitrationBit=<00..29> ( decimal bit number in bitstream )
( CONTROLLER IN CAN ID + ERROR STATUS IN DATA[1]: )
OverflowRX ( RX buffer overflow )
OverflowTX ( TX buffer overflow )
WarningRX ( reached warning level for RX errors )
WarningTX ( reached warning level for TX errors )
PassiveRX ( reached error passive status RX, errors > 127 )
PassiveTX ( reached error passive status TX, errors > 127 )
Active ( recovered to error active state )
( PROTOCOL ERROR IN CAN ID + TYPE IN DATA[2]: )
SingleBit ( single bit error )
FrameFormat ( frame format error )
BitStuffing ( bit stuffing error )
Bit0 ( unable to send dominant bit )
Bit1 ( unable to send recessive bit )
BusOverload ( bus overload )
ActiveAnnouncement ( active error announcement )
TX ( error occurred on transmission )
( PROTOCOL ERROR IN CAN ID + LOCATION IN DATA[3]: )
SOF ( start of frame )
ID28_21 ( ID bits 21..28, SFF: 3..10 )
ID20_18 ( ID bits 18..20, SFF: 0..2 )
SRTR ( substitute RTR, SFF: RTR )
IDE ( identifier extension )
ID17_13 ( ID bits 13..17 )
ID12_05 ( ID bits 5..12 )
ID04_00 ( ID bits 0..4 )
RTR ( RTR )
RES1 ( reserved bit 1 )
RES0 ( reserved bit 0 )
DLC ( data length code )
DATA ( data section )
CRC_SEQ ( CRC sequence )
CRC_DEL ( CRC delimiter )
ACK ( ACK slot )
ACK_DEL ( ACK delimiter )
EOF ( end of frame )
INTERM ( intermission )
( TRANSCEIVER ERROR IN CAN ID + STATUS IN DATA[4]: )
( CANH CANL )
TransUnspec ( 0000 0000 )
CanHiNoWire ( 0000 0100 )
CanHiShortToBAT ( 0000 0101 )
CanHiShortToVCC ( 0000 0110 )
CanHiShortToGND ( 0000 0111 )
CanLoNoWire ( 0100 0000 )
CanLoShortToBAT ( 0101 0000 )
CanLoShortToVCC ( 0110 0000 )
CanLoShortToGND ( 0111 0000 )
CanLoShortToCanHi ( 1000 0000 )
( CUSTOM BYTE TO DATA[0..7]: )
Data<0..7>=<00..FF> ( write hex number to one of 8 payload bytes )
Examples:
./hlcanerrsim can1 LostArbitrationBit=09 TX BusOff Data7=AA Data6=BB
( can1: 9th arb. bit lost, transmission, bus off, controller specific info in Data[6] and Data[7] )
./hlcanerrsim vcan0 NoAck TxTimeout Active
( vcan0: received no ACK on transmission, driver timeout, protocol type active error announcement )
./hlcanerrsim vcan0 BusError CanHiNoWire Restarted INTERM
( vcan0: bus error, lost CANH wiring, controller restarted, protocol location intermission )
is there already a way to perform the actions which the 'ip' command does in pascal?Calling ip command from your pascal application and parsing the output would be the simplest solution. If you are not satisfied with that, you would have to use NETLINK sockets, since that is what ip command uses. Alternatively, you could use libsocketcan (a wrapper around netlink sockets for CAN) or libnl, but you would need to make your own wrapper.
like "sudo ip link set can0 type can bitrate 125000 sample-point 0.875"
and "sudo ip link set can0 up"
and "sudo ip link set can0 down"?
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.
No errors during compilation, but return code is -1.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
Where is my error?
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.
What device(s) do you use to interface with CAN bus?Pi, PocketBeagle and Arduino (AVR, STM32, ESP32)
What device(s) do you use to interface with CAN bus?Pi, PocketBeagle and Arduino (AVR, STM32, ESP32)
What device(s) do you use to interface with CAN bus?Pi, PocketBeagle and Arduino (AVR, STM32, ESP32)
Does Arduino (AVR) has to be some specific type (e.g. AT90CAN128) or any will do?
What do you use between 'controller' and CAN bus?
This thread mentions C to Pascal translation several times. I'm wondering if this is not also an opportunity to test out some of the automatic C to Pascal or C to Delphi translators. Probably wouldn't be as good as being done manually by someone very fluent in both, but perhaps the automatic software could be useful in various cases.I use these all the time. They are good, but not perfect and I usually have to combine them. They can save you a lot of time, but can not save you from manual work completelly.
For now, there is no plan to support libsocketcan.
I found that in the recent can-utils.Not everything is related to CAN. If you take a look at candump.c from can-utils you will see that it includes sys/epoll.h which is a standard linux header for which there is a man page https://linux.die.net/man/2/epoll_wait. As such, you could also search your fpc directory and find that translation for epoll_wait can already be found in your existing \fpcsrc\rtl\linux\linux.pp, so you already have everything needed.
But the num_events is always either 0 or 1 even if more than 1 message was sent to the port.I am in the middle of industrial plant commissioning, so I will not be able to take a look at this before next week.
I am in the middle of industrial plant commissioning, so I will not be able to take a look at this before next week.
But the num_events is always either 0 or 1 even if more than 1 message was sent to the port.Based on a quick look, it seams to me that instead of a single PEPoll_event you should try to create an array of PEPoll_event, pass number of elements to epoll_create(), and pass PEPoll_event array to epoll_wait(). Exactly аs in C demo that you can find at https://linux.die.net/man/7/epoll. I know that epoll_create() with kernels newer then 2.6.8 should not care for size parameter (as long as it's positive), but C demo thinks that it does matter so you should probably listen to it (at least until you make it work).
I converted the LibSocketCAN library into a Pascal Unit.Very nice and thank you! If you agree to put the same license as in my CAN wrapper and demos, then I can add your wrapper also - if you add some simple console demo (of course, it will be clear who is the author of which file). What I would probably do is rename LibSockCAN.pas to can.lib.pas, and rename if_linkpart.pas (which is missing, btw) to can.if.linkpart.inc and include it from can.lib unit. What do you think?
(at least until you make it work).I actually don't care how many events occur, because the epoll is fixed to the event EPOLLIN. As long as the query returns '1' there is data to read, if
Very nice and thank you! If you agree to put the same license as in my CAN wrapper and demos, then I can add your wrapper also - if you add some simple console demo (of course, it will be clear who is the author of which file).I can rework the whole stuff, no problem
What I would probably do is rename LibSockCAN.pas to can.lib.pas, and rename if_linkpart.pas (which is missing, btw) to can.if.linkpart.inc and include it from can.lib unit. What do you think?
Is really a console application required? A GUI exists, which I left out of the .zip due to its size and in case of a console app I would have to do a cmd parser......Although you can find basic cmd parsers in hlcanerrdump and hlcanerrsim, there is really no need to go that far. Just fix interface name and other needed parameters in code and that shall be fine. GUI advanced demos are nice, but SocketCAN package will be part of FPC and there is a good chance that it will run on a headless SBC without Lazarus, so simple console demos are more important.
Thanks! It would be great if you could use license templates from my demos and wrappers.What I would probably do is rename LibSockCAN.pas to can.lib.pas, and rename if_linkpart.pas (which is missing, btw) to can.if.linkpart.inc and include it from can.lib unit. What do you think?I can do the renaming, the licensing stuff and and check if all is available, no problem.
I am working on another topic : https://forum.lazarus.freepascal.org/index.php/topic,54944.msg408418.html#msg408418 (https://forum.lazarus.freepascal.org/index.php/topic,54944.msg408418.html#msg408418)Nice. I wrote a solution proposal there.
and want to solve that too.
Pic of the GUI attached.
sorry for the late reply, I changed job so my days are very busy....Take your time. No rush.
I will review the new demo and come back.
About integration of LibSocketCAN into can.hl my two cents are keep it as an tool on top, because it is not always needed but a grip to do some diagnostics.Your wrapper will stay as can.lib unit, and future pascalish thin wrapper will be a separate can.lib.hl unit. That way we will still be able to easily convert C demos when needed, while having more eye pleasing pascalish named access as with the rest of the high level CAN.
@jcdammeyer: CAN FD receive and transmit demos are here. It was not trivial to find info of what exactly to change when compared to legacy CAN but it works now. 8-)
Oh my gosh. I've finally finished a fairly large work-work project this summer and was thinking about getting back to this and I must have missed an email that the thread had been updated.I'm glad you like the progress. :D ;) :D
Wow!
I'm glad you like the progress. :D ;) :DThe problem with CANopen is it's huge and for 99% of the projects (IMHO) doesn't need to be. For example, a big deal is made over the support of the configuration files. Useful for the non-programmer mechanical engineer or installer but for someone who writes in Delphi or Lazarus not so much. Building up the object dictionary (OD) to show the size of variables pointless and just takes up a lot of code/data space. Creating a be all end all installation would be nice but also overkill and hard to understand and maintain.
If you need CANopen now, then you will have to implement it on your own. Patches are welcome.
To migrate to socketCAN it will need a level of abstraction built in so we can open a device like the internal processor built in CAN on a BeagleBone or a Pi3 HAT that uses the MCP2515 SPI to CAN device and of course the socketCAN version of CANUSB.Step-by-step guide on using Lawicel CANUSB via SocketCAN: https://pascal-walter.blogspot.com/2015/08/installing-lawicel-canusb-on-linux.html
To migrate to socketCAN it will need a level of abstraction built in so we can open a device like the internal processor built in CAN on a BeagleBone or a Pi3 HAT that uses the MCP2515 SPI to CAN device and of course the socketCAN version of CANUSB.Step-by-step guide on using Lawicel CANUSB via SocketCAN: https://pascal-walter.blogspot.com/2015/08/installing-lawicel-canusb-on-linux.html
I've dumped CAN packets from working systems using socketCAN with the CANUSB on the PI3/4. But that's using the C language command line programs.As you progress through pascal SocketCAN demos, you will see that low level units will help when you want to convert C examples from the net since it will mostly be 1:1 translation as far as SocketCAN part is concerned. Once you get a feeling, you will quickly advance to more natural pascalish high level unit.
Really looking forward to playing with your socketCAN stuff.I wish you as much fun as I have! :D
I wish you as much fun as I have! :DNot quite yet.
BBB sockets.pp doesn't have PF_CANAs mentioned at https://forum.lazarus.freepascal.org/index.php/topic,39858.msg396135.html#msg396135 you need newer FPC so getting trunk would be a good idea. If that is not for you, then instead you could simply define missing constants PF_CAN and AF_CAN as 29 somewhere in your code. After that, it would be good to create vcan0 virtual adapter and go through demos since they should all work out of the box.
Would you be able to create a canreceive.zip with a console application who's sole purpose is to open say slcan0 and just dump out messages like your canreceive.Once you have demos working with vcan0, making them work with slcan0 should be trivial. For example, in canreceive.lpr or hlcanreceive.lpr, all you need is to replace 'vcan0' with 'slcan0' at one place in code (as shown in your 3rd attachment).
Sadly this link doesn't work anymore which is why I posted the question.BBB sockets.pp doesn't have PF_CANAs mentioned at https://forum.lazarus.freepascal.org/index.php/topic,39858.msg396135.html#msg396135 you need newer FPC so getting trunk would be a good idea. If that is not for you, then instead you could simply define missing constants PF_CAN and AF_CAN as 29 somewhere in your code. After that, it would be good to create vcan0 virtual adapter and go through demos since they should all work out of the box.
CAN constants have been added to FPC 48867:In fact I can't even access https://svn.freepasccal.org
https://svn.freepascal.org/svn/fpc/trunk/packages/rtl-extra/src/linux/unxsockh.inc
QuoteCAN constants have been added to FPC 48867:In fact I can't even access https://svn.freepasccal.org
https://svn.freepascal.org/svn/fpc/trunk/packages/rtl-extra/src/linux/unxsockh.inc
debian@ebb:~/lazarus/AvraCAN$ ./ConsoleApplication
Hello World from Console Application
CAN Sockets Receive Demo Rev 0.01
fpsocket call
fpioctl call
fpbind call
fpread call
Standard CAN frame received with length 1
0x718 [1] 05
debian@ebb:~/lazarus/AvraCAN$
debian@ebb:~/lazarus/AvraCAN$ ./ConsoleApplication
CAN Sockets Receive Demo Rev 0.1 Build 5
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 718 [1] 05
debian@ebb:~/lazarus/AvraCAN$
CAN Sockets Receive Demo Rev 0.1 Build 5
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 298 [7] 02 44 00 00 01 00 02
slcan0 298 [7] 00 66 00 00 06 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 66 00 00 06 00 00
slcan0 298 [7] 00 66 00 00 06 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 66 00 00 06 00 00
slcan0 298 [7] 00 66 00 00 06 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 718 [1] 05
debian@ebb:~$ candump can1
can1 298 [7] 00 44 00 00 01 00 00
can1 718 [1] 05
can1 298 [7] 00 44 00 00 01 00 00
can1 298 [7] 00 44 00 00 01 00 00
can1 718 [1] 05
can1 298 [7] 00 44 00 00 01 00 00
^Cdebian@ebb:~$ cd lazarus/AvraCAN/
debian@ebb:~/lazarus/AvraCAN$ ./ConsoleApplication
CAN Sockets Receive Demo Rev 0.1 Build 6
can1 298 [7] 00 44 00 00 01 00 00
can1 718 [1] 05
can1 298 [7] 00 44 00 00 01 00 00
can1 298 [7] 00 44 00 00 01 00 00
can1 718 [1] 05
can1 298 [7] 00 44 00 00 01 00 00
can1 298 [7] 00 44 00 00 01 00 00
can1 718 [1] 05
debian@ebb:~/lazarus/AvraCAN$ sudo ifconfig slcan0 up
[sudo] password for debian:
debian@ebb:~/lazarus/AvraCAN$ ./ConsoleApplication
CAN Sockets Receive Demo Rev 0.1 Build 7
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 718 [1] 05
debian@ebb:~/lazarus/AvraCAN$
I also did put them into unxsockh.inc but it didn't have any effect.That would have also worked after FPC rebuilding.
No idea why canreceive.lpr won't compile into an executable.What is the compilation error message? What FPC/LAZ/OS/ARCH/Bitness combo was used? Did you manage to compile other demos?
Also back in 2013 when I attended the CANopen Conference in Germany the attached pdf was one of the presentations.Nice and simple bridge and ISO examples.
Unfortunately at this point you lose me on what to do there. I ran fpcupdeluxe to install the same version on the PC, Pi3/4 and BBB. I would need the simpleton step by step procedure to do the 'FPC rebuilding' along with a "why I am doing what I'm doing"I also did put them into unxsockh.inc but it didn't have any effect.That would have also worked after FPC rebuilding.
I opened up the .lpi project from Lazarus and did a build. The screen capture I posted earlier and again here shows the result. I tried a number of options with no success in creating an executable. That's when I used the lazarus 'new' and selected console application program to create my stock application. Then coppied and pasted the key parts that were needed to duplicate the basic functionality of candump.No idea why canreceive.lpr won't compile into an executable.What is the compilation error message? What FPC/LAZ/OS/ARCH/Bitness combo was used? Did you manage to compile other demos?
Also back in 2013 when I attended the CANopen Conference in Germany the attached pdf was one of the presentations.Nice and simple bridge and ISO examples.
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 298 [7] 00 00 00 00 01 00 00
slcan0 318 [1] 04
slcan0 12345678 [1] 00
slcan0 718 [1] 05
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 718 [1] 05
slcan0 298 [7] 00 44 00 00 01 00 00
slcan0 318 [1] 00
slcan0 12345678 [1] 00
slcan0 298 [7] 00 00 00 00 01 00 00
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Application
Icon=/home/debian/fpcupdeluxe/lazarus/images/icons/lazarus.ico
Exec=/home/debian/fpcupdeluxe/lazarus/lazarus --pcp="/home/debian/fpcupdeluxe/config_lazarus" %f
Name=Lazarus_fpcupdeluxe
GenericName=Lazarus IDE with Free Pascal Compiler
Category=Application;IDE;Development;GUIDesigner;Programming;
Categories=Application;IDE;Development;GUIDesigner;Programming;
Keywords=editor;Pascal;IDE;FreePascal;fpc;Design;Designer;
FPC rebuild steps for Windows: https://forum.lazarus.freepascal.org/index.php/topic,55358.msg411825.html. Shouldn't be too difficult to adapt for Linux. Ah, yes... do not forget to rebuild Lazarus as well, so IDE can be aware of FPC changes.Unfortunately at this point you lose me on what to do there. I ran fpcupdeluxe to install the same version on the PC, Pi3/4 and BBB. I would need the simpleton step by step procedure to do the 'FPC rebuilding' along with a "why I am doing what I'm doing"I also did put them into unxsockh.inc but it didn't have any effect.That would have also worked after FPC rebuilding.
I can see on the screenshot that compilation was a success, so canreceive file should be created. It also seams that you tried to run it from IDE, which I do not recommend. Better try to run it from the terminal. If file canreceive exists, then maybe you just need to manually flag it as an executable? What about other demos? Could you compile them and run, or not?QuoteI opened up the .lpi project from Lazarus and did a build. The screen capture I posted earlier and again here shows the result. I tried a number of options with no success in creating an executable.No idea why canreceive.lpr won't compile into an executable.What is the compilation error message? What FPC/LAZ/OS/ARCH/Bitness combo was used? Did you manage to compile other demos?
I do have a zip of the entire conference proceedings (47MB) including my presentation (1.4MB) all too big to post here.What was the topic of your presentation?
The Pi4 has the folder fcpupdeluxe as shown in the attached photo. However there's no shortcut to it on the desktop. I don't remember at what point I stopped with the installation or if I even installed it.Excluding path difference, I have identical desktop shortcut on my Debian XFCE system so you should be good to copy and use yours in another system.
The BBB has this as the desktop link:
debian@ebb:/$ sudo find / -name canreceive*
[sudo] password for debian:
/home/debian/lazarus/AvraCAN/canreceive.lpi
/home/debian/lazarus/AvraCAN/canreceive.lpr
/home/debian/lazarus/AvraCAN/backup/canreceive.lpi
/home/debian/lazarus/AvraCAN/backup/canreceive.lpr
/home/debian/lazarus/AvraCAN/backup/canreceive.lps
/home/debian/lazarus/AvraCAN/canreceive.lps
debian@ebb:/$
1. Really. It didn't compile it. Very strange.Do you have problems generating executable only with canreceive demo, or you have problems with all demos (hlcanreceive...)? If all demos suffer the same problem, then it might be dir/file access rights problem and you could try another directory or fix access rights.
1. Really. It didn't compile it. Very strange.Do you have problems generating executable only with canreceive demo, or you have problems with all demos (hlcanreceive...)? If all demos suffer the same problem, then it might be dir/file access rights problem and you could try another directory or fix access rights.
1. Really. It didn't compile it. Very strange.Do you have problems generating executable only with canreceive demo, or you have problems with all demos (hlcanreceive...)? If all demos suffer the same problem, then it might be dir/file access rights problem and you could try another directory or fix access rights.
Haven't had a chance to try that yet. Yesterday was a battle to get fpcupdeluxe installed on the Pi4 LinuxCNC.
So today I'll take another look at your examples. Are you compiling them from within Lazarus or just using FPC and command line?
Attached latest SocketCAN with fixed example projects LPIs. Old Lazarus is now able to open all projects.
After seeing that your project inspector is empty, and that when comparing LPIs - one XML file has <BuildModes Count = "1"> and the other one has just <BuildModes>, it is clear that all LPI files have been saved in new Lazarus 2.1+ XML file format, and that was the reason why you have not been able to load project properly, because you have old Lazarus 2.0. For a quick fix you can use this tool: https://sourceforge.net/p/lazarus-ccr/svn/HEAD/tree/applications/fixlp/, but as a permanent solution I will change all project files to be saved in old compatibility mode.
After seeing that your project inspector is empty, and that when comparing LPIs - one XML file has <BuildModes Count = "1"> and the other one has just <BuildModes>, it is clear that all LPI files have been saved in new Lazarus 2.1+ XML file format, and that was the reason why you have not been able to load project properly, because you have old Lazarus 2.0. For a quick fix you can use this tool: https://sourceforge.net/p/lazarus-ccr/svn/HEAD/tree/applications/fixlp/, but as a permanent solution I will change all project files to be saved in old compatibility mode.
I've downloaded it to my PC and then dragged and dropped onto the Pi and the Beagle via windows explorer. Since I'm running 2.0.10 on the Windows systems too I'll also try it there.
I recall from looking at older Delphi libraries that I thought I saw {$ifdef... statements that tested versions of the compiler. Should that not then be in socketCAN libraries so if one tries to compile applications that require > 3.2.x that the compiler complains and stops. If sample applications are dependent on that then should that not also exist in those samples?It was never meant to make SocketCAN a library that works with any FPC version. It can be forced but it would be a mine field which I do not recommend. In one of the old messages in this thread you can find exact FPC revision that I added missing constants to, and which has everything else needed - but if you do not feel like hunting it down, then current trunk FPC will do. This is just a playground and SocketCAN will be part of FPC, so there will be no need for ifdefs in code. As for Lazarus, my last can.zip does not depend on Lazarus 2.1+ any more and should work with any Lazarus 2.0.x and maybe even older.
The two windows systems (WIN-7 and WIN-10) have been upgraded to trunk and trunk.Since projects can now be opened in older Lazarus, there was no real need to use Lazarus trunk, but it will not hurt. In case you want to be able to open your own projects saved with Lazarus 2.1+ in Lazarus 2.0.x and older, you can go to Project Options / Misellaneous and check Maximize compatibility of project files (LPI and LPS). That's all I did in latest can.zip, so fixlp is not needed any more.
And therein lies the problem with constantly updating. All the lpk packages have to be rebuilt and installed into the IDE. It was always the worst part of upgrading Delphi too.If you use fpcupdeluxe, then once you install it in one OS/CPU combo, you can simply copy whole dir and desktop shortcut to another machine with the same (or compatible) OS/CPU combo. That's all. No need for reinstallation all over again. And sometimes cross compilation can also save the day...
Since projects can now be opened in older Lazarus, there was no real need to use Lazarus trunk, but it will not hurt. In case you want to be able to open your own projects saved with Lazarus 2.1+ in Lazarus 2.0.x and older, you can go to Project Options / Misellaneous and check Maximize compatibility of project files (LPI and LPS). That's all I did in latest can.zip, so fixlp is not needed any more.
If you use fpcupdeluxe, then it would be wise to write down exact revision of FPC and LAZ combo you used at one place, and then tell fpcupdeluxe to download that exact combo on each system you use for SocketCAN. That would eliminate a lot of ifs in case of problems.And therein lies the problem with constantly updating. All the lpk packages have to be rebuilt and installed into the IDE. It was always the worst part of upgrading Delphi too.If you use fpcupdeluxe, then once you install it in one OS/CPU combo, you can simply copy whole dir and desktop shortcut to another machine with the same (or compatible) OS/CPU combo. That's all. No need for reinstallation all over again. And sometimes cross compilation can also save the day...
...that created the same problem from 6 months ago... Had to go back through all my postings to find that solution and now the sample 7 segment programs work on all three systems.Well, LCL evolves so from time to time you need to check your projects for compatibility. SocketCAN should work with your old Lazarus, but your project which uses some GUI features that changed in newer Lazarus was the reason for incompatibility. Glad you fixed that after all.
In either case, updating to 3.3.1 allows all your examples to compile. Thanks for all your help.You're most welcome. I'm glad that you can finally compile all SocketCAN demos.
Noting that this is the dominant Canbus thread: what interface hardware are people using for general development on a PC? I might need to prod at a vehicle subsystem with Canbus as one (fortunately not the only one) of the interfaces.
MarkMLl
It's because I have four of the CANUSB from Lawicel in Sweden that it is one of the first tools I grab but the software support for monitoring isn't the best. I think there are clones from China for even less.
Noting that this is the dominant Canbus thread: what interface hardware are people using for general development on a PC? I might need to prod at a vehicle subsystem with Canbus as one (fortunately not the only one) of the interfaces.
For the Beagle I have a cape with the CAN and RS485 driver. For the Pi I have a single and dual CAN cape both using SPI.
Noting that this is the dominant Canbus thread: what interface hardware are people using for general development on a PC? I might need to prod at a vehicle subsystem with Canbus as one (fortunately not the only one) of the interfaces.
Linux has best tools and allows greatest hacking capability, so you could use these (Pi based on MCP2515):For the Beagle I have a cape with the CAN and RS485 driver. For the Pi I have a single and dual CAN cape both using SPI.
Lawicel based ones work with both Windows and Linux (and can occasionally drop frames on very congested 1Mbit networks), but above ones are my favorites (especially if you have proper DBC files for automatic data decoding). For software/hardware specifics read my older messages.
Thanks for that. I see http://www.can232.com/?page_id=16 and note that that's described as having an FTDI interface, so I've got a fair degree of confidence that Linux will see it (as remarked elsewhere, I've bought lots of stuff over the last year or so that has an embedded serial chip).
Is the clone you're thinking about something like https://www.ebay.co.uk/itm/143099880796 ?
I can see the various SPI interfaces, but at least initially I want to be able to exercise some kit from my desk.
MarkMLl
Noting that this is the dominant Canbus thread: what interface hardware are people using for general development on a PC? I might need to prod at a vehicle subsystem with Canbus as one (fortunately not the only one) of the interfaces.
Linux has best tools and allows greatest hacking capability, so you could use these (Pi based on MCP2515):For the Beagle I have a cape with the CAN and RS485 driver. For the Pi I have a single and dual CAN cape both using SPI.
Lawicel based ones work with both Windows and Linux (and can occasionally drop frames on very congested 1Mbit networks), but above ones are my favorites (especially if you have proper DBC files for automatic data decoding). For software/hardware specifics read my older messages.
most USB interfaces start to break down above 115Kbaud. Although DMX512A for light shows are 250kbaud.
Thanks for the reminder about grounding and the extra link, I actually had much of that stuff drummed into me when I was hooking up an early not-quite-PC LAN in about 1984 :-)
For the moment this is strictly desktop-experimentation (well, desktop plus a cable to my antenna mast) and if anything production comes of it cost will be little object (you ought to see the cost of the traditional opposition...)
MarkMLl
Just remember that UARTs have 'BAUD' rates and CAN has BitRates. BAUD is derived from Baudot and 5 bits of data with a start bit and two stop bits. Now of course we tend to use 8 bits with one start and one stop. So a Baud rate of 9600 baud means exactly 960 characters per second. Calling CAN rate a baud rate tells you nothing.most USB interfaces start to break down above 115Kbaud. Although DMX512A for light shows are 250kbaud.
Particularly if they use a counterfeit chip. I'm amassing a photo collection...
As a slight aside, if deciding on a default "Baud rate" ** for a serial link it's worth considering that some Arduino-like devices (e.g. ESP32) don't support below 38k4.
MarkMLl
** I know, that's why I put it in quotes.
A colleague at Lowbrow had had his PhD (possibly at Liverpool) paid for by Ripaults designing a vehicle data bus. He joined at the same time as I did- late '83- which gives some idea of the timeframe... there must have been many companies working on the same thing.
MarkMLl
Ground is a fundamental part of the circuit and it's find if you have an arduino or Pi which is also powered from the vehicle 12V power system as at some point the arduino power ground matches up with the vehicle CAN bus ground.There are galvanic isolated Pi shields like https://www.sg-electronic-systems.com/can-bus-dual-iso-v2-1-shield-for-raspberry/ which help when you must have separate power supply for your equipment. I solve that problem simply by powering Pi from the vehicle (Pi Zero is sufficient for CAN hacking), and then ssh or vnc to Pi from my laptop via WiFi. I even have a 4.3" display and small wireless keyboard for the Pi, but I find laptop access more convenient in 90% of the cases.
(Later:) I've ordered one of those cheap interfaces and will report back.There are AVR, ESP32 and STM32 projects which implement Lawicel protocol, so if at the end you become unsatisfied with your device then you can go DIY path.
(Later:) I've ordered one of those cheap interfaces and will report back.There are AVR, ESP32 and STM32 projects which implement Lawicel protocol, so if at the end you become unsatisfied with your device then you can go DIY path.
... I solve that problem simply by powering Pi from the vehicle (Pi Zero is sufficient for CAN hacking), and then ssh or vnc to Pi from my laptop via WiFi.Happy me just ordered 2 of these new toys: https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/
(Later:) I've ordered one of those cheap interfaces and will report back. My suspicion is that that jumper probably ties one side of the data to (USB) ground...
I need to load a custom module and bring a link up manuallyThat is normal. See https://pascal-walter.blogspot.com/2015/08/installing-lawicel-canusb-on-linux.html
I'm attached on a one-to-one basis to a device with documented addresses, and I need to read and possibly write some of those. Any suggestions would be appreciatedInstall can-utils. Although there are other tools you can find if you search through my older messages in this thread, everything needed is already there. It is best if you have CAN messaging docs for your devices, but CAN hacking is not that hard, either. In hacking you try to physically change something on your device and while spying CAN network you try to interpret data changes you see in the messages (CAN data messages are usually heavily bit packed records with no bits wasted and no byte alignment). Without docs it will be hard to guess how to send data to device, so it might be helpful to already have a device which writes to target device. Then all you need is to spy those messages and simply replicate them or try to guess the message data structure when you need to have a variable parameter.
I'm in the middle of making a T-cable to tap into a live system, which needs a couple of moderately-expensive connectorsThere are contactless crocodile clips which can be used if you only need to spy data without sending anything (like just spying J1939):
Impressive work!Thanks! ;)
How do I do if I want to find out which channels that are available on the device (can0, can1, etc.)?Using ifconfig from net-tools package can show CAN device interfaces that you have already brought up:
If I want to list the devices in my FPC application, how can I get the devices through FPC code?Either asume that ifconfig is installed and each CAN interface has CAN word in it's name so you can use output of this command line: