Library coexistance

22 Nov 2010

 

Are the libraries offered by mbed's baseline implemented such that they don't have problems with interactions, such as

- disable interrupts for more than few tens of microseconds?

- coordinate global assignments like interrupt vector slots?

 

and so on.

22 Nov 2010 . Edited: 22 Nov 2010

Hi Steve,

In general, yes this will work; so for your examples:

- disable interrupts for more than a few microseconds

Interrupts will still pend, so when you re-enable them any outstanding interrupts will be handled. Things like the Ticker/Timeout are obviously trying to fire at a specific time, and handling will be delayed if you disable interrupts. But as an example, the repeat time of a Ticker is determined by an absolute  running clock, not relative to the last time it was handled, so even if some get delayed you'll still get the right number of events.

- coordinate global assignments like vector slots

You can assign to the interrupt vector slots if you'd like (either statically or dynamically). The mbed libraries will only register those it needs. One thing to be aware of is the GPIO interrupts, which all share the same vector, so you can't mix and match mbed and your own there. I will look at allowing some form of fallthrough so, for example, a number of handlers could share the same slot, falling through if one doesn't handle it. But for now, one thing is assumed to own each slot.

The things which the mbed library currently does assume are:

  • It has control of TIMER3 (used for a 1us rolling timer)
  • The clock/PLL setup doesn't change (so it doesn't have to cope with changing PCLK frequencies for peripherals that are already set up)

It basically comes down to whether things are trying to get ownership of the same underlying mcu resource, so in the common case it is fine.

Simon

22 Nov 2010

Steve,

I little more info here:- http://mbed.org/forum/bugs-suggestions/topic/1130/

Basically, as shown, if you "do your own thing with interrupt vectors" then do Mbed libs first and then in your own code chain along the vectors. At the moment, Mbed libs expect to own an irq vector so if you alter one and then invoke an Mbed lib that needs it, your handler won't get called. As Simon noted, I think it's on their "to do" list to add chaining or some other mechanism to manage it.

--Andy

22 Nov 2010 . Edited: 22 Nov 2010

I should read before asking, but... are global things like interrupt vector slots managed with some library routine that dispenses unused slots on request, rather than having slot numbers hard coded at design-time? (my app would need to know which slots are unused, at run-time ? )

From the above, I understand that TIMER3 is owned. And the PLL is fixed and the crystal freq. is as well. That's fine.

UART transmit FIFO - is it used so that the interrupt rate can be 1/16th the character rate?
Is the UART receive FIFO thresholding used so that this interrupt rate can also be reduced? These are important with 115200 kBaud's character times.

What about the Ethernet interface: Are its interrupt vectors also allocated at run-time?