Certain messages not sent out

Universal CAN Converter
Post Reply
yoman91
Posts: 4
Joined: Wed 15. Sep 2021, 09:53

Certain messages not sent out

Post by yoman91 » Wed 15. Sep 2021, 10:13

Hi folks,
I need some helping advice regarding a simple program.
The code I've written is based on the example '03_TIMER'. I have several messages what should sent out by the device with different timestamps (10ms, 20ms, 100ms, 1000ms and 2000ms). Each timer starts like in the example:

Code: Select all

        /***************************************************/
        /************         2000 ms        ***************/
        /***************************************************/
	if (SYSTIME_DIFF (timer2000, timenow) >= 2000000)
	{
            timer2000 += 2000000;
                    
            CANmsg_out.Id = 0x3E9U;
            CANmsg_out.Len = 8U;
            CANmsg_out.Type = CAN_MSG_STANDARD;
            
            CANmsg_out.Data8[0] = 0x01U;
            CANmsg_out.Data8[1] = 0x10U;
            CANmsg_out.Data8[2] = 0x00U;
            CANmsg_out.Data8[3] = 0x00U;
            CANmsg_out.Data8[4] = 0x00U;
            CANmsg_out.Data8[5] = 0x00U;
            CANmsg_out.Data8[6] = 0x00U;
            CANmsg_out.Data8[7] = 0x00U;
            CAN_UserWrite(CAN_BUS2, &CANmsg_out);     
            ...
            // imagine 5 more instances
In this '2 second' period, there are 6 messages, but somehow, the last 3 messages are not sent out.
I found a workaround and divided the 6 messages into 2 pieces of 3-message packet (timestamp of the 1st packet is 2s, and the other is 1.8s). Right now it is working, and all the messages sent out. So looks like it:

Code: Select all

        /***************************************************/
        /************         1800 ms        ***************/
        /***************************************************/
	if (SYSTIME_DIFF (timer1800, timenow) >= 1800000)
	{
	    timer1800 += 1800000;
            
            CANmsg_out.Id = 0x3E9U;
            CANmsg_out.Len = 8U;
            CANmsg_out.Type = CAN_MSG_STANDARD;
            
            CANmsg_out.Data8[0] = 0x01U;
            CANmsg_out.Data8[1] = 0x10U;
            CANmsg_out.Data8[2] = 0x00U;
            CANmsg_out.Data8[3] = 0x00U;
            CANmsg_out.Data8[4] = 0x00U;
            CANmsg_out.Data8[5] = 0x00U;
            CANmsg_out.Data8[6] = 0x00U;
            CANmsg_out.Data8[7] = 0x00U;
            CAN_UserWrite(CAN_BUS2, &CANmsg_out);     
            ...
            // imagine 2 more instances                          
        }
        
        /***************************************************/
        /************         2000 ms        ***************/
        /***************************************************/
	if (SYSTIME_DIFF (timer2000, timenow) >= 2000000)
	{
            timer2000 += 2000000;
            CANmsg_out.Id = 0x301U;
            CANmsg_out.Len = 8U;
            CANmsg_out.Type = CAN_MSG_STANDARD;
            
            CANmsg_out.Data8[0] = 0x01U;
            CANmsg_out.Data8[1] = 0x10U;
            CANmsg_out.Data8[2] = 0x10U;
            CANmsg_out.Data8[3] = 0x10U;
            CANmsg_out.Data8[4] = 0x02U;
            CANmsg_out.Data8[5] = 0x03U;
            CANmsg_out.Data8[6] = 0x00U;
            CANmsg_out.Data8[7] = 0x00U;
            CAN_UserWrite(CAN_BUS2, &CANmsg_out);     
            ...
            // imagine 2 more instances   
          }
          
However I accomplished my goal, this workaround is not nice. Does there any explanation, why the original code is not functioning as should?
Of course, the compiler is error and warning free. I tried the change the optimization level, but it does not influence the behavior.

PEAK PCAN-Router IPEH-002210 07638

M.Heidemann
Sales & Support
Sales & Support
Posts: 1083
Joined: Fri 20. Sep 2019, 13:31

Re: Certain messages not sent out

Post by M.Heidemann » Wed 15. Sep 2021, 15:06

Hello,

Maybe there are to many messages being pushed to the Txbuffer at once (Bear in mind some of your cycles are mutliples of each other), as a first test,
please check if extending the TX buffer in can_user.h helps in your case:

Try setting the TX_QUEUE_SIZE as 16 and test again.

Code: Select all


// defines
#define  CAN1_TX_QUEUE_SIZE	8
#define  CAN1_RX_QUEUE_SIZE	16

#define  CAN2_TX_QUEUE_SIZE	8
#define  CAN2_RX_QUEUE_SIZE	16

Please report back to us with your findings.

Best Regards

Marvin
---
Marvin Heidemann
PEAK-Support Team

yoman91
Posts: 4
Joined: Wed 15. Sep 2021, 09:53

Re: Certain messages not sent out

Post by yoman91 » Wed 15. Sep 2021, 17:07

Thank you for the quick reply. It solved the problem.
However one question has arisen in my head regarding your sentence: Bear in mind some of your cycles are mutliples of each other
Is there a cleaner way to handle this kind of structure?

M.Heidemann
Sales & Support
Sales & Support
Posts: 1083
Joined: Fri 20. Sep 2019, 13:31

Re: Certain messages not sent out

Post by M.Heidemann » Thu 16. Sep 2021, 08:41

Hello,

Consider this example:

Imagine your proposed cycles start at the same time

10ms -
20ms - every second cycle of (10ms) happens at the same time
100ms - every tenth cycle of (10ms) and every fith cycle of (20ms) at the same time
1000ms - Every hundreth cycle of (10ms), every fiftieth cycle of (20ms), every tenth cycle of (100ms) ...
2000ms - you get the idea.

If we assume every cycle has 5 messages being pushed to Txbuffer, our 2000 ms cycle will coincide
with 4 other cycles, in this case we do not push 5 messages to buffer but we try to push 20 messages
to Txbuffer. The same goes for the previous cycles ...As all the cycles are multiples of ten and they started at the same time, they will always coincide with all lower cycles.

Either you choose cycles which do not represent multiples of each other or you offset the start of each cycle, so that even if the cycles are mutliples of each other they are staggered and do not coincide.

Best Regards

Marvin
---
Marvin Heidemann
PEAK-Support Team

yoman91
Posts: 4
Joined: Wed 15. Sep 2021, 09:53

Re: Certain messages not sent out

Post by yoman91 » Tue 21. Sep 2021, 11:50

Thank you for the reply, looks like it is working now.

Can you tell me what is the biggest size of the TX and RX message buffer? (CAN1_TX_QUEUE_SIZE)

Your explanation is clear, but there is something, that I don't really understand.
Assume, that I have a cycle with 10 ms and the other e.g. 21 ms. In my view, it does not make so much difference. It is true, that the 21 ms is not the multiple of 10 ms, but in my eyes, it still can happen, that the message buffer is overloaded since not too much time elapses between the filling of the message buffer with messages of the 10 ms and with the messages of the 20 ms.
Or 1 ms difference is far enough for the periphery to empty the buffer?

Does there any function, that can investigate, whether the buffer is overloaded or not? (e.g. while(!MsgBufferIsFull) ... )

M.Heidemann
Sales & Support
Sales & Support
Posts: 1083
Joined: Fri 20. Sep 2019, 13:31

Re: Certain messages not sent out

Post by M.Heidemann » Tue 21. Sep 2021, 12:51

Hello,

The PCAN-Router has 16Kbyte RAM,
which is needed for all variables, libs, etc.

Your compiler will also give information regarding the total size used for the firmware, including all dependencies.

You'll need about 16 bytes for an TX message and 20 bytes for a RX message (it includes a timestamp).

So you can increase the buffer as long as your firmware including buffer and libs does not exceed the ram-size.

Yeah, there still could be some overlap, but since your buffer is bigger, this should not be an issue. Futhermore does the queue work in a FIFO matter so the order of frames stays the same.

If the buffer is full the write function will return an error:
PCR_Return.png
PCR_Return.png (11.71 KiB) Viewed 8112 times

Best Regards

Marvin
---
Marvin Heidemann
PEAK-Support Team

yoman91
Posts: 4
Joined: Wed 15. Sep 2021, 09:53

Re: Certain messages not sent out

Post by yoman91 » Tue 21. Sep 2021, 13:12

Thank you for the feedback.

I will create my further projects taking into consideration all these information.

Regards,
Tamas

Post Reply