Re: [ECOS] Separate console and debug ports?

[Grant Edwards <grante@visi.com>]

On Tue, Mar 13, 2001 at 08:25:41PM +0000, Jonathan Larmour wrote:

> > In order to avoid loosing input characters I got rid of the
> > timeouts in RedBoot's gets(), so now if there's no input on a
> > UART, it doesn't delay. It checks the next UART (or the
> > network) immediately.  I don't understand the purpose of the
> > delay after checking a UART -- my configuration works a lot
> > better without them.
> > 
> > Since nobody is calling the 1ms delay routine that updates the
> > system time, I did have to add to the main loop a call to a new
> > routine in ticks.c to advance the system by about 80us
> > everytime through the loop.  The unfortunate thing about that
> > setup is that you have to tune the "system time adjust" value
> > by hand to get a reasonably accurate system time.
> > 
> > But, ping resonse time is 1-2 ms and I never loose console
> > characters at 57.6K baud.  :)
> 
> I may well be talking out my *rse, but what about trying to
> make the timer interrupt driven rather than polled, and then
> delay_us just reads a global volatile counter?

That would work just fine.  In fact, what you described is
pretty much exactly how the bootloader in one of our other
products works: the only interrupt is a 1ms timer that does
nothing but increment a counter.  Everthing else is polled in a
main loop.

> Normally RedBoot is completely polled, but as long as you mask
> all your unused interrupt sources I don't know any reason why
> there'd be a problem. Admittedly I don't think we would want
> such a change in the master sources so this wouldn't solve the
> problem for everyone.

The reason I avoided using a timer interrupt is that I didn't
know what would happen when I started using GDB stubs to debug
an eCos app.  Both my hardware timers are used for other
purposes by eCos -- if GDB stubs need us_delay, then I can't
use any hardware timers at all (interrupt or not) in the
us_delay routine.
-- 
Grant Edwards
grante@visi.com