[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Rtems_termios_ioctl problem



-----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-----