Re: ADC on Arduino Primo
Ive also got a DIS thats a good candidate and a very simple polled button. https://github.com/jacobrosenthal/mynewt-nimble-services/tree/master/services On Wed, Mar 1, 2017 at 9:53 AM, Sterling Hughes < sterling.hughes.pub...@gmail.com> wrote: > :-) > > 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 >>> >>>
Re: ADC on Arduino Primo
:-) 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
Re: ADC on Arduino Primo
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 >
Re: ADC on Arduino Primo
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
Re: ADC on Arduino Primo
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 > > > > 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 > >>
Re: ADC on Arduino Primo
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. >>> >>> >>> >>
Re: ADC on Arduino Primo
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 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. >>> >>> >>> >> >
Re: ADC on Arduino Primo
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. >> >> >> >
Re: ADC on Arduino Primo
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. > > >
Re: ADC on Arduino Primo
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/ <http://www.gnupg.com/> Secure your email!!! * Public key available at keyserver.pgp.com <http://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. signature.asc Description: Message signed with OpenPGP
ADC on Arduino Primo
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. Best regards, dg -- 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/ <http://www.gnupg.com/> Secure your email!!! * Public key available at keyserver.pgp.com <http://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. signature.asc Description: Message signed with OpenPGP
