NetBurner Community Forum

rnixon wrote:Its not 8 times performance, and it only works if the processor can catch up, which may not happen if you have a sustained full load.

OMG, you haven’t brought a single figure but you are denying mines…
On a Netburner platform I have 61 uS to retrieve a CAN packet on a SJA1000 I have EIGHT times 61 uS for retrieving 8 packets, considering the overhead for retrieving 8 packets instead of one from the SJA1000 no significant I can say the SJA1000 has a receiving performance EIGHT times better.

rnixon wrote: Although there is some benefit to reading two or more messages at one time in an isr/task if they are buffered, you will still eventually run out of buffer on a sustained full load if the system can't keep up.

I appreciate your effort but if you do not have figures you are not helping me...

rnixon wrote: If this is still a concern you can either test it yourself on a CB34EX, or maybe build a system using a NetBurner module like the Mod5234 and add the buffer chip you like to it. Wouldn't that approach work?

Thanks again for your help, I'm trying to get the opinion of people that used the CB34EX on a real CAN environment. Have you ever done so?

patpat wrote: That does not help much, a locked buffer preserves the received packet but not the one that arrives before the buffer is unlocked....
We need the time involved on moving the received CAN packet to the uCOS FIFO..
Pat

Once the CAN RX buffer is locked the serial receive buffer can still receive another packet but it will wait to transfer it to the RX buffer until it is unlocked. This is basically a 2 buffer hardware fifo. If a third packet is sent while the RX buffer is locked and there is a packet in the serial buffer then the packet in transit is not acked and the sending CAN controller should resend it. This is what would happen on any CAN controller that does not overwrite a CAN packet until it is read.

If you have mutiple address ranges that you are reading from then you can put each range on its own receive channel, there are 16 of them in the CAN controller. This does not improve the worst case condition but will definitely improve the average case condition.

Just set the time to transfer the data to the OS fifo as the worst interrupt latency time, I know it will be much less. The majority of the time spent during interrupt latency or posting to a fifo is the time required to copy data. This is why there is such a big difference when saving the data to SRAM instead of SDRAM. In the interrupt switch all the CPU registers must be saved, 16 32-bit registers + 32-bit PC and 32-bit status = 72bytes of data. The time required to send the packet to the OS fifo is just the time it takes to do a memcpy of the buffer size. The largest can buffer is 16 bytes. Yes there is some additional overhead for incrementing a few variables and processing some instructions but this is small compared to the time to transfer the actual memory. Moving the CAN data and posting the fifo is much faster then the interrupt latency.

If you do not tie the processor up with an interrupt mask higher then the CAN interrupt level then I do not think you should have a problem. I have never heard of CAN data loss due to too much incoming data on NetBurner products.

I've used the Mod5234, which has the same processor as the CB34EX, and it works great.

lgitlitz wrote: Once the CAN RX buffer is locked the serial receive buffer can still receive another packet but it will wait to transfer it to the RX buffer until it is unlocked. This is basically a 2 buffer hardware fifo. If a third packet is sent while the RX buffer is locked and there is a packet in the serial buffer then the packet in transit is not acked and the sending CAN controller should resend it. This is what would happen on any CAN controller that does not overwrite a CAN packet until it is read.

understood

lgitlitz wrote: If you have mutiple address ranges that you are reading from then you can put each range on its own receive channel, there are 16 of them in the CAN controller. This does not improve the worst case condition but will definitely improve the average case condition.

I agree,

lgitlitz wrote: Just set the time to transfer the data to the OS fifo as the worst interrupt latency time, I know it will be much less. The majority of the time spent during interrupt latency or posting to a fifo is the time required to copy data. This is why there is such a big difference when saving the data to SRAM instead of SDRAM. In the interrupt switch all the CPU registers must be saved, 16 32-bit registers + 32-bit PC and 32-bit status = 72bytes of data. The time required to send the packet to the OS fifo is just the time it takes to do a memcpy of the buffer size. The largest can buffer is 16 bytes. Yes there is some additional overhead for incrementing a few variables and processing some instructions but this is small compared to the time to transfer the actual memory. Moving the CAN data and posting the fifo is much faster then the interrupt latency.

if accurate, this is really good info... then can I consider let say 10 uS since the RX interrupt is risen til the RX is unlocked for receiving the next packet?

lgitlitz wrote: If you do not tie the processor up with an interrupt mask higher then the CAN interrupt level then I do not think you should have a problem. I have never heard of CAN data loss due to too much incoming data on NetBurner products.

I hope your figures are correct, it would solve my problem thanks.
Pat

rnixon wrote:I've used the Mod5234, which has the same processor as the CB34EX, and it works great.

you know that works but you do not why... that's ok for some people....

OK, I set up a test and I confirm that the total latency is less then the 61uS to receive a no-data packet. I start a timer as soon as I enter the CAN interrupt routine in the canif driver. I am using the normal CAN to serial example. I read the timer after a successful pend on the OS fifo AND checking that the message is valid with can_msg.IsValid(). The packet I receive is a full CAN packet with 8 bytes of data. Since the timing I get includes task switches from idle to main and validating RX packets, this includes much more code then the actual timings. I am trying to be conservative and the actual times will be less. The only part that is not included in the time is the initial interrupt latency which we already know is always less then 5uS.

I sampled these results about 100 times and looked for the worst case, the numbers were always withing about 20% of each other.
With SRAM enabled worst case was always less then 20uS... I would say this will always be less then 21uS if you include the initial interrupt latency. I even tried putting our CAN software buffers in SRAM and this saved another 2uS. I had to reduce the software buffer size quite a bit to do this so I think you are better off with the larger software buffer pool in SDRAM.
Without SRAM the worst tested case is 42uS, about 47uS if you include the first interrupt switch.

Make sure to not set the interrupt SR mask to a level that can block CAN interrupts and you will be well within your threshold. Keep all your task stacks in SRAM and you should have much more CPU time for processing the data. By default most important stuff is in SRAM. You should add the idle task to SRAM if your application can fall into it. Any user tasks should also be put in SRAM:
http://www.netburner.com/downloads/nndk ... rmance.pdf

-Larry

Thank you Larry for doing beyond the call to provide this test and results. Most vendors I work with with would just suggest the customer test it and caution about not being responsible for user applications. I appreciate the extra support. We have over 200 CAN monitoring and logging systems in trucks based on the 5282 at one/fifth the cost of other solutions. Thanks for making the good stuff affordable.

Thanks again Larry; yours is the kind of answer I was looking for.

Pat