You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by "David G. Simmons" <sa...@mac.com> on 2016/11/29 16:37:14 UTC
NRF52dk ADC
Moving on from the BLE -- which now works perfectly -- and I understand how 'subscribed' values work in nimBLE, thanks to all who responded!
Next up is implementing an ADC-based sensor. All the NRF52DK stuff has been moved out of -core and into mynewt-nordic, and I've looked through the source there as well.
From my understanding of the board, the ADC pin is P0.03, and I've tested the sensor, and it works. So, only questions are:
Given the move to external packages, how does the #include work? I've tried about every iteration of #include "drivers/adc/adc_nrf52/adc_nrf52.h" I can think of. :-)
Using the ADC:
struct os_dev adc_dev;
rc = nrf52_adc_dev_init(&adc_dev, void *);
assert(rc == 0);
Should then initialize the ADC? Or do I need to nrf52_adc_open() first?
And subsequently, how to read the ADC. Do I nrf52_adc_read_channel(), nrf52_adc_read_buffer() or ??
This is the first ADC Tutorial for the Mynewt docs, so I'd like to get it exactly right. :-)
Oh, the sensor is this one: https://www.adafruit.com/products/1786 which is a pretty cool liquid level sensor.
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.
Re: NRF52dk ADC
Posted by Adam <ad...@gmail.com>.
You should still be able to access a ref to the branch even if it was
deleted. For git, deleting a branch is more like shoving the clutter in
the closet than throwing it in the trash.
try 'git branch -a' to see if it's visible on the remote...
and if nothing else, 'git checkout 0c0f3e1' because that is the latest sha
on that branch-- i just checked :)
Adam
On Fri, Dec 2, 2016 at 9:42 AM, David G. Simmons <sa...@mac.com> wrote:
> Sadly my fork does not have that branch any longer ... If anyone DOES
> happen to have a copy of it, and could send me the relevant main.c file for
> reference, I'd greatly appreciate it!
>
> Best regards,
> dg
>
> > On Dec 2, 2016, at 12:43 PM, Christopher Collins <cc...@apache.org>
> wrote:
> >
> > On Fri, Dec 02, 2016 at 09:30:04AM -0800, will sanfilippo wrote:
> >> There is a branch called “sterly_refactor” that we used when we were
> >> refactoring bsp and other code. There is ADC code in there. If you
> >> checkout that branch you can go to the apps directory and look for the
> >> sblinky app. In that main.c (which is where I said this stuff shouldnt
> >> be but that was all just test code) it should show how the ADC was
> >> used. You cant just bring all that code in I suspect as it is way out
> >> of date, but I think there is enough in there to give you an idea of
> >> how things are expected to work.
> >>
> >> Be warned though; that code was just all hacked in and I am not sure
> >> what state it was left in.
> >
> > The sterly_refactor branch was deleted recently. However, if you have a
> > github fork, you probably have a copy of that branch.
> >
> > Chris
>
> --
> 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.
>
>
>
Re: NRF52dk ADC
Posted by "David G. Simmons" <sa...@mac.com>.
Sadly my fork does not have that branch any longer ... If anyone DOES happen to have a copy of it, and could send me the relevant main.c file for reference, I'd greatly appreciate it!
Best regards,
dg
> On Dec 2, 2016, at 12:43 PM, Christopher Collins <cc...@apache.org> wrote:
>
> On Fri, Dec 02, 2016 at 09:30:04AM -0800, will sanfilippo wrote:
>> There is a branch called “sterly_refactor” that we used when we were
>> refactoring bsp and other code. There is ADC code in there. If you
>> checkout that branch you can go to the apps directory and look for the
>> sblinky app. In that main.c (which is where I said this stuff shouldnt
>> be but that was all just test code) it should show how the ADC was
>> used. You cant just bring all that code in I suspect as it is way out
>> of date, but I think there is enough in there to give you an idea of
>> how things are expected to work.
>>
>> Be warned though; that code was just all hacked in and I am not sure
>> what state it was left in.
>
> The sterly_refactor branch was deleted recently. However, if you have a
> github fork, you probably have a copy of that branch.
>
> Chris
--
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.
Re: NRF52dk ADC
Posted by will sanfilippo <wi...@runtime.io>.
I should have realized that… I have a local copy of it (well, some copy of it at some point in time). If you cant get access to that branch David let me know and I think I can send you some files that would help.
> On Dec 2, 2016, at 9:43 AM, Christopher Collins <cc...@apache.org> wrote:
>
> On Fri, Dec 02, 2016 at 09:30:04AM -0800, will sanfilippo wrote:
>> There is a branch called “sterly_refactor” that we used when we were
>> refactoring bsp and other code. There is ADC code in there. If you
>> checkout that branch you can go to the apps directory and look for the
>> sblinky app. In that main.c (which is where I said this stuff shouldnt
>> be but that was all just test code) it should show how the ADC was
>> used. You cant just bring all that code in I suspect as it is way out
>> of date, but I think there is enough in there to give you an idea of
>> how things are expected to work.
>>
>> Be warned though; that code was just all hacked in and I am not sure
>> what state it was left in.
>
> The sterly_refactor branch was deleted recently. However, if you have a
> github fork, you probably have a copy of that branch.
>
> Chris
Re: NRF52dk ADC
Posted by Christopher Collins <cc...@apache.org>.
On Fri, Dec 02, 2016 at 09:30:04AM -0800, will sanfilippo wrote:
> There is a branch called \u201csterly_refactor\u201d that we used when we were
> refactoring bsp and other code. There is ADC code in there. If you
> checkout that branch you can go to the apps directory and look for the
> sblinky app. In that main.c (which is where I said this stuff shouldnt
> be but that was all just test code) it should show how the ADC was
> used. You cant just bring all that code in I suspect as it is way out
> of date, but I think there is enough in there to give you an idea of
> how things are expected to work.
>
> Be warned though; that code was just all hacked in and I am not sure
> what state it was left in.
The sterly_refactor branch was deleted recently. However, if you have a
github fork, you probably have a copy of that branch.
Chris
Re: NRF52dk ADC
Posted by will sanfilippo <wi...@runtime.io>.
There is a branch called “sterly_refactor” that we used when we were refactoring bsp and other code. There is ADC code in there. If you checkout that branch you can go to the apps directory and look for the sblinky app. In that main.c (which is where I said this stuff shouldnt be but that was all just test code) it should show how the ADC was used. You cant just bring all that code in I suspect as it is way out of date, but I think there is enough in there to give you an idea of how things are expected to work.
Be warned though; that code was just all hacked in and I am not sure what state it was left in.
> On Dec 2, 2016, at 9:11 AM, David G. Simmons <sa...@mac.com> wrote:
>
> Do you have some functioning code you could share? I'm really just using this sensor https://www.adafruit.com/products/1786 <https://www.adafruit.com/products/1786> and reading an analog voltage from it anyway.
>
> dg
>
>> On Dec 2, 2016, at 12:06 PM, will sanfilippo <wi...@runtime.io> wrote:
>>
>> I have not implemented an ADC sensor but I have used the ADC to simply get readings from an analog voltage so I at least know that the underlying ADC code works (or used to work) :-)
>
> --
> 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.
>
>
Re: NRF52dk ADC
Posted by "David G. Simmons" <sa...@mac.com>.
Do you have some functioning code you could share? I'm really just using this sensor https://www.adafruit.com/products/1786 <https://www.adafruit.com/products/1786> and reading an analog voltage from it anyway.
dg
> On Dec 2, 2016, at 12:06 PM, will sanfilippo <wi...@runtime.io> wrote:
>
> I have not implemented an ADC sensor but I have used the ADC to simply get readings from an analog voltage so I at least know that the underlying ADC code works (or used to work) :-)
--
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.
Re: NRF52dk ADC
Posted by will sanfilippo <wi...@runtime.io>.
Just to chime in here. Not sure what your interrupt issue without looking at it in more detail, but there is a reason you dont want to do the init in main and you want to do it in the bsp: you now have processor specific code in your application. If you want your driver or application to be processor independent you would move any processor specific code to a processor specific directory.
I have not implemented an ADC sensor but I have used the ADC to simply get readings from an analog voltage so I at least know that the underlying ADC code works (or used to work) :-)
> On Dec 2, 2016, at 7:47 AM, David G. Simmons <sa...@mac.com> wrote:
>
> Hi Marko,
>
> This is great, thanks! Super helpful, and I'm almost there ...
>
>>
>> That should happen through package dependencies.
>> So add dependency to @mynewt_nordic/hw/drivers/adc_nrf52.
>>
>> Here’s a sample as I tried this out:
>>
>> pkg.deps:
>> - "@apache-mynewt-core/sys/console/full"
>> - "@apache-mynewt-core/kernel/os"
>> - "@apache-mynewt-core/sys/shell"
>> - "@mynewt_nordic/hw/drivers/adc/adc_nrf52"
>
> Ahh ... I had gone with @mynewt_nordic/hw, so not a complete enough path.
>
>> And then I can include it from my source:
>>
>> #include <adc/adc.h>
>> #include <adc_nrf52/adc_nrf52.h>
>>
>>
>>>
>>> Using the ADC:
>>>
>>> struct os_dev adc_dev;
>>> rc = nrf52_adc_dev_init(&adc_dev, void *);
>>> assert(rc == 0);
>>>
>>> Should then initialize the ADC? Or do I need to nrf52_adc_open() first?
>>
>> Yes, you need to initialize it first. The preferred way to do this would be within
>> BSP's bsp_init(), but you can do it elsewhere early in the init.
>
> Can you explain why this is the preferred way? Unless a developer has been writing their own bsp, should they really be tinkering around in the bsp_init()? Or am I misreading this?
>
>>
>> I added this to my app’s main():
>>
>> rc = os_dev_create((struct os_dev *)&adc_dev, "adc0",
>> OS_DEV_INIT_KERNEL, OS_DEV_INIT_PRIO_DEFAULT,
>> nrf52_adc_dev_init, &adc_cfg);
>> assert(rc == 0);
>>
>> And then once the system has started, I open it from a task:
>>
>> dev = (struct adc_dev *)os_dev_open("adc0",
>> OS_TIMEOUT_NEVER,
>> &saadc_cfg);
>> assert(dev);
>>
>>> And subsequently, how to read the ADC. Do I nrf52_adc_read_channel(), nrf52_adc_read_buffer() or ??
>>>
>>
>> I would go through the function pointers within dev->ad_funcs. Or the convenience functions
>> present in adc/adc.h. I don’t have sample code for this at hand though. Maybe someone else
>> does?
>>
>
> Apparently something's not quite right. As soon as I run os_start() after os_dev_create() I get:
>
> 0:Unhandled interrupt (3), exception sp 0xffffffd8
>
> And if I'm in the debugger:
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> os_default_irq (tf=0x2000ff90) at os_fault.c:143
> 143 console_printf(" r0:0x%08lx r1:0x%08lx r2:0x%08lx r3:0x%08lx\n",
>
> Which doesn't look good. :-)
>
> os_dev_create() succeeds, that much I know, but apparently not much beyond that is good.
>
> Still have to figure out how to actually read values too, once I get the device created/initialized.
>
> Anyone gotten ADC sensor devices working?
>
> 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.
>
>
Re: NRF52dk ADC
Posted by "David G. Simmons" <sa...@mac.com>.
Hi Marko,
This is great, thanks! Super helpful, and I'm almost there ...
>
> That should happen through package dependencies.
> So add dependency to @mynewt_nordic/hw/drivers/adc_nrf52.
>
> Here’s a sample as I tried this out:
>
> pkg.deps:
> - "@apache-mynewt-core/sys/console/full"
> - "@apache-mynewt-core/kernel/os"
> - "@apache-mynewt-core/sys/shell"
> - "@mynewt_nordic/hw/drivers/adc/adc_nrf52"
Ahh ... I had gone with @mynewt_nordic/hw, so not a complete enough path.
> And then I can include it from my source:
>
> #include <adc/adc.h>
> #include <adc_nrf52/adc_nrf52.h>
>
>
>>
>> Using the ADC:
>>
>> struct os_dev adc_dev;
>> rc = nrf52_adc_dev_init(&adc_dev, void *);
>> assert(rc == 0);
>>
>> Should then initialize the ADC? Or do I need to nrf52_adc_open() first?
>
> Yes, you need to initialize it first. The preferred way to do this would be within
> BSP's bsp_init(), but you can do it elsewhere early in the init.
Can you explain why this is the preferred way? Unless a developer has been writing their own bsp, should they really be tinkering around in the bsp_init()? Or am I misreading this?
>
> I added this to my app’s main():
>
> rc = os_dev_create((struct os_dev *)&adc_dev, "adc0",
> OS_DEV_INIT_KERNEL, OS_DEV_INIT_PRIO_DEFAULT,
> nrf52_adc_dev_init, &adc_cfg);
> assert(rc == 0);
>
> And then once the system has started, I open it from a task:
>
> dev = (struct adc_dev *)os_dev_open("adc0",
> OS_TIMEOUT_NEVER,
> &saadc_cfg);
> assert(dev);
>
>> And subsequently, how to read the ADC. Do I nrf52_adc_read_channel(), nrf52_adc_read_buffer() or ??
>>
>
> I would go through the function pointers within dev->ad_funcs. Or the convenience functions
> present in adc/adc.h. I don’t have sample code for this at hand though. Maybe someone else
> does?
>
Apparently something's not quite right. As soon as I run os_start() after os_dev_create() I get:
0:Unhandled interrupt (3), exception sp 0xffffffd8
And if I'm in the debugger:
Program received signal SIGTRAP, Trace/breakpoint trap.
os_default_irq (tf=0x2000ff90) at os_fault.c:143
143 console_printf(" r0:0x%08lx r1:0x%08lx r2:0x%08lx r3:0x%08lx\n",
Which doesn't look good. :-)
os_dev_create() succeeds, that much I know, but apparently not much beyond that is good.
Still have to figure out how to actually read values too, once I get the device created/initialized.
Anyone gotten ADC sensor devices working?
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.
Re: NRF52dk ADC
Posted by marko kiiskila <ma...@runtime.io>.
Hi David,
I have partial answers:
> On Nov 29, 2016, at 8:37 AM, David G. Simmons <sa...@mac.com> wrote:
>
>
> Moving on from the BLE -- which now works perfectly -- and I understand how 'subscribed' values work in nimBLE, thanks to all who responded!
>
> Next up is implementing an ADC-based sensor. All the NRF52DK stuff has been moved out of -core and into mynewt-nordic, and I've looked through the source there as well.
>
> From my understanding of the board, the ADC pin is P0.03, and I've tested the sensor, and it works. So, only questions are:
>
> Given the move to external packages, how does the #include work? I've tried about every iteration of #include "drivers/adc/adc_nrf52/adc_nrf52.h" I can think of. :-)
That should happen through package dependencies.
So add dependency to @mynewt_nordic/hw/drivers/adc_nrf52.
Here’s a sample as I tried this out:
pkg.deps:
- "@apache-mynewt-core/sys/console/full"
- "@apache-mynewt-core/kernel/os"
- "@apache-mynewt-core/sys/shell"
- "@mynewt_nordic/hw/drivers/adc/adc_nrf52"
And then I can include it from my source:
#include <adc/adc.h>
#include <adc_nrf52/adc_nrf52.h>
>
> Using the ADC:
>
> struct os_dev adc_dev;
> rc = nrf52_adc_dev_init(&adc_dev, void *);
> assert(rc == 0);
>
> Should then initialize the ADC? Or do I need to nrf52_adc_open() first?
Yes, you need to initialize it first. The preferred way to do this would be within
BSP's bsp_init(), but you can do it elsewhere early in the init.
I added this to my app’s main():
rc = os_dev_create((struct os_dev *)&adc_dev, "adc0",
OS_DEV_INIT_KERNEL, OS_DEV_INIT_PRIO_DEFAULT,
nrf52_adc_dev_init, &adc_cfg);
assert(rc == 0);
And then once the system has started, I open it from a task:
dev = (struct adc_dev *)os_dev_open("adc0",
OS_TIMEOUT_NEVER,
&saadc_cfg);
assert(dev);
> And subsequently, how to read the ADC. Do I nrf52_adc_read_channel(), nrf52_adc_read_buffer() or ??
>
I would go through the function pointers within dev->ad_funcs. Or the convenience functions
present in adc/adc.h. I don’t have sample code for this at hand though. Maybe someone else
does?
> This is the first ADC Tutorial for the Mynewt docs, so I'd like to get it exactly right. :-)
Hope this helps.
> Oh, the sensor is this one: https://www.adafruit.com/products/1786 which is a pretty cool liquid level sensor.
>
> 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.
>
>