75XX CAN
The FPGA contains a SJA1000C compatible CAN controller that can be accessed using canctl which provides a CAN network service. Any application on the network can make use of this service to send or receive CAN packets using the API defined by canctl. Thus, it is possible to develop code written in other languages (java, python, etc.) and/or to run this code under other operating systems.
The canctl server is started by running:
Note: | Due to a bug in some releases, daqctl will grab the IRQ before canctl. If CAN is unable to take the IRQ you can stop the daqctl process to reclaim it:
killall daqctl
canctl --server
|
The easiest interface to CAN is calling "canctl" through the command line:
canctl --port=127.0.0.1 --txdat=01:02:03:04:05:06
# canctl --help Technologic Systems CAN controller manipulation. -a | --address=ADR CAN register address -b | --baud=BAUD CAN baud rate (7500 to 1000000) -R | --peek8r CAN register read -W | --poke8w=VAL CAN register write -i | --txid=ID CAN TX packet ID -T | --txrtr TX RTR packet -d | --txdat=DAT TX packet with data DAT -s | --server==<port> Daemonize and run as server -D | --dump Receive and print all CAN packets -0 | --btr0=BTR0 SJA1000 BTR0 bus timing reg val -1 | --btr1=BTR1 SJA1000 BTR1 bus timing reg val -t | --txtest Send TX test pattern -r | --rxtest Do RX test -p | --port=<host><:port> Talk to canctl server -S | --std Send standard frame (not extended) -v | --recover Automatically recover from bus-off
The canctl application implements network CAN functionality using the can_rx_remote() and can_tx_remote() functions. These functions which read and write one fixed-size packet of struct canmsg to a TCP socket descriptor. Writing your own canctl client in the language of your choice is as simple as doing the same thing. The format of the each CAN packet sent or received via the network interface is described below. The terms "Rx" and "Tx" are relative to the client, so "Rx" would describe packets read from CAN over the network and "Tx" would describe packets written to CAN over the network.
UINT32 flags: bit 7 - set on Tx if packet is a control packet control packets are intercepted by the canctl server to allow control functionality. bit 6 - set if message originates locally (unused) bit 5 - set if CAN message has extended ID bit 4 - set if remote transmission request (RTR) bit 3 - set on Rx if CAN error warning condition occurred bit 2 - set on Rx if CAN bus had a data overrun bit 1 - set on Rx if CAN bus went error passive bit 0 - set on Rx if a CAN bus error occurred Error conditions are reported for informational purposes. The server normally handles these errors and recovers from them. control information present (reserved for future use) message originates from this node (unused) UINT32 CAN id UINT32 timestamp_seconds UINT32 timestamp_microseconds UINT32 bytes of CAN data which are valid if bit 7 of flags is set, this byte is instead interpreted as a command number: 0 = set acceptance filter if the acceptance filter has been set, then only CAN packets which pass the filter will be received. to pass the filter, all bits in the acceptance filter which are to be checked (specified by a 1 in the corresponding bit of the mask) are compared (filter id compared to corresponding bit in received id). only if all bits to be checked do match will the packet be received. UINT8[8] CAN data if bit 7 of flags is set, this byte is instead interpreted as follows: cmd 0: UINT32 acceptance filter id UINT32 acceptance filter mask
UINT32 values are sent in little-endian format.
So for example, to send a standard CAN packet of length 6 with contents 01:02:03:04:05:06 and CAN id 55 it would be necessary to open a TCP connection to port 7552 on the device with the canctl server running, and the write the following packet to the socket:
00 00 00 00 55 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00 01 02 03 04 05 06 00 00