Interrupts¶

Der Overhead soll moeglichst gering gehalten werden.
Daher werden nur Informationen fuer Peripheri-Interrupts gehalten, die auch verwendet werden.
Dynamische Arrays fuer Interrupt-Objekte gibt es nicht mehr sondern nur einzelne Pointer auf verwendete
Interrupt-Objekte. Durch das explizite Aktivieren von ISRs werden nicht benutzte Pointer durch den Linker eliminiert.
Der fuer eine Peripherie verwendete Interrupt-Objekt-Pointer kann in der Config-Struktur angegeben sein.
Eine Interrupt-Klasse ist nicht notwendig.

Beispiel:

CUart *interruptUart1=nullptr;
CUart *interruptUart2=nullptr;

INTERRUPT_IMPL(UART2)
{
   callInterrupt(uart2);
};

CUart::interrupt()
{
   HAL_UART_INTERRUPT( m_pHandler );
}

SUartConfig configBlockUart2
{
   .interrupt=interruptUart2,
};

Callbacks¶

The callback functions called via HAL unfortunately do not provide an way to deliver an user data, e.g. an pointer to the uart object.
So the object has to be determined in the callback function. But we dont want pointers for all unused periphery. Only the used objects
should have an pointer.
So the pointers are put into a special section. The compiler/linker can eliminate unused pointers as they are not referenced anywhere
like it would be when they appear in the config structure of the periphery.
With the help of a additional biwak linker script, the callback function can find the object pointer.

Input interrupts¶

An EXTI object has an virtual interrupt() method. As long as you just inherit from CInput, you can just implement your own interrupt(),
like CButton does.
When the application is more complex, the CInput-object may already exist. In that case there is the signal "interruptSignal". Connect it
to an method of your application class and do whatever has to be done there.

Another possibility is to hook an input decoder (CInputDecoder). This approach is meant for fast input bursts like single wire sensors or
infrared remotes.