Re: [ECOS] hal_diag serial driver: using XON/XOFF flow control?

[Heiko Panther <hpanther at mac dot com>]

> > my hal_diag.c serial driver is all set up to handle incoming
> > XON/XOFF messages, that is, it has an ISR and handles the incoming
> > interrupts by reading a char. I'm using the hal_diag driver to do my
> > debug logging, so I have /dev/haldiag and /dev/ttydiag on top of
> > it. As I get it, these are associated with the serial channel from
> > serial.c which provides for the flow control.
> >
> > Now the problem seems to be that the HAL doesn't send characters
> > that come in on interrupt to the serial driver. It just checks for
> > CTRL-C and that's it. So that would mean I have to do polling (by
> > issuing read's to the serial port) in order to get flow control for
> > outgoing data. It also means that characters are lost which are
> > received on interrupt.
> >
> > Am I overlooking something? If not, I would like to implement
> > XON/XOFF for the HAL diag driver. Looks like getting the received
> > character to the serial driver needs some architectural change in
> > the common HAL. Am I better off with reimplementing flow control
> > inside the hal diag driver? What do you suggest?
>
>
>
> The HAL serial support is intended solely for polled IO in RedBoot and
> for diagnostic output. If you want to have an interrupt driven, flow
> controlled serial device then implement a proper device driver, don't
> try to hack the HAL driver. There is plenty of documentation on how to
> do this and there are plenty of example in the source repository.

Hm, it might be hacking while it's not officially supported by the common HAL. Still, /dev/haldiag is a proper device driver, only that it relies on the HAL routines. Do you suggest copying the HAL routines into another serial device driver?

I also get your point that the HAL driver should be as simple as possible. However, many HAL drivers already contain ISR support for CTRLC interrupts.

It looks to me as if there is a generally unused field in the call to the hal_diag ISR, a CYG_ADDRWORD __data. This could be used to pass a pointer to return the received char. hal_if.c:hal_ctrlc_isr() could then call the serial channel's rcv_char() to add the char to the channel's buffer.

So I see 3 minor additions: the platform HAL puts the received char into the space provided, the common HAL probably needs a hook for a serial driver to register for interrupt chars, and hal_ctrlc_isr needs to call a registered serial driver. Do you really think that would add too much complexity?

Heiko


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss