[Xenomai-help] CAN rt_dev_recvfrom

[Xenomai-help] CAN rt_dev_recvfrom

[roland Tollenaar]

Hi,

Ok the issue I posted earlier regarding the read function. It seems
that it IS recieving can messages and displaying them correctly. Only
its behaviour is not as I expected. I thought the function

rt_dev_recvfrom

would simply perform a read one frame from a buffer (which in my
experience holds a number of can messages) then exit.

By the look of things I will have to implement the aforementioned
buffer myself. I.e

run rt_dev_recvfrom in a separate thread other than my periodic task
and store an x number of messages in BUFFER that I recieve there. The
can_read() function which I implement in the periodic task must then
simply read the messages from BUFFER.

Can this be confirmed or is rt_dev_recvfrom() behaving incorrectly in my case?

Kind regards,

Roland.

Re: [Xenomai-help] CAN rt_dev_recvfrom

[Wolfgang Grandegger]

roland Tollenaar wrote:
> Hi,
> 
> Ok the issue I posted earlier regarding the read function. It seems
> that it IS recieving can messages and displaying them correctly. Only
> its behaviour is not as I expected. I thought the function
> 
> rt_dev_recvfrom
> 
> would simply perform a read one frame from a buffer (which in my
> experience holds a number of can messages) then exit.
> 
> By the look of things I will have to implement the aforementioned
> buffer myself. I.e
> 
> run rt_dev_recvfrom in a separate thread other than my periodic task
> and store an x number of messages in BUFFER that I recieve there. The
> can_read() function which I implement in the periodic task must then
> simply read the messages from BUFFER.
> 
> Can this be confirmed or is rt_dev_recvfrom() behaving incorrectly in my 
> case?

rt_dev_recvfrom() reads message frames (one at a time) from an internal 
socket buffer (there is actually a kernel configuration option to 
configure the size). If no messages are available, it will block by 
default, but it can also be used in non-blocking mode by using the flag 
MSG_DONTWAIT. It seems, that your application is trying to read messages 
periodically in polling mode. Either you do reading and buffering in 
your own thread as you suggested above or you use rt_dev_recvfrom() in 
non-blocking mode.

Wolfgang.

Re: [Xenomai-help] CAN rt_dev_recvfrom

[Roland Tollenaar]

Hi Wolfgang,

>> Can this be confirmed or is rt_dev_recvfrom() behaving incorrectly in 
>> my case?
> 
> rt_dev_recvfrom() reads message frames (one at a time) from an internal 
> socket buffer (there is actually a kernel configuration option to 
> configure the size). If no messages are available, it will block by 
> default, but it can also be used in non-blocking mode by using the flag 
> MSG_DONTWAIT. It seems, that your application is trying to read messages 
> periodically in polling mode. Either you do reading and buffering in 
> your own thread as you suggested above or you use rt_dev_recvfrom() in 
> non-blocking mode.

Thanks for this. I have not tried it yet but I was looking for that flag 
in the hope that something like this would exist. I thought I had seen 
something like it but when I tried to locate it yesterday I failed. 
Don;t worry it is there, I just checked. Sorry.

Where can I find the buffer size option in the kernel config menu? What 
is the default size?

Thanks again.

Roland

> 
> Wolfgang.
> 
> 

Re: [Xenomai-help] CAN rt_dev_recvfrom

[Wolfgang Grandegger]

Roland Tollenaar wrote:
> Hi Wolfgang,
> 
>>> Can this be confirmed or is rt_dev_recvfrom() behaving incorrectly in 
>>> my case?
>>
>> rt_dev_recvfrom() reads message frames (one at a time) from an 
>> internal socket buffer (there is actually a kernel configuration 
>> option to configure the size). If no messages are available, it will 
>> block by default, but it can also be used in non-blocking mode by 
>> using the flag MSG_DONTWAIT. It seems, that your application is trying 
>> to read messages periodically in polling mode. Either you do reading 
>> and buffering in your own thread as you suggested above or you use 
>> rt_dev_recvfrom() in non-blocking mode.
> 
> Thanks for this. I have not tried it yet but I was looking for that flag 
> in the hope that something like this would exist. I thought I had seen 
> something like it but when I tried to locate it yesterday I failed. 
> Don;t worry it is there, I just checked. Sorry.
> 
> Where can I find the buffer size option in the kernel config menu? What 
> is the default size?

On the first menu of the RT-Socket-CAN configuration options:

config XENO_DRIVERS_CAN_RXBUF_SIZE
         depends on XENO_DRIVERS_CAN
         int "Size of receive ring buffers (must be 2^N)"
         default 1024

Note that the messages are stored in "packed" format.

Wolfgang.

Re: [Xenomai-help] CAN rt_dev_recvfrom

[Roland Tollenaar]

Hi,

>> Where can I find the buffer size option in the kernel config menu? 
>> What is the default size?
> 
> On the first menu of the RT-Socket-CAN configuration options:
> 
> config XENO_DRIVERS_CAN_RXBUF_SIZE
>         depends on XENO_DRIVERS_CAN
>         int "Size of receive ring buffers (must be 2^N)"
>         default 1024
> 
> Note that the messages are stored in "packed" format.

Does this mean that the buffer will store 1024 can_frame's ?

If yes (or even if no) when rt_dev_recv is called, does it place the 
last recieved message (youngest message) or the oldest (behave like a 
FIFO) into *Buf?

Roland

> 
> Wolfgang.
> 

Re: [Xenomai-help] CAN rt_dev_recvfrom

[Wolfgang Grandegger]

Roland Tollenaar wrote:
> Hi,
> 
>>> Where can I find the buffer size option in the kernel config menu? 
>>> What is the default size?
>>
>> On the first menu of the RT-Socket-CAN configuration options:
>>
>> config XENO_DRIVERS_CAN_RXBUF_SIZE
>>         depends on XENO_DRIVERS_CAN
>>         int "Size of receive ring buffers (must be 2^N)"
>>         default 1024
>>
>> Note that the messages are stored in "packed" format.
> 
> Does this mean that the buffer will store 1024 can_frame's ?

The size is usually in bytes. And as the messages are packed, the FIFO 
can hold from 1024/5 to 1024/13 messages (without time-stamp).

> If yes (or even if no) when rt_dev_recv is called, does it place the 
> last recieved message (youngest message) or the oldest (behave like a 
> FIFO) into *Buf?

It is a FIFO.

Wolfgang.