Re: ADC on Arduino Primo

2017-02-17 Thread David Simmons 


Sent from my iPad

> On Feb 17, 2017, at 6:15 PM, Jacob Rosenthal  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 
> 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 
>> 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  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  • Blog  •
>>> Linkedin  • Twitter
>>>  • GitHub 
>>> /** 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

2017-02-17 Thread Jacob Rosenthal 
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 
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 
> 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 
>> 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  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  • Blog  •
>>> Linkedin  • Twitter
>>>  • GitHub
>>> 
>>> /** 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

2017-02-17 Thread Jacob Rosenthal 
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 
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 
> 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  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  • Blog  •
>> Linkedin  • Twitter
>>  • GitHub 
>> /** 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.
>>
>>
>>
>

[ANNOUNCE] Apache Mynewt 1.0.0-b2-incubating

2017-02-17 Thread Will San Filippo 
Hello all,

The Apache Mynewt team is pleased to announce the release of
1.0.0-b2-incubating.

Apache Mynewt is a community-driven module OS for constrained, embedded
applications.  Mynewt provides a real-time operating system, flash file
system, network stacks, and support utilities for real-world embedded
systems.

The release is available here:
http://www.apache.org/dyn/closer.lua/incubator/mynewt/apache-mynewt-1.0.0-b2-incubating

Release notes can be found here:
https://cwiki.apache.org/confluence/display/MYNEWT/RN-1.0.0-b2-incubating

We welcome your help and feedback. For more information on the project
and how to get involved, visit the project website at
http://mynewt.incubator.apache.org/

Regards,
The Apache Mynewt team

Disclaimer:
Apache Mynewt is an effort undergoing incubation at The Apache Software
Foundation (ASF) sponsored by the Apache Incubator PMC. Incubation is
required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process have stabilized in a manner consistent with other successful
ASF projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate that
the project has yet to be fully endorsed by the ASF.

Re: ADC on Arduino Primo

2017-02-17 Thread Jacob Rosenthal 
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  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  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  • Blog  •
> Linkedin  • Twitter
>  • GitHub 
> /** 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: Issues with bleprph and blecent on nRF51822xxaa

2017-02-17 Thread marko kiiskila 

> On Feb 16, 2017, at 8:19 PM, Marcos Scheeren  wrote:
> 
> Hi, Marko.
> 
> On Tue, Feb 14, 2017 at 2:33 PM, marko kiiskila  wrote:
>> Hi,
>> 
>> 
>> Quick peek to gdb sources tells me that the memory region is marked as
>> flash, and comment says that only allow writes during ‘load’ phase (which,
>> technically, I guess would be correct). Check the output of ‘info mem’, and 
>> see if you
>> can change the properties of it.
>> 
> 
> (gdb) info mem
> Using memory regions provided by the target.
> Num Enb Low Addr   High Addr  Attrs
> 0   y   0x 0x0004 flash blocksize 0x400 nocache
> 1   y   0x10001000 0x10001100 flash blocksize 0x100 nocache
> 2   y   0x2000 0x20004000 rw nocache

You could try removing the memory areas which are marked as flash, and then use
restore.
I.e.
delete mem 0
delete mem 1
mem 0 0x rw nocache
info mem
restore  binary 

Depending on the gdb remote implementation, aka your black magic probe, this 
might
or might not work.

> 
>> Alternative would be to convert the binary blob into a ihex or srecord 
>> format.
>> gdb can load these the same way as it can load elf. You can use objcopy
>> to do that. Note that elf has location data, as do ihex and srecord.
>> 
> 
> I tried "$ arm-none-eabi-objcopy bletest.elf.bin -O srec bletest.elf.bin.srec"
> but it yields: arm-none-eabi-objcopy:bletest.elf.bin: File format not 
> recognized


I don’t know what the flash map is like on your bsp.yml, but this is how you’d
convert binary into srecord so I can’t give the correct start address.
This is how you’d do it if you were to set the load address to 0x8000.

arm-none-eabi-objcopy --adjust-vma=0x8000 -O srec -I binary blinky.img 
blinky.srec
After this you should be able to do ‘load blinky.srec’ in gdb.

> 
> When inputting the .elf file, it converts ok to both srec and ihex and GDB
> accepts both just fine.
> 
> 
>> 
>> My guess the system is out of heap. Check while in gdb:
>> p/d sbrkBase-brk
>> 
>> Hopefully there are things you can prune out.
>> 
> 
> The output of p/d sbrkBase-brk in gdb:
> blehci: -5392
> bletest: -1120
> bleprph: -192
> bleprph (BLE_LL_CFG_FEAT_LE_ENCRYPTION: 0 // BLE_SM_LEGACY: 0):  -1072
> blecent: -1200

Ah, my bad! I remembered the symbol name for end-of-heap incorrect.
Instead, say:

p/d sbrkLimit - brk


>> 
>> Highly unlikely that the linker scripts would cause this.
>> I suspect it’s the RAM usage.
> 
> Could it be that for some examples/apps 16KB MCUs aren't just enough?

I’m pretty certain not all of those have been tried. Others on the list might 
have
more data on this.



>> 
>> Let me know how it goes,
>> M
>> 
>> 
> 
> Thank you.
> Marcos.