Hi Michael,
On 19.05.22 18:56, Michael Anochin wrote:
How does this application implement this 10ms interval?
I use epiktimer https://wiki.lazarus.freepascal.org/EpikTimer
(https://github.com/graemeg/epiktimer) for freepascal compiler. It calls
fpsend (like "send" in c) very periodically to put the can_fd msg to the
buffer. No doubt on this. I think, the lag is in a m_can implementation.
Ok.
The interrupts are switched off briefly in m_can_isr
(m_can_disable_all_interrupts), may be one of IRQs goes lost or
something like this.
Hm. Do you plan to test the Linux 5.17 kernel to make use of the latest
SPI improvements then?
Can you check cangen -g 10 -f -I 123 -L 64 can0
Yes, I will do it tomorrow and report.
Good.
candump -td can0
I see even greater jitter with candump -td. That's why I took the
separate CAN adapter for sniffing.
Ok.
What is the use-case for this 10ms cyclic transmission?
The use-case is in the communication with car light (automotive sector).
Aah - I have a rough idea ;-)
Maybe the CAN_BCM could bring an improvement
Unfortunately, the format of a broadcast message cannot be taken. There
is a package counter in each message, wich sould be incremented each time.
In fact the CAN_BCM is also capable to send a sequence(!) of CAN(FD) frames.
The nframes element in the struct bcm_msg_head can be e.g. 16 (4 bit
counter) or even 256 (8 bit counter) so that you can create (or modify)
a bigger array of CAN(FD) frames including the counter value or some
checksums.
And then this array can be (asynchronously) pushed to the BCM socket for
content updates while the cycle time for the proper and precise
transmission is maintained in the kernel.
You should give it a try ;-)
Best regards,
Oliver
Am 19.05.2022 um 18:26 Oliver Hartkopp:
Hi Michael,
On 19.05.22 17:52, Michael Anochin wrote:
my application continuously sends 64 bytes CANFD packets with 1MBit/s
at the 10ms interval.
How does this application implement this 10ms interval?
Can you check whether
cangen -g 10 -f -I 123 -L 64 can0
has the same problems?
With
candump -td can0
you should be able to see some timestamp gaps around 10ms.
I use tcan4450 on the RPI4 with 5.10.103 Kernel and raspbian. No
other significant processes load the CPU.
When I monitor the traffic with a PCAN adapter on a Windows PC, I
notice that the packets sometimes arrive with a delay of 5-9ms. But
the next following packet arrive faster as 10ms. My desired interval
of 10ms is kept at the jitter of +/- 9ms.
Running the App on only one CPU core using tasksel improve the jitter
somewhat.
What is the use-case for this 10ms cyclic transmission? Maybe the
CAN_BCM (which uses in-kernel highres timers) could bring an
improvement for you.
Am I the only one who observes such large jitter or is the m_can
implementation at Perepherie (spi) not so fast from the throughput
and is completely normal.
Maybe I should switch to 5.17 kernel? On 5.17 there are bulk
read/write function for spi regmap.
I don't answer to this as I don't have the required SPI knowledge ...
but if you could upgrade to a newer kernel this is always a good
approach ;-)
Best regards,
Oliver
