Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT
On 04/02/2012 10:25 AM, Minh GIANG wrote:
> hello,
>
> i don't know how call the function rt_dev_ioctl() after the timeout
> happened, this function is called in the begining of "while" loop
> (cross-link program).
> I get the value of struct rtser_status,
> line status = 96
> modem status = 176
> to be honest, i don't know why cross-line program works without the
> function rt_dev_ioctl() with RTSER_RTIOC_WAIT_EVENT in option.
>
> main : write-file opened
> main : write-config written
> main : read-file opened
> main : read-config written
> main : write-task created
> main : read-task created
> main : starting write-task
> main : starting read-task
> Nr | write->irq|irq->read| write->read |
> ---
> 0 |17113389816533987823 |154257183912191 | 8348398
> 1 |17113389815533997483 |154258183885264 | 8331131
> 2 |17113389814533998100 |154259183882033 | 8328517
> 3 |17113389813534000420 |154260183884535 | 839
> 4 |17113389812533998430 |154261183888665 | 8335479
> ..
>
> i tried to send a character table, and it also worked.
Hm, maybe you receive something, but the numbers are bogous. To
understand better what's going on, coud you please apply the attached
patch to your Xenomai tree, rebuild the kernel and send the dmesg output
while running cross-link.
BTW: what Xenomai version are you using?
Wolfgang.
> On Fri, Mar 30, 2012 at 4:48 PM, Wolfgang Grandegger
> wrote:
>
>> On 03/30/2012 04:34 PM, Minh GIANG wrote:
>>> hi,
>>>
>>> with option RTSER_RTIOC_WAIT_EVENT in rt_dev_ioctl(), this function
>> returns
>>> un number -110 (Connection timed out)
>>> with option RTSER_RTIOC_GET_STATUS in rt_dev_ioctl(), this function
>> returns
>>> un number 0 (not message)
>>
>> You should call this function *after* the timeout happened. What does
>> the "struct rtser_status" contain? Especially the "line_status" is of
>> interest.
>>
>>>
>>> Anyway, currently it works without rt_dev_ioctl(), i can see
>> rt_dev_read()
>>> wait data event (with debug mode) while giving the period of write
>>> task, for exemple = two seconds.
>>>
>>> so can i remove the funtion rt_dev_ioctl?
>>
>> The rt_dev_ioctl should work. You can remove it, but the problem will
>> remain. To debug the problem you could also add some printk's here:
>>
>>
>> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/serial/16550A.c#223
>>
>> Especially the value of "iir" might be interesting.
>>
>> Wolfgang.
>>
>
diff --git a/ksrc/drivers/serial/16550A.c b/ksrc/drivers/serial/16550A.c
index 3672539..392c4f7 100644
--- a/ksrc/drivers/serial/16550A.c
+++ b/ksrc/drivers/serial/16550A.c
@@ -240,6 +240,7 @@ static int rt_16550_interrupt(rtdm_irq_t * irq_context)
while (1) {
iir = rt_16550_reg_in(mode, base, IIR) & IIR_MASK;
+ printk("base=%#lx iir=%#x\n", base, iir);
if (testbits(iir, IIR_PIRQ))
break;
@@ -258,6 +259,7 @@ static int rt_16550_interrupt(rtdm_irq_t * irq_context)
events |= RTSER_EVENT_MODEMLO;
}
+ printk("base=%#lx status=%#x\n", base, ctx->status);
ret = RTDM_IRQ_HANDLED;
}
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Intermixing native and POSIX skins
On 03/27/2012 11:35 PM, Doug Brunner wrote: The usage pattern would be a bit like BSD ptys--the server maintains a few ports, say named "server0" through "server15" and clients that need a port try "server0", if it's busy then try "server1", etc.. An option to mimic this partially might be to define a fixed port number clients would use to ask the server for a free port to connect to later on? The server would let the RTIPC layer pick a free port when binding, then return it to the client via a converse message to the fixed port. I suppose the problem here is really that the application running over these sockets is stateful, the configuration of the nodes (processes) that are communicating is not known until run time, and nodes may appear and disappear as the server runs, so the transport needs to be connection-oriented rather than message-oriented. The semaphore is still a bit of a kludge, since it doesn't notify a thread blocked on recv() that the remote has hung up, but it works well enough in conjunction with a message that says "I'm a client that's newly connected to this server" to reset the state associated with the connection. I suppose I could implement a sort of TCP handshake on top of the IDDP socket layer and use that to provide true connection-oriented behavior. Yep, RTIPC won't help that much by default in that area, it only exhibits connectionless semantics. Good to know about in-order delivery; a quick glance at the source code seemed to suggest that, but I wasn't sure. Doug Brunner -Original Message- From: "Philippe Gerum" Sent: Tuesday, March 27, 2012 9:26am To: "Doug Brunner" Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Intermixing native and POSIX skins On 03/26/2012 06:14 PM, Doug Brunner wrote: Thanks for the information--the issue is not about picking a free port on the server side, but rather about communicating the information on which ports are "free" to the clients (server has connected its end, but no other client is using the port). The semaphore mechanism isn't that much of a problem, though; I've been able to build a satisfactory implementation. Mm, still scratching my head to understand the issue. Both the client and server side accept -1 as the port spec, telling the kernel to draw a free port. I understand the issue is not on the server side, so is it on the client side? Could you sketch the usage pattern? One other question: although I know in-order delivery isn't necessarily a feature of datagram based protocols, would I get that with an IDDP socket connection between just two processes, and/or an XDDP connection to a /dev/rtpN? Yes, in-order delivery is guaranteed with all RTIPC protocols. This is written in stone. Doug Brunner -Original Message- From: "Philippe Gerum" Sent: Friday, March 16, 2012 11:29am To: "Doug Brunner" Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Intermixing native and POSIX skins On 03/15/2012 05:30 PM, Doug Brunner wrote: Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea. I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label). This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface? The RTIPC protocols are fundamentally datagram-based, so allowing N:1 data paths is wanted. If the issue is about picking a different port each time you bind a server socket in the AF_RTIPC domain, then I would suggest to set sipc_port to -1 when binding the server-side socket: a free port will be picked automatically. You could then use getsockname() to retrieve the actual port #, and pass it to the clients. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt latency greater than 250ms. Question.
On 03/28/2012 08:23 PM, Makarand Pradhan wrote: Hi Philippe, On 28/03/12 12:17 PM, Philippe Gerum wrote: The log says your code wants to control when the IRQ is enabled again, by calling rt_intr_enable() from userland. I guess you are setting I_NOAUTOENA too. Correct? That is correct. I_NOAUTOENA is used in rt_intr_create. Otherwise the level trigerred interrupt will not allow the userland processing of the int. The userland handler is very small and it unconditionally rt_intr_enables the intr. Testing indicates that the interrupt is always enabled from user space within 250 usec after kernel gets the interrupt. I have noted that unless I see "#end 0x002b" and a hit to the ipic_unmask_irq, the next interrupt is not processed. And this is getting delayed once in a while which causes a delay in processing the next interrupt. So the sequence of events leading to the problem is: 1. Get interrupt: #begin 0x002b noted in ipipe trace 2. Intr enabled from user space. Always happens roughly within 250usec. 3. #end 0x002b noted in ipipe trace where the int is unmasked by ipipe. When I see the problem, step 3 is delayed. I am trying to capture a trace where the begin, int enable and end are captured. Your thoughts on what might cause this delay would be appreciated. Which IRQ are you re-enabling from user-space, the multiplexed IRQ 33, or the cascaded one you receive? Rgds, Mak. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] analogy - serial port
On 04/02/2012 04:12 PM, Minh GIANG wrote: > Hello everybody, > > Do the Analogy driver support the serial port. I can attach the serial > port(ttyS0) to rtser0 with xeno_16550A.ko as mentionned in Xenomai > Documentation > > modprobe xeno_16550A io=[,...] irq=[,...] > [baud_base=[,...]] > [tx_fifo=[,...]] [start_index=] > > > How can i tell to the Analogy driver to recognize the serial port in > order to use the Analogy API. i have seen the command > > /xeno_install/sbin/analogy_config analogy0 analogy_ni_pcimio > > i think that analogy_ni_pcimio is the drivers suppors of National > Instruments PCI / PXI cards. But i don't have the DAQ card yet, > currently i test with two serial ports on my computer while connecting > them by one cable. the first aim is to test the api analogy. > > Thanks, > > > > when i try to add the analogy_ni_pcimio module over terminal linux. i > get one message error > > insmod analogy_ni_pcimio.ko > > analogy_ni_pcimio.ko : -1 Unknown symbol in module And I forgot. Please stick to plain text mails, do not waste everyone's bandwidth with HTML. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] analogy - serial port
On 04/02/2012 04:12 PM, Minh GIANG wrote: > Hello everybody, > > Do the Analogy driver support the serial port. I can attach the serial > port(ttyS0) to rtser0 with xeno_16550A.ko as mentionned in Xenomai > Documentation > > modprobe xeno_16550A io=[,...] irq=[,...] > [baud_base=[,...]] > [tx_fifo=[,...]] [start_index=] > > > How can i tell to the Analogy driver to recognize the serial port in > order to use the Analogy API. i have seen the command > > /xeno_install/sbin/analogy_config analogy0 analogy_ni_pcimio > > i think that analogy_ni_pcimio is the drivers suppors of National > Instruments PCI / PXI cards. But i don't have the DAQ card yet, > currently i test with two serial ports on my computer while connecting > them by one cable. the first aim is to test the api analogy. Sorry, I did not make myself clear: the RTDM API is a general API for making drivers, Analogy is a class of drivers for acquisition boards written using RTDM. The analogy library allow access to this class of driver, so, you can not use the analogy library with a serial port driver. > > Thanks, > > > > when i try to add the analogy_ni_pcimio module over terminal linux. i > get one message error > > insmod analogy_ni_pcimio.ko > > analogy_ni_pcimio.ko : -1 Unknown symbol in module See dmesg to understand what symbol is missing. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] analogy - serial port
Hello everybody, Do the Analogy driver support the serial port. I can attach the serial port(ttyS0) to rtser0 with xeno_16550A.ko as mentionned in Xenomai Documentation modprobe xeno_16550A io=[,...] irq=[,...] [baud_base=[,...]] [tx_fifo=[,...]] [start_index=] How can i tell to the Analogy driver to recognize the serial port in order to use the Analogy API. i have seen the command /xeno_install/sbin/analogy_config analogy0 analogy_ni_pcimio i think that analogy_ni_pcimio is the drivers suppors of National Instruments PCI / PXI cards. But i don't have the DAQ card yet, currently i test with two serial ports on my computer while connecting them by one cable. the first aim is to test the api analogy. Thanks, when i try to add the analogy_ni_pcimio module over terminal linux. i get one message error insmod analogy_ni_pcimio.ko analogy_ni_pcimio.ko : -1 Unknown symbol in module ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT
hello, i don't know how call the function rt_dev_ioctl() after the timeout happened, this function is called in the begining of "while" loop (cross-link program). I get the value of struct rtser_status, line status = 96 modem status = 176 to be honest, i don't know why cross-line program works without the function rt_dev_ioctl() with RTSER_RTIOC_WAIT_EVENT in option. main : write-file opened main : write-config written main : read-file opened main : read-config written main : write-task created main : read-task created main : starting write-task main : starting read-task Nr | write->irq|irq->read| write->read | --- 0 |17113389816533987823 |154257183912191 | 8348398 1 |17113389815533997483 |154258183885264 | 8331131 2 |17113389814533998100 |154259183882033 | 8328517 3 |17113389813534000420 |154260183884535 | 839 4 |17113389812533998430 |154261183888665 | 8335479 .. i tried to send a character table, and it also worked. On Fri, Mar 30, 2012 at 4:48 PM, Wolfgang Grandegger wrote: > On 03/30/2012 04:34 PM, Minh GIANG wrote: > > hi, > > > > with option RTSER_RTIOC_WAIT_EVENT in rt_dev_ioctl(), this function > returns > > un number -110 (Connection timed out) > > with option RTSER_RTIOC_GET_STATUS in rt_dev_ioctl(), this function > returns > > un number 0 (not message) > > You should call this function *after* the timeout happened. What does > the "struct rtser_status" contain? Especially the "line_status" is of > interest. > > > > > Anyway, currently it works without rt_dev_ioctl(), i can see > rt_dev_read() > > wait data event (with debug mode) while giving the period of write > > task, for exemple = two seconds. > > > > so can i remove the funtion rt_dev_ioctl? > > The rt_dev_ioctl should work. You can remove it, but the problem will > remain. To debug the problem you could also add some printk's here: > > > http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/serial/16550A.c#223 > > Especially the value of "iir" might be interesting. > > Wolfgang. > ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
