Hello,
Does PCAN provide hardware time based control of CAN frame to transmit short periodic message?
In my application, I have to send a periodic CAN frame with 1ms. Is it possible when I use PCAN-Developer 4?
Thank you,
MHKong
short periodic message transmission
Re: short periodic message transmission
Hello,
with the API of PCAN-Developer 4 package, you have the possibility to send frames with a future time stamp into the driver queue. The driver will send those frames and will take care for the needed timing than. However, there is no sorting algorithm in the TX driver queue for timestamps, you have to write your TX messages with incremented timestamps into the TX queue. We use this feature in PCAN-View, to keep the timing even when the application will be moved or blocked. A hardware buffer for cyclic messages is not available.
Here are the steps you have to do to use that feature:
- Get the actual timestamp with CAN_GetSystemTime()
- Calculate the needed CAN data and write the message with CAN_Write with an incremented timestamp based on the actual timestamp to the driver. By default the driver can handle up to 32768 tx messages.
- Use a timer to fill the next batch of messages in time. You can check the fill size of the TXqueue of the client with CAN_GetParam() (see 8.3.8 CAN_PARAM_XMTQUEUEFILL of the Clients).
- The driver will send out the messages when the timestamp used in CAN_Write() is reached.
- You can see the driver buffer of the client in PCAN-Status display selecting the Queue option.
- Please take care that the driver don’t use a sorting algorithm for those tx messages. So you have to write those messages with timestamps in chronological order.
- If you need to clear the TX messages in the buffer, you could use CAN_ResetClient() to empty the TX queue again.
- It is always possible to send another CAN message while the TX buffer has messages with future timestamps in the TX queue. In that case you have to take care to use a timestamp for CAN_Write() which is in the past.
- The drivers checks the timestamp in the moment when you call CAN_Write, and put it in the client queue when there is a future timestamp used, or send it directly to the hardware queue when an older timestamp is used.
Another solution to have a good timing for your TX messages is the use of the Windows multimedia timer option. With this Windows timer, your application is able to handle a timing of 1ms.
regards
Michael
with the API of PCAN-Developer 4 package, you have the possibility to send frames with a future time stamp into the driver queue. The driver will send those frames and will take care for the needed timing than. However, there is no sorting algorithm in the TX driver queue for timestamps, you have to write your TX messages with incremented timestamps into the TX queue. We use this feature in PCAN-View, to keep the timing even when the application will be moved or blocked. A hardware buffer for cyclic messages is not available.
Here are the steps you have to do to use that feature:
- Get the actual timestamp with CAN_GetSystemTime()
- Calculate the needed CAN data and write the message with CAN_Write with an incremented timestamp based on the actual timestamp to the driver. By default the driver can handle up to 32768 tx messages.
- Use a timer to fill the next batch of messages in time. You can check the fill size of the TXqueue of the client with CAN_GetParam() (see 8.3.8 CAN_PARAM_XMTQUEUEFILL of the Clients).
- The driver will send out the messages when the timestamp used in CAN_Write() is reached.
- You can see the driver buffer of the client in PCAN-Status display selecting the Queue option.
- Please take care that the driver don’t use a sorting algorithm for those tx messages. So you have to write those messages with timestamps in chronological order.
- If you need to clear the TX messages in the buffer, you could use CAN_ResetClient() to empty the TX queue again.
- It is always possible to send another CAN message while the TX buffer has messages with future timestamps in the TX queue. In that case you have to take care to use a timestamp for CAN_Write() which is in the past.
- The drivers checks the timestamp in the moment when you call CAN_Write, and put it in the client queue when there is a future timestamp used, or send it directly to the hardware queue when an older timestamp is used.
Another solution to have a good timing for your TX messages is the use of the Windows multimedia timer option. With this Windows timer, your application is able to handle a timing of 1ms.
regards
Michael