Implement asynchronous SPI interface

[salkinium]

Adds the functions as defined by the asynchronous interface in mbed-hal. Successfully tested using the asynch-spi unittest in mbed-hal.

It uses interrupts for now (3 interrupts per transferred byte).

These changes rely on https://github.com/ARMmbed/mbed-hal-st-stm32f429zi/pull/13.

@bremoran @bogdanm @0xc0170

[miklis]

Build finished. No test results found.

[miklis]

Build finished. No test results found.

[salkinium]

Also please note that I only added the asynch APIs, but did not fundamentally fix the problem inherited by the synchronous API, which are mostly related to providing safe mutual exclusion for multi-access.

Specifically, the current implementation of SPI (well, really any API of the entire HAL) is not safe for true asynchronous operation. For example, calling spi_init() after a transfer has been started with spi_master_transfer() will reset the spi master and invalidate the transfer. Similarly, interoperability between the synchronous and asynchronous API is not possible.

[0xc0170]

Also please note that I only added the asynch APIs, but did not fundamentally fix the problem inherited by the synchronous API, which are mostly related to providing safe mutual exclusion for multi-access.

No worries, we won't hunt you for that one. As noted, we are not there yet.

Can you please fix formating with these new changes, reason - consistency

[bogdanm]

It uses interrupts for now (3 interrupts per transferred byte).

Could you please ellaborate a bit on this? Why 3 interrupts?

[salkinium]

I'm still a little confused by there are 3 interrupts per byte.

I can reason for 2 interrupts per byte for TXRX transfers, because of the TxEmpty and RxNotEmpty interrupts. For TX only, I measured 1 interrupt, but for RX its also 2 interrupts, because:

@0xc0170 just now found this (undocumented) gem in the Cube library in the HAL_SPI_Receive_IT function: The Cube library actually sends the receive buffer during reception (!).

In the unittest I memset the rx buffer and therefore I saw zeros in the tx line, instead of 0xff, which is the SPI_FILL_WORD. This lead to the workaround here, where I tx one 8/16bit word 0f 0xff(ff) per received byte. I will try to memset the rxbuffer to 0xff before starting the "reception".

For the tx only part, I now believe that I prematurely disabled the interrupt here, and therefore disallowed the tx-only configuration in Cube to properly unconfigure its internal states, and therefore it just continued the previous transfer on the next transfer. This lead to this workaround, which costs 2 interrupts per byte.

[miklis]

Build finished. No test results found.

[miklis]

Build finished. No test results found.

[miklis]

Build finished. No test results found.

[miklis]

Build finished. No test results found.

[salkinium]

Ok, so I've fixed the reception, it is now much more efficient.

Interrupts per byte:

• Tx & Rx: 1
• Rx only: 1
• Tx only: 2

I still didn't find a fix for using the HAL_SPI_Transmit_IT function, so the workaround for that costs 2 interrupts per byte.

I now also "conform" to coding style.

[0xc0170]

Looks good to me.

Unknown state for HAL_SPI_Transmit_IT - Shall we leave TODO there to remind us to look at this (or even a issue), https://github.com/ARMmbed/mbed-hal-st-stm32f4/pull/15/files#diff-bc7df4243a454d3629b0f7efffec53f7R461

[miklis]

Build finished. No test results found.

[miklis]

Build finished. No test results found.

[miklis]

Build finished. No test results found.

[miklis]

Build finished. No test results found.