The drivers within this repository have been designed in an attempt to cater for all use cases that would be needed within a MCU/embedded device. Therefore, in the case of external communication, there are typically two ways that this can be managed:

'Polling' Communication	'Interrupt' Communication
When communicating with an external device the embedded device will do nothing other than check the status of the I/O, until the input has been recieved	Interrupt based, will allow the embedded device to do other functions whilst awaiting a receive event from the external device

Therefore, the functions within the repository have been named accordingly. If the function will poll for the data, then the function name begins with pole, e.g. .poleSingleRead, .poleSingleTransmit, etc.

• Yes! I understand that the wrong poll has been used within the function name - however I've used this for ALL the functions, and I don't see the point in re-naming; so please live with it :D

Interrupt function names has followed the same layout, using int at the start, e.g. .intWrtePacket, .intReadPacket, etc.

So....why am I writing this here? Well that is because the design of the polling function(s) is fairly easy, as the device is dedicated to that particular communication, however! the interrupt based communication is different. This is because once the device comes back to service the I/O it won't necessarily know what to do with the data, without some level of infrastructure around it - hence the introduction of my Form System.

Form System

What the Form System allows, is for the class to have a queuing system for data requests along a particular I/O device. The contents of this form will vary depending upon the device/driver, however the basics are:

• Pointer to were data to be transmitted/received
• Number of data points to transmit (in all cases assumed to be 8bits)
• Pointer to a completed flag (expected to be unique for each communication string)
  • This will essentially be a counter, starting at zero and will hit the number of data points to transmit
• Pointer to a fault flag (so can indicate any specific faults with communication)

How this works

1. A Driver class will need to be declared, and provided with a Form queue to use as its internal queue/memory for data requests
2. When a request is needed, it will be put onto the Driver queue, and the interrupt(s) for this driver enabled
3. Driver will then pull the request off the queue, and make it the active Form, and start retrieving the data as required
   • The Driver class will keep track for each data packet transmitted, decrementing this down to zero
   • Any faults will result in the fault being provided to the source requester
4. Once the data communication is completed (or faulted), the number of data packets communicated will be added to the source completed flag
   • Management of the source completed flag, and fault flags is to handled external to the Driver
5. At this point, the Driver will then see if there is any other requests (returning to number 3)
6. If there are no requests, the Driver will de-activate; till a new request is provided

Therefore, as the image above shows, this facilitates multiples devices communicating via the same I/O driver (i.e. I2C, or SPI). Any faults specific to that communication or device will be isolated to that device. However, any faults with the driver will obviously cause issues for all devices.

Direct Memory Access (DMA)

The design of the Form system also allows for the embedded device to make use of DMA. As all the information needed to populate a DMA interface (or at least the STM32 DMA) is contained within the Form. The only difference is how the Driver manages the interrupts. For normal interrupts, each data packet would trigger an interrupt and the embedded device would need to put the next data packet onto the HAL. The DMA handles this, and will only flag an event if there is an error, or the communication has completed.