I went through a similar train of thought while porting the stm32f3 family, but then I realized I can argue both ways.
If the BSP doesn't route any of the pins of the peripheral it doesn't matter if the MCU would support it. Or you might have to use a different internal peripheral for UART_0, depending on BSP layout. But yes, it does lead to a lot of code duplication (and therefore maintenance). Maybe some master implementation of hal_bsp_init would eliminate most of it. One other thought I had was "maybe" the BSPs are mostly copies of each other because most (all) BSPs in the repository are evaluation boards and vendors typically try to use the same peripherals in all of their evaluation boards to reduce above mentioned maintenance costs. As I said, I can argue both ways... Markus On Wed, 7 Feb 2018 11:44:26 -0800 will sanfilippo <[email protected]> wrote: > Hello: > > There has been some discussion in the larger community regarding the > proper place for the MYNEWT definitions for peripheral existence. For > example, these are definitions such as I2C_0, UART_0, etc. > > In the past, these definitions were placed in hw/bsp/syscfg.yml. At > some point some of these were defined in hw/mcu/syscfg.yml. > > My vote would be to place them in the MCU as it is the MCU that > “defines” the existence of these peripherals and that duplicating > them in each bsp that points to a speciifc MCU is redundant. Of > course, the BSP can override the MCU if desired. > > Another side point: should the default definition define these > settings to be 0 or 1 by default? My vote, although I do not feel > strongly about this, would be to set them to 0 by default and let the > bsp or target set the appropriate values. My reasoning behind the bsp > actually setting them is that it is the bsp which actually “defines” > which peripherals are used (ie the particular board may not use any > SPI or I2C and thus no need to set them to 1). > > Thanks!
