This arrived today with b3be6f034169efaa53511b9da0905c4bba014608 and I updated both my nrf51 version of davids adc driver and my battery service. I think its pretty clean and 'newty' Again, any code review welcome, and if you think any of it fits in core I can PR
https://github.com/jacobrosenthal/mynewt-nrf51-adc-driver https://github.com/jacobrosenthal/mynewt-nimble-services/ tree/master/services/battery Thanks all! On Mon, Feb 20, 2017 at 10:19 PM, Sterling Hughes < sterling.hughes.pub...@gmail.com> wrote: > Hi Jacob, > > This is awesome. > > On 20 Feb 2017, at 14:35, Jacob Rosenthal wrote: > > Thanks again David for your example. Ive taken liberally from there and put >> together what seems like a working nrf51 driver. Any input accepted. >> https://github.com/jacobrosenthal/mynewt-nrf51-adc-driver >> >> and used it in a ble battery service, again any input happily accepted. >> https://github.com/jacobrosenthal/mynewt-nimble-services/ >> tree/master/services/battery >> >> Mynewt folks, >> >> In the spirit of the driver model, It seems like I should be be able to >> use >> the os_dev_lookup function so both the adc driver and the battery service >> can use the pkg.init functions so I dont have to do: >> >> adc = adc_nrf51_driver_init(); >> rc = ble_svc_battery_init(adc); >> >> But instead can pass the adc name "adc0" via mynewt variable, however >> os_dev_lookup isnt in the header. Any objection to exposing that? >> >> > No problem with me, I have found this to be something that I have wanted > in a number of cases. I’ve gotten around it by exposing and referencing a > global variable, but the function should work. > > I think I was worried about locking constraints and exposing them when I > originally made it private. We should put an admonition in the comments > that we don’t expect this to be locked, so caveat emptor. > > I’d like to get this in prior to 1.0-rel if folks are OK with it. It is a > low-risk change to expose an existing function in a header file. > > Sterling >