* [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.