Hello Oleksij,
thanks for report and suggestion.
I cannot promiss anything due to lack of financing
and people for this project. I am aware that QEMU CAN
bus support initial KISS design. I am happy that it
has some use in this form. I have invested my personal
time to mentor RTEMS CAN QEMU GSoC slot and then to
rewrite code to the mainline acceptable state.
There are much more to think about:
- back pressure mechanism from CanBusClientState
in real CAN network it is realized by real speed
limits and overload frames. But overload frames are
internal mechanism which is not exposed by SocketCAN
interfaces.
- more CAN interfaces, it would be great to have Zynq
and i.MX6 support to emulate real automotive related
targets
- CAN FD support, without really well paid contract for university
or my company or other consortium, I would not invest my personal time
to any closed source CAN FD core or work. My life and time is too precious
for me to work on and support project which could be closed/blocked/destroyed
by random manager or professor (as happend already too much times to me).
So my plan and hope is to find time, energy or even financing to continue
work on opensource CAN FD core which design has started at our university
and Mr. Ille and I invest our personal time into
see http://canbus.pages.fel.cvut.cz/
Actual progress from January is complete CAN protocol control
redesign and cleanup up to the state that core passes basic real hardware
tests (Zynq and PC+PCIe Altera/Intel) again. So it is time to start again
with review process for open-firmare entry inclusion and then
discussion about driver changes to make it ready for mainline.
CAN FD for QEMU comes to the mind only after progress on this side.
Best wishes,
Pavel Pisa
phone: +420 603531357
e-mail: pisa@xxxxxxxxxxxxxxxx
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://dce.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa (alternatively http://pikron.com/ )
On Thursday 29 of August 2019 14:48:37 Oleksij Rempel wrote:
> Hi all,
>
> Just in case some one has similar problem. Current QEMU with CAN support
> is not totally realistic when it comes to sending frames. When the QEMU
> is attached to a vcan, then it sends out the CAN frames as fast as it
> could. Another QEMU attached to the same vcan tends to drop frames
> during reception.
>
> One of the ways to fix it is to send packets from QEMU with proper
> packet rate. For example the hw/net/can/can_sja1000.c could delay the TX
> complete interrupt based on the configured CAN bit timing and CAN frame
> length.
>
> In case some one has time to do it:
>
> This function can be used to calculate the frame length:
>
> https://github.com/linux-can/can-utils/blob/master/canframelen.c#L239
>
> I think CFL_WORSTCASE is good enough :)
>
> and this example shows how to properly delay and interrupt call in QEMU:
>
> https://github.com/qemu/qemu/blob/master/hw/net/e1000.c#L270
>
> regards,
> Oleksij & Marc
