There is an easy way to prevent this as well which should be added to
syscfg.yml. The following works:
SPI_0_MASTER:
description: 'SPI 0 master'
value: 1
restrictions:
- "!SPI_0_SLAVE"
SPI_0_SLAVE:
description: 'SPI 0 slave'
value: 1
restrictions:
- "!SPI_0_MASTER"
The newt tool generates a nice error message:
Error: Syscfg restriction violations detected:
SPI_0_MASTER=1 requires SPI_0_SLAVE not be set, but SPI_0_SLAVE=1
SPI_0_SLAVE=1 requires SPI_0_MASTER not be set, but SPI_0_MASTER=1
Setting history (newest -> oldest):
SPI_0_MASTER: [hw/bsp/nrf52dk:1]
SPI_0_SLAVE: [hw/bsp/nrf52dk:1]
> 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
>
