Probably the most significant change for Teensy3 as a development platform is using the ARM nested interrupt priorities. Previously, all interrupts ran at level 0, which is the highest non-fault priority (lower numbers are higher priority). So except for faults, interrupts couldn't interrupt each other.
Now all the interrupts default to priority 128. The chip supports 16 different prorities: 0,16,32,48,64,80,96,112,128,144,160,176,192,208,224,240. When ordinary non-interrupt code is running, it's effectively priority level 256. You can configure what priority an interrupt uses with NVIC_SET_PRIORITY(irqnum, priority). Currently, the USB and hardware serial increase their priority. Most interrupts will probably be fine with the defaults.
I'm curious if anyone has any feedback about this priority scheme, and especially how it relates to Arduino and the commonly used libraries? For example, libraries like Servo that are really sensitive to latency from other libraries probably want higher priority.
Another significant change, which is somewhat experimental, is in Serial1. Inside Serial1.write(), which is called by Serial1.print(), it now checks to see if interrupts are blocked (by looking at priority levels). Normally, this would cause Serial.print() to never return if you try to print more than fits into the transmit buffer. Anybody who's worked on interrupts know you normally need to be careful what you do inside interrupt code. But my goal is to make Serial1 (and eventually much more) "just work", even when used inside an interrupt. So if Serial1 detects the interrupt is blocked while it's waiting for space in the transmit buffer, it will revert to polling the hardware and transmitting the data while the interrupt can't run. Of course, Serial1.print() can't return until the remainder of the data it wants to transmit can fit into the buffer, but that's a lot better than it never returning at all. My goal is to eventually make as much as possible "just work" in as many situations as I can. This is just the start, and before I try extending this to USB virtual serial and other things, I'm hoping for some feedback about how well it works (or doesn't work)? Or even any theoretical arguments about deadlocks, thread safety, etc.
I also changed the default fault handler so the USB and serial ports are polled while in fault mode. This hasn't been tested much, but it does allow the Upload button to auto-reboot Teensy3 when it's stuck it the fault handler. For normal Arduino programming, faults should be very rare, but if you've ever fiddled with accessing hardware directly, it's pretty easy to get a fault condition if you read or write registers on disabled peripherals or make other mistakes. Not having to physically press the button is always nice.
It's perfectly fine to discuss these changes here (even through it's the announcement forum). I'm really curious to hear any thoughts or feedback, especially about the use of priority levels and ways to make more Arduino functionality interrupt safe?
