 |
|
When the CAN controller is on bus, it is receiving messages and is sending acknowledge bits in response to all correctly received messages. A controller that is off bus is not taking part in the bus communication at all.
Use canBusOn() to go on bus and canBusOff() to go off bus.
If you have multiple handles to the same controller, the controller will go off bus when the last of the handles go off bus (i.e. all handles must be off bus for the controller to be off bus). You can use canReadStatus() and watch the flag canSTAT_BUS_OFF to see if the controller has gone off bus.
If you would like to reset a CAN bus controller by taking the channel off bus and then on bus again, you can use canResetBus().
You can set a channel to silent mode by using the canDRIVER_SILENT mode if you want it to be on-bus without interfering with the traffic in any way, see CAN Driver Modes
Example. This example takes an open channel off-bus and then takes it on-bus again, for what purpose it may serve.
Incoming messages are placed in a queue in the driver. In most cases the hardware does message buffering as well. You can read the first message in the queue by calling canRead(); it will return canERR_NOMSG if there was no message available.
The flag parameter of canRead() contains a combination of the message flags canMSG_xxx, including canFDMSG_xxx if the CAN FD protocol is enabled, and error flags canMSGERR_xxx which provides you with more information about the message; for example, a frame with a 29-bit identifier will have the canMSG_EXT bit set, and a remote frame will have the canMSG_RTR bit set. Note that the flag argument is a combination of the canMSG_xxx flags, so more than one bit might be set.
See CAN Frame Types Different for more detailed information.
The size of the queues in the driver and hardware is described in Message Queue and Buffer Sizes.
Sometimes it is desirable to have a peek into the more remote parts of the queue. Is there, for example, any message waiting that has a certain identifier?
You can specify a timeout (in milliseconds) for those routines that wait for messages.
Example. Input Queue Handling
As an illustration of the abovementioned routines, consider the case where CAN messages with the following identifiers have arrived to the input queue:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Example. The following code fragment reads the next available CAN message, if any.
You can set filters to reduce the number of received messages. CANlib supports setting of the hardware filters on the CAN interface board. This is done either with the canAccept() function or with the canSetAcceptanceFilter() function.
Note that both functions distinguish between 11-bit (std) and 29-bit (ext) identifiers since these are handled by two separate filters. Both of these filters default to OFF (mask == 0).
You set an acceptance code and an acceptance mask which together determine which CAN identifiers are accepted or rejected.
If you want to remove a filter, call canAccept() with the mask set to 0.
Example. To set the mask to 0xF0 and the code to 0x60:
or, alternatively,
This code snippet will cause all messages having a standard (11-bit) identifier with bit7-bit4 in the identifier equal to 0110 (binary) will pass through. Other messages with standard identifiers will be rejected.
Example. How acceptance filters can be used in a smaller project.
Explanation of the code and mask format used by the canAccept(), canSetAcceptanceFilter(), and canObjBufSetFilter() functions:
In other words, the message is accepted if ((code XOR id) AND mask) == 0.
canSetAcceptanceFilter() and canAccept() both serve the same purpose but the former can set the code and mask in just one call.
You transmit messages by calling canWrite(). Outgoing CAN messages are buffered in a transmit queue and sent on a First-In First-Out basis. You can use canWriteSync() to wait until the messages in the queue have been sent.
Example. Sending a CAN message.
Using Extended CAN (CAN 2.0B)
"Standard" CAN has 11-bit identifiers in the range 0 - 2047. "Extended" CAN, also called CAN 2.0B, has 29-bit identifiers. You specify which kind of identifiers you want to use in your call to canWrite(): if you set the canMSG_EXT flag in the flag argument, the message will be transmitted with a 29-bit identifier. Conversely, received 29-bit-identifier messages have the canMSG_EXT flag set.
Example. The following code fragment sends a CAN message on an already open channel. The CAN message will have identifier 1234 (extended) and DLC = 8. The contents of the data bytes will be whatever the data array happens to contain.
There are more (but not all) of the message flags canMSG_xxx, including canFDMSG_xxx if the CAN FD protocol is enabled, that are meaningful to set when sending messages.
Some of the Kvaser interfaces are equiped with hardware buffers for automatic sending and responding to messages. They can be used when the timing conditions are strict, and might not be possible to fulfill on the application level.
There are two types of buffers, auto response and auto transmit.
Using the object buffers
To use the object buffers, start by allocating buffer with a call to canObjBufAllocate() and set the content of the buffer with canObjBufWrite().
For auto response you define which messages to respond to by calling canObjBufSetFilter(). The filter uses a code and mask, which means it can be set to respond to a range of CAN ids.
For automatic transmission the delay between each message sent is set by calling canObjBufSetPeriod(). To limit the number of messages sent by the buffer make a call to canObjBufSetMsgCount().
To enable the buffer make a call to canObjBufEnable(). The buffer can be disabled by canObjBufDisable().
You can deallocate a buffer that you don't want to use any longer by a call to canObjBufFree(), or to deallocate all buffers in one call use canObjBufFreeAll().
Example Auto Response.
This example responds with "1 2 3 4 5 6" with id "200" when a message with the id "100" is recieved.
Example Auto Transmit.
This example transmit "1 2 3 4 5 6" with id "300" every second.