Discussion about allocating memory from within an irq
So I've been thinkng about this, and I think it would be possible to have some type of scratch allocator which could be used inside interrupt handlers.
The actual scratch buffer would be allocated outside of the interrupt and somehow associated with the handler.
When the handler runs it would put the registered handler on top of a list of allocators. When a memory allocation is required, it would either use the scratch allocator, or if none were present, use the heap allocator. The scrath allocator would basically just increment a pointer by the number of bytes being allocated, as long as that number of bytes still exists in the scratch buffer,
Each time the interrupt fires, it would reset the scratch buffer.
I just thought I'd throw this out as an idea.
Ctrl-C is too greedy and dangerous
This has been in the back of my mind for a while: pressing ctrl-C will break you out of anything, even if you're deep in some HAL function or allocating memory. This is very bad, since it can lead to uPy being in a completely inconsistent state, which only a soft or hard reboot will fix.
Resolution is not easy (at least, to do efficiently). Main idea is that you only want to be able to break out of executing byte code, and in that case ctrl-C "injects" an exception into the VM at it's current point of execution.
The other place where it's valid to ctrl-C is within native, viper and inline assembler code. But this might be really difficult to arrange.
Ctrl-C currently waits for all IRQs to finish before raising an exception, so one idea would be to execute byte code at lowest (IRQ) priority, and all other code at a higher priority.
Other simple idea is to put a check in the VM to see if ctrl-C was pressed, but that really degrades performance.