I think the MCU is the proper place for the definition and either bsps, apps or targets can override/set the variables.
+1 for me too. Will > On Sep 21, 2017, at 11:19 AM, Vipul Rahane <[email protected]> wrote: > > I did take a look at the discussion and it seems that moving the SPI/I2C > definitions to mcu would be the appropriate thing to do since they are all > SOC based restrictions. It is something that the BSP cannot control. > > I have tried hooking up multiple sensors but all of them were on the I2C_0 > so, it really didn’t matter. The boards that I have seen either have all SPI > sensors or all I2C sensors(could be because of the restriction on they > interfaces). I have not come across a board with a combination but that is > not a deciding factor as this could very well be application specific and > sensor specific. Most sensors give two interfaces to talk to them, SPI as > well as I2C. some cheap industrial ones provide a single interface which will > be a problem. > > so, +1 for the idea. > > Regards, > Vipul Rahane > >> On Sep 21, 2017, at 10:25 AM, Gordon Klaus <[email protected]> >> wrote: >> >> I'm bringing the conversation from >> https://github.com/apache/mynewt-core/pull/564#issuecomment-331137397 to a >> larger audience, per wes3's suggestion. >> >> The question is whether to move some syscfg definitions that are duplicated >> across many BSPs into MCUs instead. The definitions in this case are >> I2C_0, I2C_1, SPI_0_MASTER, and SPI_0_SLAVE. Their primary use seems to be >> in the MCU, where they are checked when instantiating these interfaces, but >> they are also used in the BSPs for initialization with board specific pin >> numbers. >> >> In the PR above I added a restriction between the I2C and SPI definitions >> as dictated by the nRF52. I only added it for the EE-02 board, but it >> really should be done for all nRF52 based boards. Duplication could be >> avoided by moving these definitions into the MCUs. >> >> What do you think? >
