As you may or may not know, I've written a demo using an external ADC Sensor on the NRF52dk board. Since the Nordic stuff had to be moved out to an external repository, I nee do move the code that I had originally added to the -core repository out as well to comply with licensing, etc. It's also been an exercise in learning how to use the HAL/BSP stuff so that I can write a tutorial on that too.
I've been conversing with another mynewt developer off-list, but I think it's time to bring it out in public and see if I can get going again. If anyone can shed light on any of this I'd be very grateful! dg > >> On Dec 16, 2016, at 8:01 AM, David G. Simmons <santa...@mac.com >> <mailto:santa...@mac.com>> wrote: >> >> Ok, I'm finally back to this ... >> >> I think the majority of my confusion here is that there are HAL and BSP >> directories in various places, and I can't quite figure out where to jump >> in. >> > Yes, it can get confusing for sure :-) > >> Can you comment on whether or not I'm moving in the right direction here? >> >> there's hw/bsp/nrf52dk/include/bsp -- I'm guessing I'd have to define the >> ADC Pin here in bsp.h? >> >> I've already added >> #if MYNEWT_VAL(ADC_0) >> rc = os_dev_create((struct os_dev *) &os_bsp_adc0, "adc0", >> OS_DEV_INIT_KERNEL, OS_DEV_INIT_PRIO_DEFAULT, >> nrf52_adc_dev_init, &os_bsp_adc0_config); >> assert(rc == 0); >> #endif >> } >> to hal_bsp.c and I believe that stays there. >> > I think the way things are moving with this is that pin definitions are > configured in structures in hal_bsp.c. There was a time that pins were > defined in syscfg.yml but it seems the community has decided that pins should > be set in structures defined in hal_bsp.c. For example, look at hal_bsp.c for > the nrf51dk and how SPI pins are defined. > >> I believe that the hw/bsp/nrf52dk/syscfg.yml addition of >> >> ADC_0: >> description: 'TBD' >> value: 1 >> ADC_0_RESOLUTION: >> description: 'TBD' >> value: 'SAADC_CONFIG_RESOLUTION' >> ADC_0_OVERSAMPLE: >> description: 'TBD' >> value: 'SAADC_CONFIG_OVERSAMPLE' >> ADC_0_INTERRUPT_PRIORITY: >> description: 'TBD' >> value: 'SAADC_CONFIG_IRQ_PRIORITY' >> >> is also correct. But I might have to move this to my new LLS Driver >> syscfg.yml since it references SAADC_CONFIG_IRQ_PRIORITY which is in the >> Nordic licensed code. > The BSP code that you are modifying with this would exist in the nordic > directory right? This is one of the items that needs to be addressed in the > code. There is a Jira ticket that I think is related if not directly about > this subject; I cannot quite recall even though I added the Jira ticket! :-) > The only piece of this that should be defined in syscfg.yml in the BSP is > ADC_0. The rest of these items would be related to pin definitions and are > either set in a structure in the bsp or set through some driver API. For > example, I think resolution is a generic driver configuration. I think the > general idea was this: there are chip specific configurations that get set in > hal_bsp.c. There are “generic driver” configuration that get set through the > ADC driver API. Of course, the generic configuration eventually need to call > into a bsp or SDK call. > > This is the “tricky” part of the code changes and I would need to spend a bit > of time on this myself to reconcile all this. > > Sorry I am not being the most helpful. If this still does not make sense I > can spend a bit more time on it. The problem is, I am not 100% sure about all > this. > >> >> I believe I'll also have to add an adc_nrf52dk.h to hw/drivers/adc/adc_nrf52 >> > This I am not sure of… > >> At present there is no hal_adc.h in hw/hal/include/hal where there is a >> hal_spi.h, etc. so I'm going to assume I need to add one, and this would >> just be basic stubs for the ADC calls. >> >> That's where I lose the plot ... >> > There is no hal for ADC and there is no expectation of doing one. I guess one > could be added, but I think there was a discussion a ways back regarding the > ADC and that coming up with a generic HAL for them, as they can be quite > different, was not something we wanted to tackle. Thus, I would not add an > ADC. This could be a good topic for the dev list too. > -- David G. Simmons (919) 534-5099 Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs> /** Message digitally signed for security and authenticity. * If you cannot read the PGP.sig attachment, please go to * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!! * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/> **/ ♺ This email uses 100% recycled electrons. Don't blow it by printing! There are only 2 hard things in computer science: Cache invalidation, naming things, and off-by-one errors.
