:-)
Definitely the battery service. Unfortunately we can’t accept the
nrf51-adc-driver, yet. The Nordic SDK drivers it relies on are not
(yet) BSD licensed. I believe that Nordic was looking into this.
We’d be happy to merge it into the runtime repository where we’re
keeping the non-BSD nordic stuff:
https://github.com/runtimeinc/mynewt_nordic
The hope is to merge the repo into core once Nordic relicenses their
SDK.
Sterling
On 28 Feb 2017, at 20:03, Jacob Rosenthal wrote:
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
