Hi Wolfgang, I overlooked the irq thing. If I look at the /proc/xenomai/irq I see this when cross-link is not running: ever...@mini:/proc/xenomai$ cat irq ever...@mini:/proc/xenomai$ cat irq IRQ CPU0 300: 11671 [timer] 322: 0 [virtual]
when cross-link is running: ever...@mini:/proc/xenomai$ 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 <[email protected]> wrote: > Hi Wolfgang, > > Thanks for your quick email. :-) > > On Mon, Jun 7, 2010 at 9:17 PM, Wolfgang Grandegger <[email protected]> > 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 <[email protected]> >>> 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 > ever...@mini:/proc$ 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, i...@pci:0000: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 > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
