This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Handling RTS with an UART that doesn't directly drives the RTS pin



On 12/06/12 17:55, Bernard Fouché wrote:
>
> 
> RTS is the real problem: only serial.c knows when it's time to change 
> the pin state because it's related to the use of the RX buffer, which is 
> visible only to serial.c (please correct me if I'm wrong!). AFAIK there 
> is nothing making the RX throttling information to reach higher levels 
> since these higher levels are unaware of the buffering details underneath.

You are right. I was thinking, without looking too closely at the code,
that it might be possible to slip another drive in under the serial
driver. But obviously that is not possible.

But there is still a way to do something similar, I think. In the
board-specific serial configuration package instead of passing
pc_serial_funs to the SERIAL_CHANNEL() macro, pass your own serial
functions structure. Most of the entries can just call straight through
pc_serial_funs to the 16x5x functions, but the set_config entry can be
your function which handles GPIO flow control and calls
pc_serial_funs.set_config() for the rest.

This way all the generic code stays unchanged, and the board-specific
parts are isolated in a board-specific package.

> 
> Another solution would be to add config keys to get/set the pointers of 
> the low level functions of a serial channel which are exposed by a 
> hardware driver and then one could insert any kind of middle level 
> driver (like hooks): this would be more comfortable in the long run, it 
> could help for debug or statistics. The xxx_serial_channelN definition 
> ends in .data so I guess this is possible.

I think if you do what I suggest above you wouldn't need to do this.
Also the serial function tables ought to be declared const and thus be
in read-only memory. At present they are not, but in the future this
might change. These tables should be treated as read-only.



-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]