headers
Roland Tollenaar | 1 Mar 2007 12:22
Picon

Re: CAN rt_dev_recvfrom

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.
> 
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Wolfgang Grandegger | 1 Mar 2007 12:32

Re: CAN rt_dev_recvfrom

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roland Tollenaar | 1 Mar 2007 13:10
Picon

Re: CAN rt_dev_recvfrom

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.
>
Permalink | Reply | 1 comment |
headers
Wolfgang Grandegger | 1 Mar 2007 13:25

Re: CAN rt_dev_recvfrom

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.
Permalink | Reply | 0 comments |
headers
roland Tollenaar | 1 Mar 2007 20:51
Picon

Re: warnings and tangled threads.

Hi,

My hardware has arrived. Well some of it, the rest should be coming
tomorrow. So will be testing the CAN functionality for real if I
finally get some time to work on this project other than at night. :(

In the mean time I still wanted to squeeze in applying the patch
below. However it fails, says something like

Hunk1 failed at line 295
Hunk2 succeeded.......

1 out of 2 failed.

This is what I did:
Put your patch in a file rtdmpatch in the root of the install (not the
source) directory. Then ran
patch -p0 < rtdmpatch.

What am I doing wrong? Running it in the root of the source directory
won't make a difference will it?

Regards,

Roland.

> > This works for me here (and is a bit more telling as well):
> >
> > --- include/rtdm/rtdm.h (Revision 2265)
> > +++ include/rtdm/rtdm.h (Arbeitskopie)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dmitry Adamushko | 1 Mar 2007 21:27
Picon

Re: warnings and tangled threads.

On 01/03/07, roland Tollenaar <rolandtollenaar <at> gmail.com> wrote:
> Hi,
>
> My hardware has arrived. Well some of it, the rest should be coming
> tomorrow. So will be testing the CAN functionality for real if I
> finally get some time to work on this project other than at night. :(
>
> In the mean time I still wanted to squeeze in applying the patch
> below. However it fails, says something like
>
> Hunk1 failed at line 295
> Hunk2 succeeded.......
>
> 1 out of 2 failed.

This likely indicates that your "target" file (the one to be patched)
and the one Jan used to generate this patch are of different versions
(different revisions). There must have been created a file with .rej
extension - in your case include/rtdm/rtdm.h.rej which contains a part
of the patch that has failed to apply.

Anyway, you can fix it manually. It doesn't require any knowledge of
quantum mechanics, really.

e.g.

> > > --- include/rtdm/rtdm.h (Revision 2265)
> > > +++ include/rtdm/rtdm.h (Arbeitskopie)

the file to be patched is include/rtdm/rtdm.h
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Kiszka | 1 Mar 2007 21:27
Picon

Re: warnings and tangled threads.

roland Tollenaar wrote:
> Hi,
> 
> My hardware has arrived. Well some of it, the rest should be coming
> tomorrow. So will be testing the CAN functionality for real if I
> finally get some time to work on this project other than at night. :(
> 
> In the mean time I still wanted to squeeze in applying the patch
> below. However it fails, says something like
> 
> Hunk1 failed at line 295
> Hunk2 succeeded.......
> 
> 1 out of 2 failed.
> 
> This is what I did:
> Put your patch in a file rtdmpatch in the root of the install (not the
> source) directory. Then ran
> patch -p0 < rtdmpatch.
> 
> What am I doing wrong? Running it in the root of the source directory
> won't make a difference will it?
> 

Some mail clients tend to mess with inlined patches. I attached it as
file, applicable against v2.3.x (trunk already contain the fix).

Jan

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


roland Tollenaar
 | 
2 Mar 2007 09:23






Picon





problems installing peak CAN dongle


Hi,

My dongle has arrived and seems to be OK under windows.

I am now trying to install it under linux but things not looking good so far.

from

/lib/modules/2.6.16-xen-3/kernel/drivers/xenomai/can/sja1000

I ran

$>depmod xeno_can_peak_dng.ko
$>modprobe xeno_can_peak_dng type=epp io=0x378 irq=7

but the result is:

FATAL: Error inserting xeno_can_peak_dng (xeno_can_peak_dng.ko): No such device

The little led is glowing. And the dongle is even plugged in to the
only parallel port my machine has :)
Nothing is connected to the output of the dongle at this stage.

Am I missing something fundamental here?

Thanks for your time.

Regards,

Roland

(Continue reading)






Permalink
| Reply
| 25 comments  
| 



  

  

  





headers


Jan Kiszka
 | 
2 Mar 2007 09:40






Picon





Re: problems installing peak CAN dongle


roland Tollenaar wrote:
> Hi,
> 
> My dongle has arrived and seems to be OK under windows.
> 
> I am now trying to install it under linux but things not looking good so
> far.
> 
> from
> 
> /lib/modules/2.6.16-xen-3/kernel/drivers/xenomai/can/sja1000
> 
> I ran
> 
> $>depmod xeno_can_peak_dng.ko
> $>modprobe xeno_can_peak_dng type=epp io=0x378 irq=7
> 
> but the result is:
> 
> FATAL: Error inserting xeno_can_peak_dng (xeno_can_peak_dng.ko): No such
> device
> 
> The little led is glowing. And the dongle is even plugged in to the
> only parallel port my machine has :)
> Nothing is connected to the output of the dongle at this stage.
> 
> Am I missing something fundamental here?
> 

Maybe a conflict with parport_pc.

(Continue reading)






Permalink
| Reply
| 3 comments  
| 



  

  

  





headers


Wolfgang Grandegger
 | 
2 Mar 2007 09:47





Re: problems installing peak CAN dongle


roland Tollenaar wrote:
> Hi,
> 
> My dongle has arrived and seems to be OK under windows.
> 
> I am now trying to install it under linux but things not looking good so 
> far.
> 
> from
> 
> /lib/modules/2.6.16-xen-3/kernel/drivers/xenomai/can/sja1000
> 
> I ran
> 
> $>depmod xeno_can_peak_dng.ko
> $>modprobe xeno_can_peak_dng type=epp io=0x378 irq=7

Are these the options you used for Windoze as well?

> but the result is:
> 
> FATAL: Error inserting xeno_can_peak_dng (xeno_can_peak_dng.ko): No such 
> device

Is there som additional kernel output visible via "dmesg"?

> The little led is glowing. And the dongle is even plugged in to the
> only parallel port my machine has :)
> Nothing is connected to the output of the dongle at this stage.
> 

(Continue reading)






Permalink
| Reply
| 20 comments  
| 



  

  

  

  


  





    



Gmane