Hey Chris, your description matches what I see in the code.
While working on the STM32F3 port I was using that port for a sample application to get ppl started on controlling their robots with an Android device. And I noticed that depending on which part I was working on (STM32F3 port, bsp or app) I changed my mind - or better my perspective. What I came up with was this (sticking with the uart example): -) the device name (eg "uart0") belongs to the application. As an application developer, if the board supports at least on serial port it will be named "uart0". If there are 2 serial ports they will be available as "uart0" and "uart1" .... This is the same as on a desktop or notebook computer, the device numbering starts at "0" and increments with each available device. -) the sycfg name (eg "UART_0") belongs to the BSP - and doesn't necessarily have a relationship to the device of a /similar/ name (aka the same number). The reason I ended up here is because the board I was using has one HW uart connected to the USB bridge. It seems that most (all?) bsps use "UART_0" for this connection - and so did I. When I was at the point to switch from the test setup to use the UART which was connected to the BT module I didn't want to change the application and realised that the BSP can declare multiple devices and one can use syscfg to select the one uart that matches the app - assuming that whichever one of the two uarts is enabled shows up as "uart0". This setup allows the BSP to support a lot of devices/device configurations without any ill consequences on memory footprint and code size (unless all of those device are actually enabled). But again, the numbering should start at 0 and increase by 1 for each additional device. Given the discussion a few weeks ago about moving the device declarations into the mcu, this should probably move there and only leave the device creation depending on the syscfg values in the BSP. Haven't figured out how that should look like though - not there yet. -) the mcu HW peripheral name belongs to the mcu and I don't think there is any value in correlating that to any of the numbers above. For quite a few mcus it wouldn't even be possible because the mcy peripheral numbering starts at `1` whereas all mynewt devices start at `0`. Not the most important topic to think about, I just wanted to make sure I'm not violating some sacred standard. Thanks a bunch, Markus On Wed, 28 Feb 2018 11:36:35 -0800 Christopher Collins <ch...@runtime.io> wrote: > Hi Markus, > > On Mon, Feb 26, 2018 at 11:36:41AM -0800, markus wrote: > > Is there some documentation about the numbers, meanings and > > relationship (if any) of the 3 different device numbers? > > > > -) syscfg, eg UART_0 > > -) device name, eg "uart0" > > -) mcu HW device, eg "USART2" > > The short answer is: unfortunately no, there isn't any documentation > about how devices should be numbered. I think the device numbering > scheme is something that evolved without any concrete plan, so a > conversation might be a good idea. > > For the first two (syscfg and os_dev name): these should always > correspond to the same device. I.e., `UART_0` syscfg settings should > configure the device called "uart0". > > The third item (name that the MCU datasheet assigned to a peripheral) > is not so straightforward. I think there is some tension due to two > conflicting goals: > 1. Make setting names consistent with names in MCU documentation. > 2. Make setting names consistent among all BSPs. > > The second goal seems to have won out over the first. The reason the > second goal is important is that it allows for BSP-agnostic libraries > and apps. For example, a library that requires a UART can be > configured to use a UART number without worrying about whether the MCU > documentation calls the device "UART 0" or "USART 0". > > If you have any thoughts on how this could be improved, please don't > hesitate to share them. The same goes for other readers! > > Chris
