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? On Fri, Feb 17, 2017 at 5:27 PM, aditi hilbert <ad...@runtime.io> wrote: > > > On Feb 17, 2017, at 3:47 PM, Jacob Rosenthal <jakerosent...@gmail.com> > wrote: > > > > OK.. nevermind. Im just pasting code in all the wrong places and > confusing > > myself. I > > > > Thoughts on hosting myadc package on github to keep the user from having > to > > generate those files? Then you're just editing the main.c of bleprph for > > the task. > > > > I do think a name change to nrf52_water or something instead of my_adc > > would start me down a better path. > > > I agree. I think the tutorial would be better with that too. > > > > also there is a missing include in main.c > > > > #include "myadc/myadc.h" > > #include <adc/adc.h> > > > > thanks for catching this! > > aditi > > > Sorry for the noise. Thanks for the example! I think I can figure out how > > to alter this into an nrf51 version now. > > > > > > > > On Fri, Feb 17, 2017 at 4:15 PM, Jacob Rosenthal < > jakerosent...@gmail.com> > > wrote: > > > >> OK no wait I think Im understanding.. It IS using the nrf52 driver and > not > >> duplicating.. > >> > >> Because of the driver style abstraction my_adc is an 'nrf52 water level > >> driver(sensor?)' (maybe a name change?) > >> > >> I guess I have issue with exposing a bunch of board specific stuff into > to > >> the main.c. Though maybe this is a tutorial and we shouldnt burden a > reader > >> with perfect abstraction.. > >> > >> But wed would need a separate nrf51 water level 'driver' package, but > then > >> wed be changing all that main.c code, hence why Im confused why all that > >> nordic code doesnt live inside the nice my_adc package you created. > >> > >> Then Ideally these water level packages would expose a general init and > >> callback for water level event received so you could keep that nrf code > out > >> of the main and switch between them? > >> > >> Can anyone comment how the 'sensors' api would play into something like > >> this? > >> > >> On Fri, Feb 17, 2017 at 3:36 PM, Jacob Rosenthal < > jakerosent...@gmail.com> > >> wrote: > >> > >>> David, some questions about your recent adc tutorial. > >>> > >>> First off, thanks for pushing code for me to think about and learn > about > >>> the newt stack from > >>> > >>> It seems like your tutorial is more about writing a NEW adc driver > rather > >>> than utilizing the existing mynewt-nordic driver. For me anyway, a > tutorial > >>> duplicating the mynewt-nordic work pushing all the adc handlers pretty > high > >>> level into the main.c instead of keeping it inside the driver like the > >>> mynewt-nordic version was very confusing to me. > >>> > >>> In fact Im not sure why you're including - "@mynewt-nordic/hw/drivers/ > adc/adc_nrf52" > >>> at all, except for presumably utilizing the sdk it has inside it, and > that > >>> wasnt clear to me at all in the tutorial. Perhaps you could drop that > >>> dependency and talk about brining in copies of necessary SDK files? > >>> > >>> Im not 100% on all this, still trying to get an nrf51 version utilizing > >>> the mynewt-nordic driver up. > >>> Apologies if Im off base. > >>> > >>> --Jacob > >>> > >>> > >>> > >>> > >>> On Mon, Feb 13, 2017 at 6:52 AM, David G. Simmons <santa...@mac.com> > >>> wrote: > >>> > >>>> To answer my own question, yes, I am correct in assuming that! I just > >>>> had to keep moving the wire from pin to pin until I found the one > that ADC0 > >>>> referenced, but the same driver for the ADC that worked on the NRF52DK > >>>> board works just fine on the Arduino Primo. I'll be writing up a blog > post > >>>> about that shortly. > >>>> > >>>> dg > >>>> > >>>> On Feb 10, 2017, at 9:25 AM, David G. Simmons <santa...@mac.com> > wrote: > >>>> > >>>> Am I correct in assuming that the requisite libraries for the ADC on > the > >>>> Arduino Primo are not included yet? Since the Arduino Primo is based > on the > >>>> NRF52, would it be possible to simply modify the NRF52 ADC files to > apply > >>>> them to the Arduino Primo? If so, does anyone have a valid schematic > for > >>>> the Arduino Primo in order to determine the pin mappings? > >>>> > >>>> I'd like to get the ADC App I wrote and the air_quality app running on > >>>> the same board at the same time in order to have a board that reads > >>>> multiple sensors simultaneously. > >>>> > >>>> > >>>> -- > >>>> 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/ Secure your email!!! > >>>> * Public key available at 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. > >>>> > >>>> > >>>> > >>> > >> > >
