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
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.