You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discovered in #226 , many Mbed devices still don't implement the spi_get_peripheral_name() API or define the DEVICE_SPI_COUNT define that signals its existence. It was originally intended as an optional upgrade to SPI HAL API that allowed HALs to indicate which SPI peripherals could be used simultaneously. "Optional" here meaning "we don't have to update all the HALs right away." However, it seems like many HALs never received this upgrade, meaning that SPI behaves unexpectedly -- the SPI class thinks every hardware SPI is the same peripheral, so it does a lot more mutex locking and re-initializing than is strictly needed, which can sometimes even cause glitches on the SPI lines.
We need something that will show us which HALs still need the upgrade and point contributors in the right direction. I think that a good way to do this would be with a test case in the new test system which fails if DEVICE_SPI_COUNT is not defined. Since tests are allowed to fail when newly added, this will not cause CI failures, but it will cause a big red mark that shows maintainers that there is a problem. Then, someday, once every device is updated, we can make this function mandatory for build.
The text was updated successfully, but these errors were encountered:
As discovered in #226 , many Mbed devices still don't implement the spi_get_peripheral_name() API or define the DEVICE_SPI_COUNT define that signals its existence. It was originally intended as an optional upgrade to SPI HAL API that allowed HALs to indicate which SPI peripherals could be used simultaneously. "Optional" here meaning "we don't have to update all the HALs right away." However, it seems like many HALs never received this upgrade, meaning that SPI behaves unexpectedly -- the SPI class thinks every hardware SPI is the same peripheral, so it does a lot more mutex locking and re-initializing than is strictly needed, which can sometimes even cause glitches on the SPI lines.
We need something that will show us which HALs still need the upgrade and point contributors in the right direction. I think that a good way to do this would be with a test case in the new test system which fails if DEVICE_SPI_COUNT is not defined. Since tests are allowed to fail when newly added, this will not cause CI failures, but it will cause a big red mark that shows maintainers that there is a problem. Then, someday, once every device is updated, we can make this function mandatory for build.
The text was updated successfully, but these errors were encountered: