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 <[email protected]> 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.
> 
> 

Reply via email to