Thank you Chris for taking the time to share the intentions, the rationale and presenting all the options- It all makes sense to me.
As you said the LED issue is specific to the board, to the way the LED is wired and is independent to the specific application so I will just add the LED_BLINK_OFF and LED_BLINK_ON definitions in my hal_bsp.h file for both BSPs. so that any of future apps can benefit. It also increases readability of the code- The pin choice is just an ad-hoc thing specific to the prototyping I am doing so it belongs to the target in my mind. I will create a new syscfg variable and will override at target level. Thank you again. You guys are great Ugo On Wed, Jun 14, 2017, at 08:42 PM, will sanfilippo wrote: > Ugo: > > Just as a preface, BSPs are intended to be examples of how one could > create a BSP for their own system. It was assumed/expected that folks > would take these BSPs and modify them for their own use. Well, at least I > thought so anyway. Another decision we made in the BSP and one that we > have changed over time and is still not terribly consistent is how GPIO > are defined in the BSP. We moved away from syscfg variables so that you > cannot easily override them in your target; you need to modify the code > in the BSP itself. That may not have been the wisest choice but "it is > what it is" as we say here in the states. Of course, you can modify the > code if you desire. Now, on to your issues: > > Issue number 1: > > Funny you mention this. I always thought that they way we did this is a > bit odd regarding the 0, 1 for turning on/off the LED. Depending on how > the LED is wired, setting the GPIO to 0 or 1 will do the opposite thing. > It would probably be better to have done something like this: > > LED_BLINK_OFF (0) > LED_BLINK_ON (1) > > These states would then be defined for each BSP and it would do the right > thing based on the particular setup that you have. > > Issue number 2: > There are different ways to do this but you could simply modify your BSPs > and set up the pins you want in the BSP. I do understand that you now > have a different BSP than the one in the repo. You could also do > something with a conditional directive or you could create syscfg > variables or define some of this in the target. I realize that I am not > being very explicit; I just do not know the best way to accomplish what > you want. > > Hope this helps and I am not confusing things further :-) > > > > On Jun 14, 2017, at 11:02 AM, Ugo Mastracchio <mastr...@fastmail.co.uk> > > wrote: > > > > Thank you so much Chris and Will for your notes. > > > > Let me specify my case. > > There are actually 2 different scenarios that I need to address. > > > > BACKGROUND: I have developed (or should I say Will has and I have > > subsequently hacked it) an app that runs on 2 NRF52-based BSPs, namely > > NRF52DK and RBN2 and that exhibits same behaviour on both. > > > > ISSUE ǸUMBER 1 > > > > Both boards has one LED on the board and both BSPs define LED_BLINK_PIN. > > > > But the issue is the following code would turn on the led on NRF52DK and > > will turn it off on RBN2 ! > > > > g_led_pin = LED_BLINK_PIN; > > hal_gpio_init_out(g_led_pin, 0); > > > > > > ISSUE NUMBER 2 > > > > For practical wiring reasons I want to enable different GPIO input PINS > > on the 2 BSPs > > > > Looking forward to your comments. > > > > Ciao > > Ugo > > > > > > On Wed, Jun 14, 2017, at 07:12 PM, Christopher Collins wrote: > >> On Wed, Jun 14, 2017 at 04:22:52PM +0200, Ugo Mastracchio wrote: > >>> Hello everyone, may I throw an absolute beginner's question ? > >>> > >>> How do I conditionally compile based on the BSP the target is > >>> associated with ?I want to use different GPIO pins depending on the > >>> board.... > >>> > >>> Is there a system configuration setting valued with the BSP name ? > >> > >> After writing my previous response, I am thinking I may have > >> misunderstood the question. Generally, the PIN mappings are defined in > >> the BSP package itself, so there should be no need to remap pins based > >> on the BSP being used. Are you perhaps trying to use the same BSP > >> package for two slightly different boards? > >> > >> If this is what you want to do, you may want to take a look at how the > >> arduino_zero BSP handles this. The 1) arduino zero and 2) arduino zero > >> pro hardware is very similar. I believe the only difference are a few > >> GPIO mappings. Rather than create a separate BSP for each board, the > >> arduino BSP package code uses conditional compilation. > >> > >> Within the arduino repo > >> (https://github.com/runtimeco/mynewt_arduino_zero), the arduino_zero BSP > >> defines these settings: > >> > >> BSP_ARDUINO_ZERO: > >> description: 'TBD' > >> value: 0 > >> restrictions: > >> - "!BSP_ARDUINO_ZERO_PRO" > >> > >> BSP_ARDUINO_ZERO_PRO: > >> description: 'TBD' > >> value: 0 > >> restrictions: > >> - "!BSP_ARDUINO_ZERO" > >> > >> Then, in hw/bsp/arduino_zero/include/bsp/bsp.h, pins are mapped as > >> follows: > >> > >> #if MYNEWT_VAL(BSP_ARDUINO_ZERO_PRO) > >> ARDUINO_ZERO_D2 = (8), > >> ARDUINO_ZERO_D4 = (14), > >> #endif > >> > >> #if MYNEWT_VAL(BSP_ARDUINO_ZERO) > >> ARDUINO_ZERO_D2 = (14), > >> ARDUINO_ZERO_D4 = (8), > >> #endif > >> > >> It is up to the target package to define one (and only one) of > >> BSP_ARDUINO_ZERO_PRO or BSP_ARDUINO_ZERO. > >> > >> This approach is nice because it eliminates the need for a lot of > >> duplicate code in a second BSP package. One hassle involved is the > >> necessity to define the appropriate syscfg setting in the target > >> package. > >> > >> Chris > > > > > > -- > > Ugo Mastracchio, > > mastr...@fastmail.co.uk > > Telefono: +39 > > 03631806106[https://www.fastmail.fm/mail/Inbox/090d6d955e843818-f9048467u8138?u=53b641b7#] > > > > Cellulare: +39 > > 3484116043[https://www.fastmail.fm/mail/Inbox/090d6d955e843818-f9048467u8138?u=53b641b7#] > -- Ugo Mastracchio, mastr...@fastmail.co.uk Telefono: +39 03631806106[https://www.fastmail.fm/mail/Inbox/090d6d955e843818-f9048467u8138?u=53b641b7#] Cellulare: +39 3484116043[https://www.fastmail.fm/mail/Inbox/090d6d955e843818-f9048467u8138?u=53b641b7#]
