Well, I certainly think more could be done here to make sure if someone did that things would just #error out. However, if both SPI_0_SLAVE and SPI_0_MASTER were set to #1, the second init should fail as that resource has already been acquired. Still, probably better to have a #error instead of an assert.
> On Nov 16, 2016, at 5:19 PM, Kevin Townsend <[email protected]> wrote: > > I'm just starting to look at the SPI HAL to implement a test driver, but > looking through the hal_spi code I see what might be a conflict. > > In the master branch of apache-mynewt-core the nRF52SK BSP has both SPI0 and > SPIS0 enabled: > > * > https://github.com/apache/incubator-mynewt-core/blob/master/hw/bsp/nrf52dk/include/bsp/nrf_drv_config.h#L211 > * > https://github.com/apache/incubator-mynewt-core/blob/master/hw/bsp/nrf52dk/include/bsp/nrf_drv_config.h#L252 > > Won't this lead to a situation where the hal_bsp_init function will always > initialize in slave mode, when end users might be expecting master mode if > they don't read the code carefully: > https://github.com/apache/incubator-mynewt-core/blob/master/hw/bsp/nrf52dk/src/hal_bsp.c#L217 > > Perhaps these should be exclusive and an #error is raised if both master and > slave are enabled on the same bus (which would also apply for I2C)? > > The two options don't seem to be possible at the same time since there are > separate init functions in the MCU HAL SPI code: > https://github.com/apache/incubator-mynewt-core/blob/master/hw/mcu/nordic/nrf52xxx/src/hal_spi.c#L620 > ... and the pins will have to be configured in different directions (SCK > will be input in one mode and output in the other, etc.). > > Kevin >
