We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi everybody
I use SAM7x512 and RL-ARM OS. here, OS has 7 tasks and one of them is for CAN receiver. OS_TICK is 1000 and OS_STKSIZE is 1024. and 500000 is my CAN baudrate(my board is just receiver and transmitter is a KVASER PCI CAN Interface).
speed of data transmission is my problem.
when for example transmitter side of CAN bus send a packet per 10ms or more there is know any problem but when I try to increase the speed after some packet (about 200 messages or more) I will get OS_ERR_FIFO_OVF in os_error function. but when I disable the CAN task all other task are working as well.
note: When the system is getting crash and doesn't do any tasks but it's not in os_error function in debug mode with ulink2 sometimes task of CAN in "RTX task and system" -> "stack load" shows "under flow" and after that it calls os_error (in usual states it's about 3% of stack usage)
I tried such works:
1. increase OS_STKSIZE 2. increase OS_FIFOSZ 3. increase CAN_No_ReceiveObjects 4. chaning the OS_TICK
but nothing happened
Does anyone know what I should do?
Hi about that part of my code in previous post (with isr_evt_set) when I was debugging I found that the program never pass "os_evt_wait_or (0x0001, 0xffff)" (the program has called isr_evt_set but nothing happened after that)
what's wrong with it?
Hi
after a long while I could found what the problem was.
* Try to speed up general interrupt handling.
as you can see in my sample code (2 messages before) the developer of that code has used mailbox to send a new packet to can_receive fuction and can_receive function use mailbox wait to get a new message through OS mailbox
here I try to omit it and instead, referesh a global variable and flag to be aware in main routine that new message has been received
everything is OK without any OVF on FIFO; dAbt and pAbt
I think because the number of intterupts in Ethernet and CAN are too high the only way to cope such a problem is just speed up my ISR routine as Tamir Michael said.
thanks again
well done
I'm not sure I agree with your analysis. Yes, interrupts should always be as fast as possible. And they should clear out the data and leave the hardware in a stable state. You just may not get your queues full and leave data still in the hardware.
Another issue the ISR makes use of os_mbx_check() instead of isr_mbx_check().