I will go ahead with it, then. On Fri, Sep 22, 2017 at 6:39 PM, will sanfilippo <[email protected]> wrote:
> 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? > > > >
