Libcanard question

[Pavel Vasev]

Dear Libcanard authors!

There is a file libcanard/tests/demo.c with a sample implementation of Libcanard library client.

It has a function for interaction with CAN subsystem:

```

/**

 * Transmits all frames from the TX queue, receives up to one frame.

 */

void processTxRxOnce(SocketCANInstance* socketcan, int timeout_msec)

````

What it does:

1. Sends outgoing CAN frames (as much as possible)

2. Receives 1 incoming CAN frame (if any)

The question. What are the reasons for such design?

E.g. why not

1. Receive as much as possible 2. Send as much as possible

or at least..

1. Receive one frame 2. Send as much as possible

The question is connected to the following thoughts. When we receive frames, we might generate a outgoing frames.

In current design, those outgoing frames will be send on next cycle iteration (counting that processTxRxOnce called inside some cycle).

E.g. the response will have some constant delay.

That's why I need some clarifications on current design. Thank you very much in advance!

With Best Regards,

Pavel Vasev

[Pavel Kirienko]

We need to emit frames before handling new RX frames in order to free up space in the TX queue. The freed up space will be needed if the newly received frame triggers a response from the application. This is also the reason why we don't process more than one RX frame per call. You can minimize or eliminate the TX latency by invoking the RX/TX function ad-hoc rather than at a fixed time interval.

At any rate, you don't have to use this design, it is just an example. Unlike Libuavcan, which imposes some particular way of doing things on the user, Libcanard is not opinionated and allows you to manage data whichever way you like (it also lets you shoot yourself in the foot as you please, too).

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/86db2406-da09-4d49-8194-1e38e0bc0a12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pavel Vasev]

Hi Pavel! Thank you for detailed information!

Is it true that this design considers that outgoing messages are formed outside 

of the function processTxRxOnce e.g. somewhere else and/or in previous iterations? 

That's why it needs to send before reading and thus try to free the buffer for new frames. Yes?

With Best Regards,

Pavel Vasev

С уважением,
Павел Васёв

[Pavel Kirienko]

Yes, it is assumed that the application may generate frames asynchronously, e.g. from a timer callback.

Pavel.

[Pavel Vasev]

Thank you for the information and ideas, Pavel!

пт, 27 апр. 2018, 20:49 Pavel Kirienko <pavel.k...@gmail.com>:

С уважением,
Павел Васёв

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.