Sent from my iPad
> On Feb 17, 2017, at 6:15 PM, Jacob Rosenthal <jakerosent...@gmail.com> wrote: > > OK no wait I think Im understanding.. It IS using the nrf52 driver and not > duplicating.. That's correct. > > Because of the driver style abstraction my_adc is an 'nrf52 water level > driver(sensor?)' (maybe a name change?) It is generic enough that this doesn't matter. It just takes a raw ADC value, then converts it to a millivolt value based on the reference voltage. Should work for any adc sensor. > > 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.. It specifically doesn't expose board-specific stuff in the main. All the board-specific stuff is in the mynewt_nordic package, and that can be updated and maintained separately from this. I wrote an intermediate driver that uses the hal and bsp but contains none of the (licensed) Nordic code. > > 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. No, the main code simply calls the init() method to open and initialize the adc, and then calls the drivers read_adc() method to get a value. If all the Nordic code lived in the my_adc package, it would be much harder to maintain should changes happen in the Nordic code. > > 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? That's exactly how it works now. > > 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. >>> >>> >>> >>
