Add support for CAN RxCallbacks

[HenrikSolver]

This patch adds support for adding callbacks to a can class that will be called when a message is received.

[pfalcon]

Here, and in other places, missing space between ')' & '{'.

[dpgeorge]

@PappaPeppar thanks! There are a few things I'll clean up and fix (like putting pyb_can_obj_all in root pointer section), but main thing is to discuss how to call the callback function.

Things like ExtInt and Timer only need one callback, when the event happens. Things like UART can have many callbacks: when data is received, when tx buffer is half empty, when tx buffer is completely empty. DAC can have callback when buffer is half empty, SPI can have callback when DMA transfer is finished. Etc.

Basically a callback is an interrupt request.

So how do we want to name the functions that set up the callbacks? Do we want to use individual names, like callback, rxcallback, txemptycallback, dmacallback, etc; or do we want one name (callback) with an argument to set the callback type? Eg can.callback('rx', lambda:...)? Could use short codes like 'txhe' for tx buf half empty. This would scale a bit better than adding many functions.

Any other ideas or comments?

[HenrikSolver]

First a short recap on the hardware capabilities in the area. The hardware supports three types of interrupts. Receive, Transmit and Error/Status information.
There are three Rx interrupts for each FIFO.

• FIFO not empty: This one we need and this is what's implemented in this pull request.
• FIFO Full.
• FIFO Overrun: At first I thought that this wasn't needed, but we would definitely want to know if packets are lost due to overruns.

There is one Tx interrupt for each bus controller.
It is triggered when a message is sent, but if there are more than one message sent between two interrupts (that can happen, there are three buffers that can hold messages to be transmitted) it is not trivial to determine which message that actually caused the interrupt. So I think that the value of a Tx interrupt might be limited. But I have code ready, I only have to add docs and tests.

There is one Error/Status interrupt for each bus controller.
The can controller collects statistics about how many faults it sees on the bus. If these numbers go over specific thresholds it generates a interrupt, this is defined in the CAN spec. This interrupt can also be triggered by specific events/state changes in the hw. I have not started on this yet.

I would like to keep these events as separate callbacks.

• One Rx callback for each FIFO with a parameter that indicates the reason as above. The motivation for one callback for each FIFO is that if you make a design decision to receive the messages in different FIFOS you probably have reason. Why should then the python bindings merge the code paths? Another thing I am thinking about is that we might want to set different priorities on the interrupts, in that case the callback code must be reentrant.
• Tx callbacks should be optional. In many cases there is no need to for a Tx callback in which case a empty interrupt is a waste of cycles.

Regarding naming: rxcallback and txcallback are obvious to me, but I guess other might have other opinions. I have not thought much about a name for the third callback, errcallback might be a candidate.

[dpgeorge]

Some style changes, put pyb_can_obj_all in global state structure, and merged in f80f1a7.