Rtems_termios_ioctl problem
Thomas Doerfler
Thomas.Doerfler at imd-systems.de
Wed May 2 19:38:11 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
wow, big mistake, I have outed me to know about the flow control
stuff... :-)
After digging around in the code (mainly in fillBufferQueue()), I have
extracted the following lines, which are used there when the input
buffer has enough space for further reception (which is definitively the
case when the buffer was flushed).
- ---- snip
tty->flow_ctrl &= ~FL_IREQXOF;
/* if tx stopped and XON should be sent... */
if (((tty->flow_ctrl & (FL_MDXON | FL_ISNTXOF))
== (FL_MDXON | FL_ISNTXOF))
&& ((tty->rawOutBufState == rob_idle)
|| (tty->flow_ctrl & FL_OSTOP))) {
/* XON should be sent now... */
(*tty->device.write)(tty->minor,
(void *)&(tty->termios.c_cc[VSTART]),
1);
}
else if (tty->flow_ctrl & FL_MDRTS) {
tty->flow_ctrl &= ~FL_IRTSOFF;
/* activate RTS line */
if (tty->device.startRemoteTx != NULL) {
tty->device.startRemoteTx(tty->minor);
}
}
- ---- snip
Stephane, can you add this after you have flushed to input buffer? I
checks, whether XON must be sent (and sends it possibly) and it also
takes care about the HW flow control.
wkr,
Thomas.
Eric Norum schrieb:
> Can someone who's familiar with the flow-control details of termios
> have a look at the interaction with this?
>
> Why do you need to send a break? The 'correct' way to do this would
> involve changes to low level drivers. A workaround, for those
> applications that really need to drive the serial line to such a
> state, is to temporarily set the serial line speed to a lower value,
> then transmit a NUL character, wait the the transmitter is again
> idle, and restore the line speed. Of course this means that any
> incoming characters will be mangled during this time.....
>
> <Controversial>
> My feeling is that the termios code is already too complicated and
> that all the code to support XON/XOFF flow control should be optional
> or removed.
> Does anyone really use this antiquated and unreliable means of flow
> control any more?
> I'd be happy with leaving flow control up to the hardware (RTS/CTS)
> and dropping all references to flow control from the generic termios
> code.
> /<Controversial>
>
> On May 2, 2007, at 10:53 AM, Arquer Stephane wrote:
>
>> Hi,
>>
>> Thanks for your answers, I've modified the file with your advices
>>
>> case TCFLSH:
>> {
>> switch (args->buffer) {
>> case TCIFLUSH: /* flush input buffer */
>> {
>> if ( tty->rawInBuf.Tail != tty->rawInBuf.Head ) /* buffer is not
>> empty*/
>> rtems_interrupt_disable (level);
>> tty->rawInBuf.Head = tty->rawInBuf.Tail;
>> rtems_interrupt_enable (level);
>> }
>> break;
>> case TCOFLUSH: /* flush output buffer*/
>> {
>> if ( tty->rawOutBuf.Tail != tty->rawOutBuf.Head )/* buffer is
>> not empty*/
>> rtems_interrupt_disable (level);
>> tty->rawOutBuf.Head = tty->rawOutBuf.Tail;
>> rtems_interrupt_enable (level);
>> }
>> break;
>>
>> case TCIOFLUSH: /* flush input & output buffer*/
>> {
>> if ( tty->rawInBuf.Tail != tty->rawInBuf.Head )
>> rtems_interrupt_disable (level);
>> tty->rawInBuf.Head = tty->rawInBuf.Tail;
>> rtems_interrupt_enable (level);
>>
>> if ( tty->rawOutBuf.Tail != tty->rawOutBuf.Head )
>> rtems_interrupt_disable (level);
>> tty->rawOutBuf.Head = tty->rawOutBuf.Tail;
>> rtems_interrupt_enable (level);
>> }
>> break;
>> }
>> }
>> break;
>>
>>
>>
>> I call ioctl function with tcflush()
>>
>> int tcflush (int fd, int queue)
>> {
>> switch (queue){
>> case TCIFLUSH:
>> case TCOFLUSH:
>> case TCIOFLUSH:
>> return ioctl(fd,TCFLSH,queue);
>> break;
>> default: return -1
>> } //switch
>> }
>>
>> And I am not sure that I'm using the handler ( args->buffer )in the
>> case TCFLSH correctly
>>
>> Another problem is for the TCSBRK case.
>> Can you explain to me how can I send the break signal ?
>>
>> case TCSBRK:
>> {
>> ??
>> }
>> break;
>>
>>
>> Thanks for your help.
>>
>> Stephane
>>
>>
>>
>>> -----Message d'origine-----
>>> De : Eric Norum [mailto:norume at aps.anl.gov]
>>> Envoyé : mercredi 2 mai 2007 16:00
>>> À : Arquer Stephane
>>> Cc : rtems-users at rtems.org
>>> Objet : Re: Rtems_termios_ioctl problem
>>>
>>>
>>> 1) Why place the NUL into the buffer?
>>> 2) The raw input buffer is a ring buffer, so I don't think that your
>>> rawnc calculation is right.
>>> 3) The semaphore is being used for process synchronization, not for
>>> mutual exclusion, so obtaining and releasing it like this is
>>> incorrect.
>>>
>>>
>>> It seems to me that all that's necessary is to:
>>> rtems_interrupt_disable (level);
>>> tty->rawInBuf.Head = tty->rawInBuf.Tail;
>>> rtems_interrupt_enable (level);
>>>
>>>
>>> This will flush the 'raw' input buffer. Should something happen to
>>> the 'cooked' buffer as well?
>> I don't use it for the moment.
>>
>>>
>>> On May 2, 2007, at 7:28 AM, Arquer Stephane wrote. The comment at
>>> the top of rtems_termios_enqueue_raw_characters
>>>
>>>> Hi,
>>>>
>>>> As I wrote in my previous email, I'm still trying to modify the
>>>> file termios.c to add TCFLSH request like following:
>>>>
>>>> case TCFLSH:
>>>> {
>>>> switch (args->buffer) {
>>>> case TCIFLUSH: /* flush input buffer */
>>>> {
>>>> unsigned int head;
>>>> sc = rtems_semaphore_obtain
>>> (tty->rawInBuf.Semaphore,
>>>>
>>> RTEMS_WAIT,
>>>>
>>> RTEMS_NO_TIMEOUT);
>>>>
>>>> int rawnc = tty->rawInBuf.Tail -
>>> tty->rawInBuf.Head;
>>>> if ( rawnc < 0 )
>>>> /* buffer is not empty*/
>>>
>>>> head = tty->rawInBuf.Head;
>>>> tty->rawInBuf.Tail = head;
>>>> tty->rawInBuf.theBuf[head] = '\0';
>>>>
>>>> sc = rtems_semaphore_release
>>> (tty->rawInBuf.Semaphore);
>>>> }
>>>> break;
>>>>
>>>> I don't know if it is the correct way to flush the buffer. If
>>>> someone knows how to do it,I'm interested.
>>>>
>>>> Thanks for your help.
>>>>
>>>> Stéphane.
>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>> --
>>> Eric Norum <norume at aps.anl.gov>
>>> Advanced Photon Source
>>> Argonne National Laboratory
>>> (630) 252-4793
>>>
>>>
>>>
>
- --
- --------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at:
http://www.imd-systems.de/pgpkey_en.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGOOijwHyg4bDtfjQRAtxzAJ9mNs3s80e7e1TpUL9+8GUJAj37HwCgmNb0
4jNfljmrqMmbZ4DasYshJTc=
=m+5L
-----END PGP SIGNATURE-----
More information about the users
mailing list