* [Xenomai-help] RTDM rs232 strange behavior
@ 2010-06-05 2:22 Everett Wang
2010-06-07 8:05 ` Wolfgang Grandegger
2010-06-09 6:19 ` Wolfgang Grandegger
0 siblings, 2 replies; 7+ messages in thread
From: Everett Wang @ 2010-06-05 2:22 UTC (permalink / raw)
To: xenomai
Hi All,
I am playing around with xenomai and RTDM serial driver on a
1.7Ghz Pentium-M machine running xenomai 2.5.3. The example cross-link
produced this result:
main : starting read-task
Nr | write->irq | irq->read | write->read |
-----------------------------------------------------------
0 | 118948 | 614135 | 733083
1 | 115598 | 614281 | 729879
2 | 108917 | 614982 | 723899
3 | 106101 | 616560 | 722661
4 | 113457 | 614971 | 728428
5 | 110358 | 614265 | 724623
6 | 106499 | 614406 | 720905
7 | 110363 | 615015 | 725378
8 | 115478 | 614840 | 730318
9 | 110766 | 614168 | 724934
10 | 108986 | 616435 | 725421
11 | 108030 | 614299 | 722329
12 | 109369 | 614420 | 723789
13 | 105862 | 614456 | 720318
14 | 110428 | 616301 | 726729
Is 0.7 millisecond between write and read a reasonable number?
I then changed the example a little: I let write task only
write 4 characters and instruct read task to read 10 characters.
I thought the read task will tell me when that only 4 characters
is read. But to my surprise, it waited until write-task
filled all 10 characters before finish reading. How can I
change the code to just do the read to whatever charaters
are avaliable without waiting to fill all the characters I
asked for? I will use this capability to read a GPS. It's
output length is unknow before reading.
Most GPS can also produce a precisive time pulse when data
is ready. Is it be possible to connect this to a pin in rs232 (CTS, for example)
to triger a IRQ so the data can be read in a timely manner?
Many thanks in advance.
Everett
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] RTDM rs232 strange behavior
2010-06-05 2:22 [Xenomai-help] RTDM rs232 strange behavior Everett Wang
@ 2010-06-07 8:05 ` Wolfgang Grandegger
2010-06-07 12:07 ` Everett Wang
2010-06-09 6:19 ` Wolfgang Grandegger
1 sibling, 1 reply; 7+ messages in thread
From: Wolfgang Grandegger @ 2010-06-07 8:05 UTC (permalink / raw)
To: Everett Wang; +Cc: xenomai
On 06/05/2010 04:22 AM, Everett Wang wrote:
> Hi All,
>
> I am playing around with xenomai and RTDM serial driver on a
> 1.7Ghz Pentium-M machine running xenomai 2.5.3. The example cross-link
> produced this result:
>
> main : starting read-task
> Nr | write->irq | irq->read | write->read |
> -----------------------------------------------------------
> 0 | 118948 | 614135 | 733083
> 1 | 115598 | 614281 | 729879
> 2 | 108917 | 614982 | 723899
> 3 | 106101 | 616560 | 722661
> 4 | 113457 | 614971 | 728428
> 5 | 110358 | 614265 | 724623
> 6 | 106499 | 614406 | 720905
> 7 | 110363 | 615015 | 725378
> 8 | 115478 | 614840 | 730318
> 9 | 110766 | 614168 | 724934
> 10 | 108986 | 616435 | 725421
> 11 | 108030 | 614299 | 722329
> 12 | 109369 | 614420 | 723789
> 13 | 105862 | 614456 | 720318
> 14 | 110428 | 616301 | 726729
>
> Is 0.7 millisecond between write and read a reasonable number?
No, at least not for a baudrate of 115200. Does the "latency" test
report reasonable latency figures? And how did you load xeno_16550A.ko?
> I then changed the example a little: I let write task only
> write 4 characters and instruct read task to read 10 characters.
> I thought the read task will tell me when that only 4 characters
> is read. But to my surprise, it waited until write-task
> filled all 10 characters before finish reading. How can I
> change the code to just do the read to whatever charaters
> are avaliable without waiting to fill all the characters I
> asked for? I will use this capability to read a GPS. It's
> output length is unknow before reading.
Setting the config rx timeout to RTSER_TIMEOUT_NONE should help.
> Most GPS can also produce a precisive time pulse when data
> is ready. Is it be possible to connect this to a pin in rs232 (CTS, for example)
> to triger a IRQ so the data can be read in a timely manner?
That depends on the signals, I can imagine. I'm not a hardware guy but I
know that many GPS receiver come with a read-to-use RS232 interface.
Wolfgang.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] RTDM rs232 strange behavior
2010-06-07 8:05 ` Wolfgang Grandegger
@ 2010-06-07 12:07 ` Everett Wang
2010-06-07 13:17 ` Wolfgang Grandegger
0 siblings, 1 reply; 7+ messages in thread
From: Everett Wang @ 2010-06-07 12:07 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai
I am so glad that Wolfgang is able to help giving suggestions. Thanks
a lot. That is very useful for new users. :-)
On Mon, Jun 7, 2010 at 4:05 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
> On 06/05/2010 04:22 AM, Everett Wang wrote:
>> Hi All,
>>
>> I am playing around with xenomai and RTDM serial driver on a
>> 1.7Ghz Pentium-M machine running xenomai 2.5.3. The example cross-link
>> produced this result:
>>
>> main : starting read-task
>> Nr | write->irq | irq->read | write->read |
>> -----------------------------------------------------------
>> 0 | 118948 | 614135 | 733083
>> 1 | 115598 | 614281 | 729879
>> 2 | 108917 | 614982 | 723899
>> 3 | 106101 | 616560 | 722661
>> 4 | 113457 | 614971 | 728428
>> 5 | 110358 | 614265 | 724623
>> 6 | 106499 | 614406 | 720905
>> 7 | 110363 | 615015 | 725378
>> 8 | 115478 | 614840 | 730318
>> 9 | 110766 | 614168 | 724934
>> 10 | 108986 | 616435 | 725421
>> 11 | 108030 | 614299 | 722329
>> 12 | 109369 | 614420 | 723789
>> 13 | 105862 | 614456 | 720318
>> 14 | 110428 | 616301 | 726729
>>
>> Is 0.7 millisecond between write and read a reasonable number?
>
> No, at least not for a baudrate of 115200. Does the "latency" test
> report reasonable latency figures? And how did you load xeno_16550A.ko?
>
The latency test seems very reasonable:
4 microseconds when I try to open several browers at the
same time:
mini:/usr/xenomai/share/xenomai/testsuite/klatency# ./run
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT| 00:00:01 (in-kernel periodic task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD| -0.722| -0.618| 0.755| 0| -0.722| 0.755
RTD| -0.721| -0.616| 0.803| 0| -0.722| 0.803
RTD| -0.708| -0.616| 0.876| 0| -0.722| 0.876
RTD| -0.722| -0.616| 0.854| 0| -0.722| 0.876
RTD| -0.708| -0.617| 0.954| 0| -0.722| 0.954
RTD| -0.709| -0.615| 0.682| 0| -0.722| 0.954
RTD| -0.724| -0.595| 0.918| 0| -0.724| 0.954
RTD| -0.728| -0.477| 2.785| 0| -0.728| 2.785
RTD| -0.725| -0.526| 2.721| 0| -0.728| 2.785
RTD| -0.729| -0.512| 2.609| 0| -0.729| 2.785
RTD| -0.726| -0.485| 4.483| 0| -0.729| 4.483
RTD| -0.726| -0.479| 4.142| 0| -0.729| 4.483
RTD| -0.723| -0.542| 2.735| 0| -0.729| 4.483
RTD| -0.728| -0.580| 1.896| 0| -0.729| 4.483
RTD| -0.728| -0.540| 2.196| 0| -0.729| 4.483
RTD| -0.726| -0.566| 1.831| 0| -0.729| 4.483
RTD| -0.711| -0.607| 1.768| 0| -0.729| 4.483
RTD| -0.712| -0.591| 1.050| 0| -0.729| 4.483
RTD| -0.721| -0.615| 1.116| 0| -0.729| 4.483
RTD| -0.712| -0.612| 0.694| 0| -0.729| 4.483
RTD| -0.721| -0.614| 0.782| 0| -0.729| 4.483
^CRTT| 00:00:22 (in-kernel periodic task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD| -0.724| -0.610| 1.213| 0| -0.729| 4.483
---|------------|------------|------------|--------|-------------------------
RTS| -0.729| -0.554| 4.483| 0| 00:00:24/00:00:24
mini:/usr/xenomai/share/xenomai/testsuite/klatency#
The user space latency is also reasonable at 10 microseconds:
mini:/usr/xenomai/share/xenomai/testsuite/latency# ./run
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 0.245| 0.391| 2.736| 0| 0| 0.245| 2.736
RTD| 0.132| 0.663| 7.012| 0| 0| 0.132| 7.012
RTD| 0.248| 0.871| 6.954| 0| 0| 0.132| 7.012
RTD| 0.245| 0.650| 5.741| 0| 0| 0.132| 7.012
RTD| 0.213| 1.009| 10.657| 0| 0| 0.132| 10.657
RTD| 0.247| 0.902| 8.936| 0| 0| 0.132| 10.657
RTD| 0.177| 0.776| 6.978| 0| 0| 0.132| 10.657
RTD| 0.246| 0.735| 7.571| 0| 0| 0.132| 10.657
RTD| 0.245| 0.918| 8.821| 0| 0| 0.132| 10.657
RTD| 0.127| 0.387| 3.423| 0| 0| 0.127| 10.657
RTD| 0.138| 0.429| 2.977| 0| 0| 0.127| 10.657
RTD| 0.096| 0.357| 3.100| 0| 0| 0.096| 10.657
RTD| 0.133| 0.357| 3.019| 0| 0| 0.096| 10.657
RTD| 0.132| 0.356| 2.246| 0| 0| 0.096| 10.657
RTD| 0.140| 0.382| 5.711| 0| 0| 0.096| 10.657
RTD| 0.131| 0.361| 2.041| 0| 0| 0.096| 10.657
^C---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 0.096| 0.596| 10.657| 0| 0| 00:00:16/00:00:16
mini:/usr/xenomai/share/xenomai/testsuite/latency#
I load driver using this before running cross-link examples:
setserial /dev/ttyS0 uart none
setserial /dev/ttyS1 uart none
insmod /lib/modules/2.6.32.11-xeno/kernel/drivers/xenomai/serial/xeno_16550A.ko
io=0x3f8,0x2f8 irq=4,3 tx_fifo=10,20 start_index=0
>> I then changed the example a little: I let write task only
>> write 4 characters and instruct read task to read 10 characters.
>> I thought the read task will tell me when that only 4 characters
>> is read. But to my surprise, it waited until write-task
>> filled all 10 characters before finish reading. How can I
>> change the code to just do the read to whatever charaters
>> are avaliable without waiting to fill all the characters I
>> asked for? I will use this capability to read a GPS. It's
>> output length is unknow before reading.
>
> Setting the config rx timeout to RTSER_TIMEOUT_NONE should help.
>
Thanks for the suggestion, I will try that.
>> Most GPS can also produce a precisive time pulse when data
>> is ready. Is it be possible to connect this to a pin in rs232 (CTS, for example)
>> to triger a IRQ so the data can be read in a timely manner?
>
> That depends on the signals, I can imagine. I'm not a hardware guy but I
> know that many GPS receiver come with a read-to-use RS232 interface.
>
> Wolfgang.
>
Yes, you are right. My GPS has a rs232 port and I am trying
to use it. The GPS just dump out some information to the
rs232 port every 0.1 second. I am just trying to get the information
in a timely fashion. I thought that the extra time
pulse from the GPS can help.
Thanks a lot again for your help.
Everett
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] RTDM rs232 strange behavior
2010-06-07 12:07 ` Everett Wang
@ 2010-06-07 13:17 ` Wolfgang Grandegger
2010-06-08 1:32 ` Everett Wang
0 siblings, 1 reply; 7+ messages in thread
From: Wolfgang Grandegger @ 2010-06-07 13:17 UTC (permalink / raw)
To: Everett Wang; +Cc: xenomai
On 06/07/2010 02:07 PM, Everett Wang wrote:
> I am so glad that Wolfgang is able to help giving suggestions. Thanks
> a lot. That is very useful for new users. :-)
>
> On Mon, Jun 7, 2010 at 4:05 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>> On 06/05/2010 04:22 AM, Everett Wang wrote:
>>> Hi All,
>>>
>>> I am playing around with xenomai and RTDM serial driver on a
>>> 1.7Ghz Pentium-M machine running xenomai 2.5.3. The example cross-link
>>> produced this result:
>>>
>>> main : starting read-task
>>> Nr | write->irq | irq->read | write->read |
>>> -----------------------------------------------------------
>>> 0 | 118948 | 614135 | 733083
>>> 1 | 115598 | 614281 | 729879
>>> 2 | 108917 | 614982 | 723899
>>> 3 | 106101 | 616560 | 722661
>>> 4 | 113457 | 614971 | 728428
>>> 5 | 110358 | 614265 | 724623
>>> 6 | 106499 | 614406 | 720905
>>> 7 | 110363 | 615015 | 725378
>>> 8 | 115478 | 614840 | 730318
>>> 9 | 110766 | 614168 | 724934
>>> 10 | 108986 | 616435 | 725421
>>> 11 | 108030 | 614299 | 722329
>>> 12 | 109369 | 614420 | 723789
>>> 13 | 105862 | 614456 | 720318
>>> 14 | 110428 | 616301 | 726729
>>>
>>> Is 0.7 millisecond between write and read a reasonable number?
>>
>> No, at least not for a baudrate of 115200. Does the "latency" test
>> report reasonable latency figures? And how did you load xeno_16550A.ko?
>>
> The latency test seems very reasonable:
> 4 microseconds when I try to open several browers at the
> same time:
>
> mini:/usr/xenomai/share/xenomai/testsuite/klatency# ./run
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (in-kernel periodic task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD| -0.722| -0.618| 0.755| 0| -0.722| 0.755
> RTD| -0.721| -0.616| 0.803| 0| -0.722| 0.803
> RTD| -0.708| -0.616| 0.876| 0| -0.722| 0.876
> RTD| -0.722| -0.616| 0.854| 0| -0.722| 0.876
> RTD| -0.708| -0.617| 0.954| 0| -0.722| 0.954
> RTD| -0.709| -0.615| 0.682| 0| -0.722| 0.954
> RTD| -0.724| -0.595| 0.918| 0| -0.724| 0.954
> RTD| -0.728| -0.477| 2.785| 0| -0.728| 2.785
> RTD| -0.725| -0.526| 2.721| 0| -0.728| 2.785
> RTD| -0.729| -0.512| 2.609| 0| -0.729| 2.785
> RTD| -0.726| -0.485| 4.483| 0| -0.729| 4.483
> RTD| -0.726| -0.479| 4.142| 0| -0.729| 4.483
> RTD| -0.723| -0.542| 2.735| 0| -0.729| 4.483
> RTD| -0.728| -0.580| 1.896| 0| -0.729| 4.483
> RTD| -0.728| -0.540| 2.196| 0| -0.729| 4.483
> RTD| -0.726| -0.566| 1.831| 0| -0.729| 4.483
> RTD| -0.711| -0.607| 1.768| 0| -0.729| 4.483
> RTD| -0.712| -0.591| 1.050| 0| -0.729| 4.483
> RTD| -0.721| -0.615| 1.116| 0| -0.729| 4.483
> RTD| -0.712| -0.612| 0.694| 0| -0.729| 4.483
> RTD| -0.721| -0.614| 0.782| 0| -0.729| 4.483
> ^CRTT| 00:00:22 (in-kernel periodic task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD| -0.724| -0.610| 1.213| 0| -0.729| 4.483
> ---|------------|------------|------------|--------|-------------------------
> RTS| -0.729| -0.554| 4.483| 0| 00:00:24/00:00:24
> mini:/usr/xenomai/share/xenomai/testsuite/klatency#
>
> The user space latency is also reasonable at 10 microseconds:
> mini:/usr/xenomai/share/xenomai/testsuite/latency# ./run
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD| 0.245| 0.391| 2.736| 0| 0| 0.245| 2.736
> RTD| 0.132| 0.663| 7.012| 0| 0| 0.132| 7.012
> RTD| 0.248| 0.871| 6.954| 0| 0| 0.132| 7.012
> RTD| 0.245| 0.650| 5.741| 0| 0| 0.132| 7.012
> RTD| 0.213| 1.009| 10.657| 0| 0| 0.132| 10.657
> RTD| 0.247| 0.902| 8.936| 0| 0| 0.132| 10.657
> RTD| 0.177| 0.776| 6.978| 0| 0| 0.132| 10.657
> RTD| 0.246| 0.735| 7.571| 0| 0| 0.132| 10.657
> RTD| 0.245| 0.918| 8.821| 0| 0| 0.132| 10.657
> RTD| 0.127| 0.387| 3.423| 0| 0| 0.127| 10.657
> RTD| 0.138| 0.429| 2.977| 0| 0| 0.127| 10.657
> RTD| 0.096| 0.357| 3.100| 0| 0| 0.096| 10.657
> RTD| 0.133| 0.357| 3.019| 0| 0| 0.096| 10.657
> RTD| 0.132| 0.356| 2.246| 0| 0| 0.096| 10.657
> RTD| 0.140| 0.382| 5.711| 0| 0| 0.096| 10.657
> RTD| 0.131| 0.361| 2.041| 0| 0| 0.096| 10.657
> ^C---|-----------|-----------|-----------|--------|------|-------------------------
> RTS| 0.096| 0.596| 10.657| 0| 0| 00:00:16/00:00:16
> mini:/usr/xenomai/share/xenomai/testsuite/latency#
>
> I load driver using this before running cross-link examples:
>
> setserial /dev/ttyS0 uart none
> setserial /dev/ttyS1 uart none
> insmod /lib/modules/2.6.32.11-xeno/kernel/drivers/xenomai/serial/xeno_16550A.ko
> io=0x3f8,0x2f8 irq=4,3 tx_fifo=10,20 start_index=0
Are the interrupts shared with some other devices. What does
/proc/interrupt show when you run the test? Also, the default tx_fifo
should be fine. And what does "setserial -G /dev/ttyS0" list before you
disable the device (with "uart none").
>>> I then changed the example a little: I let write task only
>>> write 4 characters and instruct read task to read 10 characters.
>>> I thought the read task will tell me when that only 4 characters
>>> is read. But to my surprise, it waited until write-task
>>> filled all 10 characters before finish reading. How can I
>>> change the code to just do the read to whatever charaters
>>> are avaliable without waiting to fill all the characters I
>>> asked for? I will use this capability to read a GPS. It's
>>> output length is unknow before reading.
>>
>> Setting the config rx timeout to RTSER_TIMEOUT_NONE should help.
>>
> Thanks for the suggestion, I will try that.
>
>>> Most GPS can also produce a precisive time pulse when data
>>> is ready. Is it be possible to connect this to a pin in rs232 (CTS, for example)
>>> to triger a IRQ so the data can be read in a timely manner?
>>
>> That depends on the signals, I can imagine. I'm not a hardware guy but I
>> know that many GPS receiver come with a read-to-use RS232 interface.
>>
>> Wolfgang.
>>
> Yes, you are right. My GPS has a rs232 port and I am trying
> to use it. The GPS just dump out some information to the
> rs232 port every 0.1 second. I am just trying to get the information
> in a timely fashion. I thought that the extra time
> pulse from the GPS can help.
Just reading out the received data should be fine. They will generate an
interrupt anyway.
Wolfgang.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] RTDM rs232 strange behavior
2010-06-07 13:17 ` Wolfgang Grandegger
@ 2010-06-08 1:32 ` Everett Wang
2010-06-08 2:46 ` Everett Wang
0 siblings, 1 reply; 7+ messages in thread
From: Everett Wang @ 2010-06-08 1:32 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai
Hi Wolfgang,
Thanks for your quick email. :-)
On Mon, Jun 7, 2010 at 9:17 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
> On 06/07/2010 02:07 PM, Everett Wang wrote:
>> I am so glad that Wolfgang is able to help giving suggestions. Thanks
>> a lot. That is very useful for new users. :-)
>>
>> On Mon, Jun 7, 2010 at 4:05 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>>> On 06/05/2010 04:22 AM, Everett Wang wrote:
>>>> Hi All,
>>>>
>>>> I am playing around with xenomai and RTDM serial driver on a
>>>> 1.7Ghz Pentium-M machine running xenomai 2.5.3. The example cross-link
>>>> produced this result:
>>>>
>>>> main : starting read-task
>>>> Nr | write->irq | irq->read | write->read |
>>>> -----------------------------------------------------------
>>>> 0 | 118948 | 614135 | 733083
>>>> 1 | 115598 | 614281 | 729879
>>>> 2 | 108917 | 614982 | 723899
>>>> 3 | 106101 | 616560 | 722661
>>>> 4 | 113457 | 614971 | 728428
>>>> 5 | 110358 | 614265 | 724623
>>>> 6 | 106499 | 614406 | 720905
>>>> 7 | 110363 | 615015 | 725378
>>>> 8 | 115478 | 614840 | 730318
>>>> 9 | 110766 | 614168 | 724934
>>>> 10 | 108986 | 616435 | 725421
>>>> 11 | 108030 | 614299 | 722329
>>>> 12 | 109369 | 614420 | 723789
>>>> 13 | 105862 | 614456 | 720318
>>>> 14 | 110428 | 616301 | 726729
>>>>
>>>> Is 0.7 millisecond between write and read a reasonable number?
>>>
>>> No, at least not for a baudrate of 115200. Does the "latency" test
>>> report reasonable latency figures? And how did you load xeno_16550A.ko?
>>>
>> The latency test seems very reasonable:
>> 4 microseconds when I try to open several browers at the
>> same time:
>>
>> mini:/usr/xenomai/share/xenomai/testsuite/klatency# ./run
>> *
>> *
>> * Type ^C to stop this application.
>> *
>> *
>> == Sampling period: 100 us
>> == Test mode: in-kernel periodic task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (in-kernel periodic task, 100 us period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
>> RTD| -0.722| -0.618| 0.755| 0| -0.722| 0.755
>> RTD| -0.721| -0.616| 0.803| 0| -0.722| 0.803
>> RTD| -0.708| -0.616| 0.876| 0| -0.722| 0.876
>> RTD| -0.722| -0.616| 0.854| 0| -0.722| 0.876
>> RTD| -0.708| -0.617| 0.954| 0| -0.722| 0.954
>> RTD| -0.709| -0.615| 0.682| 0| -0.722| 0.954
>> RTD| -0.724| -0.595| 0.918| 0| -0.724| 0.954
>> RTD| -0.728| -0.477| 2.785| 0| -0.728| 2.785
>> RTD| -0.725| -0.526| 2.721| 0| -0.728| 2.785
>> RTD| -0.729| -0.512| 2.609| 0| -0.729| 2.785
>> RTD| -0.726| -0.485| 4.483| 0| -0.729| 4.483
>> RTD| -0.726| -0.479| 4.142| 0| -0.729| 4.483
>> RTD| -0.723| -0.542| 2.735| 0| -0.729| 4.483
>> RTD| -0.728| -0.580| 1.896| 0| -0.729| 4.483
>> RTD| -0.728| -0.540| 2.196| 0| -0.729| 4.483
>> RTD| -0.726| -0.566| 1.831| 0| -0.729| 4.483
>> RTD| -0.711| -0.607| 1.768| 0| -0.729| 4.483
>> RTD| -0.712| -0.591| 1.050| 0| -0.729| 4.483
>> RTD| -0.721| -0.615| 1.116| 0| -0.729| 4.483
>> RTD| -0.712| -0.612| 0.694| 0| -0.729| 4.483
>> RTD| -0.721| -0.614| 0.782| 0| -0.729| 4.483
>> ^CRTT| 00:00:22 (in-kernel periodic task, 100 us period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
>> RTD| -0.724| -0.610| 1.213| 0| -0.729| 4.483
>> ---|------------|------------|------------|--------|-------------------------
>> RTS| -0.729| -0.554| 4.483| 0| 00:00:24/00:00:24
>> mini:/usr/xenomai/share/xenomai/testsuite/klatency#
>>
>> The user space latency is also reasonable at 10 microseconds:
>> mini:/usr/xenomai/share/xenomai/testsuite/latency# ./run
>> *
>> *
>> * Type ^C to stop this application.
>> *
>> *
>> == Sampling period: 100 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99)
>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>> RTD| 0.245| 0.391| 2.736| 0| 0| 0.245| 2.736
>> RTD| 0.132| 0.663| 7.012| 0| 0| 0.132| 7.012
>> RTD| 0.248| 0.871| 6.954| 0| 0| 0.132| 7.012
>> RTD| 0.245| 0.650| 5.741| 0| 0| 0.132| 7.012
>> RTD| 0.213| 1.009| 10.657| 0| 0| 0.132| 10.657
>> RTD| 0.247| 0.902| 8.936| 0| 0| 0.132| 10.657
>> RTD| 0.177| 0.776| 6.978| 0| 0| 0.132| 10.657
>> RTD| 0.246| 0.735| 7.571| 0| 0| 0.132| 10.657
>> RTD| 0.245| 0.918| 8.821| 0| 0| 0.132| 10.657
>> RTD| 0.127| 0.387| 3.423| 0| 0| 0.127| 10.657
>> RTD| 0.138| 0.429| 2.977| 0| 0| 0.127| 10.657
>> RTD| 0.096| 0.357| 3.100| 0| 0| 0.096| 10.657
>> RTD| 0.133| 0.357| 3.019| 0| 0| 0.096| 10.657
>> RTD| 0.132| 0.356| 2.246| 0| 0| 0.096| 10.657
>> RTD| 0.140| 0.382| 5.711| 0| 0| 0.096| 10.657
>> RTD| 0.131| 0.361| 2.041| 0| 0| 0.096| 10.657
>> ^C---|-----------|-----------|-----------|--------|------|-------------------------
>> RTS| 0.096| 0.596| 10.657| 0| 0| 00:00:16/00:00:16
>> mini:/usr/xenomai/share/xenomai/testsuite/latency#
>>
>> I load driver using this before running cross-link examples:
>>
>> setserial /dev/ttyS0 uart none
>> setserial /dev/ttyS1 uart none
>> insmod /lib/modules/2.6.32.11-xeno/kernel/drivers/xenomai/serial/xeno_16550A.ko
>> io=0x3f8,0x2f8 irq=4,3 tx_fifo=10,20 start_index=0
>
> Are the interrupts shared with some other devices. What does
> /proc/interrupt show when you run the test? Also, the default tx_fifo
> should be fine. And what does "setserial -G /dev/ttyS0" list before you
> disable the device (with "uart none").
>
I look at the bios setting. All irqs are set automatically. Window
setup indicated no conflict of IRQs. But dmesg has this:
[ 0.356143] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.356143] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.356143] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 0.359109] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.359263] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
I guess the IRQ is shared with something else. But I can't finger our
what else is using IRQ 3 and 4. The computer has only two serial
ports.
setserial -G has this:
# setserial -G /dev/ttyS0
/dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test
# setserial -G /dev/ttyS1
/dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test
Now I load xeno_16550A.ko with default fifo.
I also looked at the /proc/interrupt file
during running of the cross-link
everett@domain.hid$ cat interrupts
CPU0
0: 18169 IO-APIC-edge timer
1: 1492 IO-APIC-edge i8042
3: 10 IO-APIC-edge
4: 9 IO-APIC-edge
7: 0 IO-APIC-edge parport0
8: 2 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
10: 0 IO-APIC-edge MPU401 UART
14: 7835 IO-APIC-edge ide0
15: 6662 IO-APIC-edge ide1
16: 9665 IO-APIC-fasteoi uhci_hcd:usb1, i915@domain.hid
17: 1 IO-APIC-fasteoi Intel 82801DB-ICH4
18: 28708 IO-APIC-fasteoi uhci_hcd:usb4, ipw2200
19: 0 IO-APIC-fasteoi uhci_hcd:usb3
20: 3660 IO-APIC-fasteoi eth0
23: 2 IO-APIC-fasteoi ehci_hcd:usb2
NMI: 0 Non-maskable interrupts
LOC: 72987 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
PND: 0 Performance pending work
TRM: 0 Thermal event interrupts
THR: 0 Threshold APIC interrupts
MCE: 0 Machine check exceptions
MCP: 3 Machine check polls
ERR: 0
MIS: 0
I can see IRQ 1, which is used by i8042, as well as local time
interrupt are increasing. But not IRQ 3 and 4. They are
not changing during cross-link run.
>>>> I then changed the example a little: I let write task only
>>>> write 4 characters and instruct read task to read 10 characters.
>>>> I thought the read task will tell me when that only 4 characters
>>>> is read. But to my surprise, it waited until write-task
>>>> filled all 10 characters before finish reading. How can I
>>>> change the code to just do the read to whatever charaters
>>>> are avaliable without waiting to fill all the characters I
>>>> asked for? I will use this capability to read a GPS. It's
>>>> output length is unknow before reading.
>>>
>>> Setting the config rx timeout to RTSER_TIMEOUT_NONE should help.
>>>
>> Thanks for the suggestion, I will try that.
Yes, changing the rx timeout can read 4 characters. That is now working.
>>>> Most GPS can also produce a precisive time pulse when data
>>>> is ready. Is it be possible to connect this to a pin in rs232 (CTS, for example)
>>>> to triger a IRQ so the data can be read in a timely manner?
>>>
>>> That depends on the signals, I can imagine. I'm not a hardware guy but I
>>> know that many GPS receiver come with a read-to-use RS232 interface.
>>>
>>> Wolfgang.
>>>
>> Yes, you are right. My GPS has a rs232 port and I am trying
>> to use it. The GPS just dump out some information to the
>> rs232 port every 0.1 second. I am just trying to get the information
>> in a timely fashion. I thought that the extra time
>> pulse from the GPS can help.
>
> Just reading out the received data should be fine. They will generate an
> interrupt anyway.
>
> Wolfgang.
>
That is great. If I can get this serial IRQ to work, I don't have to
deal with the time pulse signal. The original idea is from a book. It
states that GPS precision time pulse should be used to drive data
acquisition action.
Thanks a lot.
Everett
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] RTDM rs232 strange behavior
2010-06-08 1:32 ` Everett Wang
@ 2010-06-08 2:46 ` Everett Wang
0 siblings, 0 replies; 7+ messages in thread
From: Everett Wang @ 2010-06-08 2:46 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai
Hi Wolfgang,
I overlooked the irq thing. If I look at the /proc/xenomai/irq
I see this when cross-link is not running:
everett@domain.hid$ cat irq
everett@domain.hid$ cat irq
IRQ CPU0
300: 11671 [timer]
322: 0 [virtual]
when cross-link is running:
everett@domain.hid$ cat irq
IRQ CPU0
3: 1320 rtser1
4: 165 rtser0
300: 14785 [timer]
322: 500 [virtual]
The IRQ 3 and 4 numbers are increasing rapidly. So it seems to be
working fine. What a normal time lag is expect between write
and read for X86 machine?
Thanks,
Everett
On Tue, Jun 8, 2010 at 9:32 AM, Everett Wang <everteq@domain.hid> wrote:
> Hi Wolfgang,
>
> Thanks for your quick email. :-)
>
> On Mon, Jun 7, 2010 at 9:17 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>> On 06/07/2010 02:07 PM, Everett Wang wrote:
>>> I am so glad that Wolfgang is able to help giving suggestions. Thanks
>>> a lot. That is very useful for new users. :-)
>>>
>>> On Mon, Jun 7, 2010 at 4:05 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>>>> On 06/05/2010 04:22 AM, Everett Wang wrote:
>>>>> Hi All,
>>>>>
>>>>> I am playing around with xenomai and RTDM serial driver on a
>>>>> 1.7Ghz Pentium-M machine running xenomai 2.5.3. The example cross-link
>>>>> produced this result:
>>>>>
>>>>> main : starting read-task
>>>>> Nr | write->irq | irq->read | write->read |
>>>>> -----------------------------------------------------------
>>>>> 0 | 118948 | 614135 | 733083
>>>>> 1 | 115598 | 614281 | 729879
>>>>> 2 | 108917 | 614982 | 723899
>>>>> 3 | 106101 | 616560 | 722661
>>>>> 4 | 113457 | 614971 | 728428
>>>>> 5 | 110358 | 614265 | 724623
>>>>> 6 | 106499 | 614406 | 720905
>>>>> 7 | 110363 | 615015 | 725378
>>>>> 8 | 115478 | 614840 | 730318
>>>>> 9 | 110766 | 614168 | 724934
>>>>> 10 | 108986 | 616435 | 725421
>>>>> 11 | 108030 | 614299 | 722329
>>>>> 12 | 109369 | 614420 | 723789
>>>>> 13 | 105862 | 614456 | 720318
>>>>> 14 | 110428 | 616301 | 726729
>>>>>
>>>>> Is 0.7 millisecond between write and read a reasonable number?
>>>>
>>>> No, at least not for a baudrate of 115200. Does the "latency" test
>>>> report reasonable latency figures? And how did you load xeno_16550A.ko?
>>>>
>>> The latency test seems very reasonable:
>>> 4 microseconds when I try to open several browers at the
>>> same time:
>>>
>>> mini:/usr/xenomai/share/xenomai/testsuite/klatency# ./run
>>> *
>>> *
>>> * Type ^C to stop this application.
>>> *
>>> *
>>> == Sampling period: 100 us
>>> == Test mode: in-kernel periodic task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (in-kernel periodic task, 100 us period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
>>> RTD| -0.722| -0.618| 0.755| 0| -0.722| 0.755
>>> RTD| -0.721| -0.616| 0.803| 0| -0.722| 0.803
>>> RTD| -0.708| -0.616| 0.876| 0| -0.722| 0.876
>>> RTD| -0.722| -0.616| 0.854| 0| -0.722| 0.876
>>> RTD| -0.708| -0.617| 0.954| 0| -0.722| 0.954
>>> RTD| -0.709| -0.615| 0.682| 0| -0.722| 0.954
>>> RTD| -0.724| -0.595| 0.918| 0| -0.724| 0.954
>>> RTD| -0.728| -0.477| 2.785| 0| -0.728| 2.785
>>> RTD| -0.725| -0.526| 2.721| 0| -0.728| 2.785
>>> RTD| -0.729| -0.512| 2.609| 0| -0.729| 2.785
>>> RTD| -0.726| -0.485| 4.483| 0| -0.729| 4.483
>>> RTD| -0.726| -0.479| 4.142| 0| -0.729| 4.483
>>> RTD| -0.723| -0.542| 2.735| 0| -0.729| 4.483
>>> RTD| -0.728| -0.580| 1.896| 0| -0.729| 4.483
>>> RTD| -0.728| -0.540| 2.196| 0| -0.729| 4.483
>>> RTD| -0.726| -0.566| 1.831| 0| -0.729| 4.483
>>> RTD| -0.711| -0.607| 1.768| 0| -0.729| 4.483
>>> RTD| -0.712| -0.591| 1.050| 0| -0.729| 4.483
>>> RTD| -0.721| -0.615| 1.116| 0| -0.729| 4.483
>>> RTD| -0.712| -0.612| 0.694| 0| -0.729| 4.483
>>> RTD| -0.721| -0.614| 0.782| 0| -0.729| 4.483
>>> ^CRTT| 00:00:22 (in-kernel periodic task, 100 us period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
>>> RTD| -0.724| -0.610| 1.213| 0| -0.729| 4.483
>>> ---|------------|------------|------------|--------|-------------------------
>>> RTS| -0.729| -0.554| 4.483| 0| 00:00:24/00:00:24
>>> mini:/usr/xenomai/share/xenomai/testsuite/klatency#
>>>
>>> The user space latency is also reasonable at 10 microseconds:
>>> mini:/usr/xenomai/share/xenomai/testsuite/latency# ./run
>>> *
>>> *
>>> * Type ^C to stop this application.
>>> *
>>> *
>>> == Sampling period: 100 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99)
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>> RTD| 0.245| 0.391| 2.736| 0| 0| 0.245| 2.736
>>> RTD| 0.132| 0.663| 7.012| 0| 0| 0.132| 7.012
>>> RTD| 0.248| 0.871| 6.954| 0| 0| 0.132| 7.012
>>> RTD| 0.245| 0.650| 5.741| 0| 0| 0.132| 7.012
>>> RTD| 0.213| 1.009| 10.657| 0| 0| 0.132| 10.657
>>> RTD| 0.247| 0.902| 8.936| 0| 0| 0.132| 10.657
>>> RTD| 0.177| 0.776| 6.978| 0| 0| 0.132| 10.657
>>> RTD| 0.246| 0.735| 7.571| 0| 0| 0.132| 10.657
>>> RTD| 0.245| 0.918| 8.821| 0| 0| 0.132| 10.657
>>> RTD| 0.127| 0.387| 3.423| 0| 0| 0.127| 10.657
>>> RTD| 0.138| 0.429| 2.977| 0| 0| 0.127| 10.657
>>> RTD| 0.096| 0.357| 3.100| 0| 0| 0.096| 10.657
>>> RTD| 0.133| 0.357| 3.019| 0| 0| 0.096| 10.657
>>> RTD| 0.132| 0.356| 2.246| 0| 0| 0.096| 10.657
>>> RTD| 0.140| 0.382| 5.711| 0| 0| 0.096| 10.657
>>> RTD| 0.131| 0.361| 2.041| 0| 0| 0.096| 10.657
>>> ^C---|-----------|-----------|-----------|--------|------|-------------------------
>>> RTS| 0.096| 0.596| 10.657| 0| 0| 00:00:16/00:00:16
>>> mini:/usr/xenomai/share/xenomai/testsuite/latency#
>>>
>>> I load driver using this before running cross-link examples:
>>>
>>> setserial /dev/ttyS0 uart none
>>> setserial /dev/ttyS1 uart none
>>> insmod /lib/modules/2.6.32.11-xeno/kernel/drivers/xenomai/serial/xeno_16550A.ko
>>> io=0x3f8,0x2f8 irq=4,3 tx_fifo=10,20 start_index=0
>>
>> Are the interrupts shared with some other devices. What does
>> /proc/interrupt show when you run the test? Also, the default tx_fifo
>> should be fine. And what does "setserial -G /dev/ttyS0" list before you
>> disable the device (with "uart none").
>>
>
> I look at the bios setting. All irqs are set automatically. Window
> setup indicated no conflict of IRQs. But dmesg has this:
>
> [ 0.356143] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [ 0.356143] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [ 0.356143] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> [ 0.359109] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [ 0.359263] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>
> I guess the IRQ is shared with something else. But I can't finger our
> what else is using IRQ 3 and 4. The computer has only two serial
> ports.
>
> setserial -G has this:
>
> # setserial -G /dev/ttyS0
> /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test
> # setserial -G /dev/ttyS1
> /dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test
>
> Now I load xeno_16550A.ko with default fifo.
> I also looked at the /proc/interrupt file
> during running of the cross-link
> everett@domain.hid$ cat interrupts
> CPU0
> 0: 18169 IO-APIC-edge timer
> 1: 1492 IO-APIC-edge i8042
> 3: 10 IO-APIC-edge
> 4: 9 IO-APIC-edge
> 7: 0 IO-APIC-edge parport0
> 8: 2 IO-APIC-edge rtc0
> 9: 0 IO-APIC-fasteoi acpi
> 10: 0 IO-APIC-edge MPU401 UART
> 14: 7835 IO-APIC-edge ide0
> 15: 6662 IO-APIC-edge ide1
> 16: 9665 IO-APIC-fasteoi uhci_hcd:usb1, i915@domain.hid000:00:02.0
> 17: 1 IO-APIC-fasteoi Intel 82801DB-ICH4
> 18: 28708 IO-APIC-fasteoi uhci_hcd:usb4, ipw2200
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 3660 IO-APIC-fasteoi eth0
> 23: 2 IO-APIC-fasteoi ehci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 72987 Local timer interrupts
> SPU: 0 Spurious interrupts
> PMI: 0 Performance monitoring interrupts
> PND: 0 Performance pending work
> TRM: 0 Thermal event interrupts
> THR: 0 Threshold APIC interrupts
> MCE: 0 Machine check exceptions
> MCP: 3 Machine check polls
> ERR: 0
> MIS: 0
>
> I can see IRQ 1, which is used by i8042, as well as local time
> interrupt are increasing. But not IRQ 3 and 4. They are
> not changing during cross-link run.
>
>>>>> I then changed the example a little: I let write task only
>>>>> write 4 characters and instruct read task to read 10 characters.
>>>>> I thought the read task will tell me when that only 4 characters
>>>>> is read. But to my surprise, it waited until write-task
>>>>> filled all 10 characters before finish reading. How can I
>>>>> change the code to just do the read to whatever charaters
>>>>> are avaliable without waiting to fill all the characters I
>>>>> asked for? I will use this capability to read a GPS. It's
>>>>> output length is unknow before reading.
>>>>
>>>> Setting the config rx timeout to RTSER_TIMEOUT_NONE should help.
>>>>
>>> Thanks for the suggestion, I will try that.
> Yes, changing the rx timeout can read 4 characters. That is now working.
>
>>>>> Most GPS can also produce a precisive time pulse when data
>>>>> is ready. Is it be possible to connect this to a pin in rs232 (CTS, for example)
>>>>> to triger a IRQ so the data can be read in a timely manner?
>>>>
>>>> That depends on the signals, I can imagine. I'm not a hardware guy but I
>>>> know that many GPS receiver come with a read-to-use RS232 interface.
>>>>
>>>> Wolfgang.
>>>>
>>> Yes, you are right. My GPS has a rs232 port and I am trying
>>> to use it. The GPS just dump out some information to the
>>> rs232 port every 0.1 second. I am just trying to get the information
>>> in a timely fashion. I thought that the extra time
>>> pulse from the GPS can help.
>>
>> Just reading out the received data should be fine. They will generate an
>> interrupt anyway.
>>
>> Wolfgang.
>>
> That is great. If I can get this serial IRQ to work, I don't have to
> deal with the time pulse signal. The original idea is from a book. It
> states that GPS precision time pulse should be used to drive data
> acquisition action.
>
> Thanks a lot.
>
> Everett
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] RTDM rs232 strange behavior
2010-06-05 2:22 [Xenomai-help] RTDM rs232 strange behavior Everett Wang
2010-06-07 8:05 ` Wolfgang Grandegger
@ 2010-06-09 6:19 ` Wolfgang Grandegger
1 sibling, 0 replies; 7+ messages in thread
From: Wolfgang Grandegger @ 2010-06-09 6:19 UTC (permalink / raw)
To: Everett Wang; +Cc: xenomai
On 06/05/2010 04:22 AM, Everett Wang wrote:
> Hi All,
>
> I am playing around with xenomai and RTDM serial driver on a
> 1.7Ghz Pentium-M machine running xenomai 2.5.3. The example cross-link
> produced this result:
>
> main : starting read-task
> Nr | write->irq | irq->read | write->read |
> -----------------------------------------------------------
> 0 | 118948 | 614135 | 733083
> 1 | 115598 | 614281 | 729879
> 2 | 108917 | 614982 | 723899
> 3 | 106101 | 616560 | 722661
> 4 | 113457 | 614971 | 728428
> 5 | 110358 | 614265 | 724623
> 6 | 106499 | 614406 | 720905
> 7 | 110363 | 615015 | 725378
> 8 | 115478 | 614840 | 730318
> 9 | 110766 | 614168 | 724934
> 10 | 108986 | 616435 | 725421
> 11 | 108030 | 614299 | 722329
> 12 | 109369 | 614420 | 723789
> 13 | 105862 | 614456 | 720318
> 14 | 110428 | 616301 | 726729
>
> Is 0.7 millisecond between write and read a reasonable number?
I just ran this test on my PC and got similar results. The figures are
in *nanoseconds*. And yes, stupid me, 0.7 *milli-seconds* is a resonable
number for 115200: (2 * 4 bytes * 10 bits-per-byte) / 115200 bits/sec.
Wolfgang.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-06-09 6:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-05 2:22 [Xenomai-help] RTDM rs232 strange behavior Everett Wang
2010-06-07 8:05 ` Wolfgang Grandegger
2010-06-07 12:07 ` Everett Wang
2010-06-07 13:17 ` Wolfgang Grandegger
2010-06-08 1:32 ` Everett Wang
2010-06-08 2:46 ` Everett Wang
2010-06-09 6:19 ` Wolfgang Grandegger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.