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. also there is a missing include in main.c #include "myadc/myadc.h" #include <adc/adc.h> 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. >>> >>> >>> >> >
