The HAL gpio_irq_api stores object IDs, which serve as a form of context
for the dispatch of the interrupt handler in the drivers level
InterruptIn Class. The way this is achieved is that the InterruptIn
Class casts its address to uint32_t, which is stored as the ID.
This results in compilation failure when the size of an object pointer
is greater than uint32_t, for example when building on a PC for unit
testing.
In order to allow Unit Testing of the InterruptIn Class, we replace the
use of uint32_t with uintptr_t (type capable of holding a pointer),
which allows portability and expresses intentions more clearly.
In aid of this latter goal, we also replace the use of the name "id"
with "context", to improve clarity - these are addresses of the context
related to that callback.
Modified the spi_master_block_write() function yet again. SD related examples still read/erase/write the SD cards as expected and with these alterations the power consumption does not remain high after the SPI transaction has been finished. However i still only tested the SD functionality. Please test other SPI scenarios and different sensors as well to find out if this PR introduces unexpected bugs or not.
Changes:
- deleted the whole if (xfer.ui32NumBytes) condition as i did not find it logical (by that i mean xfer.ui32NumBytes was also true within the following else if (tx_length != rx_length){} block, so basically when the 2 buffers had different lengths an extra transfer has been done for nothing)
- removed the bool Rw = (rx_length >= tx_length) as the comparison >= has no sense anymore after if (tx_length == rx_length) on line 159.
Modified line 145: previously the fill character has been hard coded to 0x00. However in Mbed OS core SPI_FILL_CHAR is defined in the core to be 0xFF by default (one can change that through mbed_app.json for example). This mod allows us to use the same fill character that is defined for Mbed OS.
Also modified spi_master_block_write(): previously it called am_hal_iom_blocking_transfer on line 182, but that prevented succesful SD card writing operations. Now i changed that part to am_hal_iom_spi_blocking_fullduplex and SD functionality seems to be working.
YahyaTawil
Hari Limaye
Martin Kojtal
kalle16lab
Kalle-Gustav Kruus
Peter B
Wenn0101