[ECOS] RedBoot serial rx interrupts

Grant Edwards grante@visi.com
Sat Jan 13 15:32:00 GMT 2001

On Sat, Jan 13, 2001 at 04:13:47PM -0700, Gary Thomas wrote:

> > My Ethernet driver initialization routine ends up calling
> > cyg_drv_isr_lock() and cyg_drv_isr_unlock().  The latter
> > enables interrupts.
> Maybe we should improve this interface to return an indication
> of whether the interrupts _were_ on when "isr_lock()" was
> called to avoid this in the future.  I'll think about it.

I doubt it's worth the extra overhead.

I hacked my way around the lock/unlock-during-init issue in
another kernel by statically initializing the lock counter to
its max value and then setting it to 0 just before the
scheduler first enables interrupts.  You'd still get interrupts
enabled during init if you called ulock() a lot of times
without calling lock(), but it behaved properly for balanced
lock/unlock calls.

> > I can add #defines to my driver code to turn those into noops
> > unless CYGPKG_NET is defined.
> > 
> > This raises the question: is it OK to call those two routines
> > during network device initialization?
> It's not necessary.  Interrupts are always off during any
> system initialization, so you could just leave this out [and
> feel safe].

Right.  The situation arose because the init code called a
function that was also called by DSR and user-level code.  As
it turned out there just happened to be two versions of the
called function, one for use inside ISRs and one for "other".
Changing the init code to use the "ISR" version of the function
solved the problem.

But, to avoid future problems, I #defined a bunch of
cyg_drv_XXXX stuff to be noops when used for RedBoot.

It looks like things are working properly now (DHCP is working,
and I suspect that once I set up a TFTP server, that will

I still have to use --ignore-errors so that I can have
live with that, since my customers are going to be building
eCos apps but not RedBoot.

Thanks for the help (especially on a Saturday!)

Grant Edwards

More information about the Ecos-discuss mailing list