You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Mo Chen <sh...@gmail.com> on 2020/06/03 15:41:53 UTC
Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Hi dear development team,
The newly released Mynewt (1.8.0) adopted a new version of nrf52 driver
which is nrfx 2.1.0 (the last version was 1.7.0).
However, the APIs have changed a lot. And the working code with nrfx 1.7.0
totally doesn't work anymore.
I searched online and found no supported documents.
I then reached out to Nordic for tech support and got the following answer:
Basically, they said the support document is not available and they are
planning to backport the driver to 1.8.x in their own next version of SDK.
It looks like there are a lot of issues with the newer driver. If they are
backporting their own SDK, I suggest we do the same. So that the code still
works and will be well supported.
Maybe we can upgrade the driver after the official support document is
available and updated in their own SDK.
Please seriously consider my suggestion, since this significantly affects
our development progress and shown no benefits.
Thanks,
Below is the response by their tech support staff:
----------------------------
Hi,
As you figured, the nrfx 2.x API is not supported in the nRF5 SDK exactly
because of the large changes in the SPI of the new nrfx_saadc driver. The
driver have been completely rewritten to fix some issues seen with the old
driver. The new driver will be backported to nrfx v1.8.x in the next
release of nRF5 SDK, but the legacy driver will still be available. The
example code needs to be completely rewritten to support the new driver.
Unfortunately, for now, we do not have any examples available for the new
driver. I would recommend you to stick with the driver from nrfx v1.8.x for
now.
Best regards,
Jørgen
-----------------------------
Mo Chen
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Miguel Azevedo <mi...@gmail.com>.
Ok, it looks like you are having a pin mapping problem, the pin value is
actually not converted from gpio number to adc pin number (which probably
should). Please look at the board schematics, in order to know which adc
input pin is the one you want to use, as far as I recall the Arduino analog
pins on the board don't map directly to the ADC input pins on nrf52xxx
boards.
On Wed, 10 Jun 2020, 22:13 Mo Chen, <sh...@gmail.com> wrote:
> Hi Miguel,
>
> I guess the problem is I am not sure what to input to the following
> structure:
>
> for "cc.pin", is my input correct? I tried NRF_SAADC_INPUT_AIN1 and (
> nrf_saadc_input_t)(NRF_SAADC_INPUT_AIN1). No luck. For nrf52, what should
> I input to it?
>
> also the same for "cc.pin_negative"
>
> Thanks,
>
> struct adc_chan_cfg cc = {
> .pin = (nrf_saadc_input_t)(NRF_SAADC_INPUT_AIN1),
> .differential = false,
> .pin_negative = (nrf_saadc_input_t)(NRF_SAADC_INPUT_DISABLED),
> .gain = ADC_GAIN1_6,
> .reference = ADC_REFERENCE_INTERNAL
> };
>
> On Wed, Jun 10, 2020 at 2:42 PM Mo Chen <sh...@gmail.com> wrote:
>
> > Hi Miguel,
> >
> > Yes, I understand that the code you sent doesn't include BLE functions.
> >
> > I modified the code on the Mynewt official website by adopting the ADC
> > configuration.
> >
> > The switch (etype) structure stuck the execution. So I removed the switch
> > structure and just did the same as the example shown in the link:
> >
> > https://mynewt.apache.org/latest/tutorials/sensors/nrf52_adc.html
> >
> > Still, the ADC give a value a 0 volt.
> >
> > The code on the official Website runs normally with 1.7.0.
> >
> > I think there must be something wrong with the ADC configuration.
> >
> > My goal is to have the example code on the official website run with
> 1.8.0.
> >
> > https://mynewt.apache.org/latest/tutorials/sensors/nrf52_adc.html
> >
> > Would you please help look into this?
> >
> > Thanks for your help!
> >
> >
> >
> > On Wed, Jun 10, 2020, 13:22 Miguel Azevedo <mi...@gmail.com>
> wrote:
> >
> >> Hi Mo,
> >>
> >> I am currently away from my computer but the example app supposedly
> >> doesn't
> >> have any Bluetooth features enabled. I'll give a closer look on your
> issue
> >> tomorrow, by the way keep in mind that the code I posted the link for
> >> belongs to a branch which is slightly different from master.
> >>
> >> On Wed, 10 Jun 2020, 17:31 Andrew Stevenson, <an...@ugh.net.au> wrote:
> >>
> >> >
> >> >
> >> > > On 10. Jun 2020, at 17:26, Mo Chen <sh...@gmail.com> wrote:
> >> > >
> >> > > Hi Andrew,
> >> > >
> >> > > Would you please attach the blog post you mentioned?
> >> >
> >> > It was attached so I guess the mailing list software strips
> >> attachments. I
> >> > have CCed you on this message so you should have two copies, one with
> >> the
> >> > attachment.
> >> >
> >> > Andrew
> >> >
> >> >
> >> >
> >> >
> >>
> > Mo Chen
> >
>
>
> --
> Mo Chen
>
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Mo Chen <sh...@gmail.com>.
Hi Miguel,
I guess the problem is I am not sure what to input to the following
structure:
for "cc.pin", is my input correct? I tried NRF_SAADC_INPUT_AIN1 and (
nrf_saadc_input_t)(NRF_SAADC_INPUT_AIN1). No luck. For nrf52, what should
I input to it?
also the same for "cc.pin_negative"
Thanks,
struct adc_chan_cfg cc = {
.pin = (nrf_saadc_input_t)(NRF_SAADC_INPUT_AIN1),
.differential = false,
.pin_negative = (nrf_saadc_input_t)(NRF_SAADC_INPUT_DISABLED),
.gain = ADC_GAIN1_6,
.reference = ADC_REFERENCE_INTERNAL
};
On Wed, Jun 10, 2020 at 2:42 PM Mo Chen <sh...@gmail.com> wrote:
> Hi Miguel,
>
> Yes, I understand that the code you sent doesn't include BLE functions.
>
> I modified the code on the Mynewt official website by adopting the ADC
> configuration.
>
> The switch (etype) structure stuck the execution. So I removed the switch
> structure and just did the same as the example shown in the link:
>
> https://mynewt.apache.org/latest/tutorials/sensors/nrf52_adc.html
>
> Still, the ADC give a value a 0 volt.
>
> The code on the official Website runs normally with 1.7.0.
>
> I think there must be something wrong with the ADC configuration.
>
> My goal is to have the example code on the official website run with 1.8.0.
>
> https://mynewt.apache.org/latest/tutorials/sensors/nrf52_adc.html
>
> Would you please help look into this?
>
> Thanks for your help!
>
>
>
> On Wed, Jun 10, 2020, 13:22 Miguel Azevedo <mi...@gmail.com> wrote:
>
>> Hi Mo,
>>
>> I am currently away from my computer but the example app supposedly
>> doesn't
>> have any Bluetooth features enabled. I'll give a closer look on your issue
>> tomorrow, by the way keep in mind that the code I posted the link for
>> belongs to a branch which is slightly different from master.
>>
>> On Wed, 10 Jun 2020, 17:31 Andrew Stevenson, <an...@ugh.net.au> wrote:
>>
>> >
>> >
>> > > On 10. Jun 2020, at 17:26, Mo Chen <sh...@gmail.com> wrote:
>> > >
>> > > Hi Andrew,
>> > >
>> > > Would you please attach the blog post you mentioned?
>> >
>> > It was attached so I guess the mailing list software strips
>> attachments. I
>> > have CCed you on this message so you should have two copies, one with
>> the
>> > attachment.
>> >
>> > Andrew
>> >
>> >
>> >
>> >
>>
> Mo Chen
>
--
Mo Chen
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Mo Chen <sh...@gmail.com>.
Hi Miguel,
Yes, I understand that the code you sent doesn't include BLE functions.
I modified the code on the Mynewt official website by adopting the ADC
configuration.
The switch (etype) structure stuck the execution. So I removed the switch
structure and just did the same as the example shown in the link:
https://mynewt.apache.org/latest/tutorials/sensors/nrf52_adc.html
Still, the ADC give a value a 0 volt.
The code on the official Website runs normally with 1.7.0.
I think there must be something wrong with the ADC configuration.
My goal is to have the example code on the official website run with 1.8.0.
https://mynewt.apache.org/latest/tutorials/sensors/nrf52_adc.html
Would you please help look into this?
Thanks for your help!
On Wed, Jun 10, 2020, 13:22 Miguel Azevedo <mi...@gmail.com> wrote:
> Hi Mo,
>
> I am currently away from my computer but the example app supposedly doesn't
> have any Bluetooth features enabled. I'll give a closer look on your issue
> tomorrow, by the way keep in mind that the code I posted the link for
> belongs to a branch which is slightly different from master.
>
> On Wed, 10 Jun 2020, 17:31 Andrew Stevenson, <an...@ugh.net.au> wrote:
>
> >
> >
> > > On 10. Jun 2020, at 17:26, Mo Chen <sh...@gmail.com> wrote:
> > >
> > > Hi Andrew,
> > >
> > > Would you please attach the blog post you mentioned?
> >
> > It was attached so I guess the mailing list software strips attachments.
> I
> > have CCed you on this message so you should have two copies, one with the
> > attachment.
> >
> > Andrew
> >
> >
> >
> >
>
Mo Chen
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Miguel Azevedo <mi...@gmail.com>.
Hi Mo,
I am currently away from my computer but the example app supposedly doesn't
have any Bluetooth features enabled. I'll give a closer look on your issue
tomorrow, by the way keep in mind that the code I posted the link for
belongs to a branch which is slightly different from master.
On Wed, 10 Jun 2020, 17:31 Andrew Stevenson, <an...@ugh.net.au> wrote:
>
>
> > On 10. Jun 2020, at 17:26, Mo Chen <sh...@gmail.com> wrote:
> >
> > Hi Andrew,
> >
> > Would you please attach the blog post you mentioned?
>
> It was attached so I guess the mailing list software strips attachments. I
> have CCed you on this message so you should have two copies, one with the
> attachment.
>
> Andrew
>
>
>
>
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Andrew Stevenson <an...@ugh.net.au>.
> On 10. Jun 2020, at 17:26, Mo Chen <sh...@gmail.com> wrote:
>
> Hi Andrew,
>
> Would you please attach the blog post you mentioned?
It was attached so I guess the mailing list software strips attachments. I have CCed you on this message so you should have two copies, one with the attachment.
Andrew
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Mo Chen <sh...@gmail.com>.
Hi Andrew,
Would you please attach the blog post you mentioned?
Thanks,
On Wed, Jun 10, 2020 at 10:23 AM Andrew Stevenson <an...@ugh.net.au> wrote:
>
>
> > On 10. Jun 2020, at 16:51, Mo Chen <sh...@gmail.com> wrote:
> >
> > BTW: I am using 1.9.0 dev. I could not figure out how to install 1.8.0 on
> > MacOS. If I use brew install mynewt-newt, it will install 1.7.0, although
> > 1.8.0 has been released a while ago. Can you please guide me on this as
> > well?
>
> You don’t have to use brew to install the mynewt tools. I attach a blog
> post (as I don’t have anywhere to post it yet) covering the steps I did.
> They compile pretty easily.
>
> HTH,
>
> Andrew
--
Mo Chen
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Andrew Stevenson <an...@ugh.net.au>.
> On 10. Jun 2020, at 16:51, Mo Chen <sh...@gmail.com> wrote:
>
> BTW: I am using 1.9.0 dev. I could not figure out how to install 1.8.0 on
> MacOS. If I use brew install mynewt-newt, it will install 1.7.0, although
> 1.8.0 has been released a while ago. Can you please guide me on this as
> well?
You don’t have to use brew to install the mynewt tools. I attach a blog post (as I don’t have anywhere to post it yet) covering the steps I did. They compile pretty easily.
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Mo Chen <sh...@gmail.com>.
Hi Miguel,
Thank you so much for your email. The example helps.
However, it seems like something has been changed in the BLE service or the
OS task?
Previously, my code could run, the only problem is the ADC returns 0
voltage. However, today, when I run the exact same code (no modification at
all, just did a newt upgraded), after downloaded, there is no BLE service
can be detected by my phone.
If I run the same code with 1.7.0, it runs properly then. I can see the BLE
service. Just with 1.8.0, no service...
Is there any change applied?
I just want to have the example:
https://mynewt.apache.org/latest/tutorials/sensors/nrf52_adc.html to run
with 1.8.0.
BTW: I am using 1.9.0 dev. I could not figure out how to install 1.8.0 on
MacOS. If I use brew install mynewt-newt, it will install 1.7.0, although
1.8.0 has been released a while ago. Can you please guide me on this as
well?
Thank you so much,
On Thu, Jun 4, 2020 at 6:41 AM Miguel Azevedo <mi...@gmail.com> wrote:
> So use this as reference, you will probably need to do a few changes so it
> compiles but this is the most updated code out there.
>
> https://github.com/mlaz/mynewt-core/blob/adc_api_changes/apps/adc_test/src/main.c
> On Wed, 3 Jun 2020, 19:05 Mo Chen, <sh...@gmail.com> wrote:
>
> > Hi Miguel,
> >
> > Thank you for your replay and detailed explanation on the underlying
> works
> > done to adopt the newer version of nrfx drivers.
> >
> > I really appreciate your offering help to have the code working.
> >
> > What we need help with is the example ADC code posted on the Mynewt
> > official website which was based on Mynewt version 1.5.0 and it works on
> > 1.7.0 but not with 1.8.0.
> >
> > Link of the example code: the highlighted part gave errors while
> compiling.
> >
> > #include <assert.h>#include <os/os.h>#include <string.h>
> > /* ADC */#include "myadc/myadc.h"#include "nrf.h"#include <adc/adc.h>
> > /* Nordic headers */#include <nrfx.h>#include <nrf_saadc.h>#include
> > <nrfx_saadc.h>#include <nrfx_config.h>
> > #define ADC_NUMBER_SAMPLES (2)#define ADC_NUMBER_CHANNELS (1)
> > nrfx_saadc_config_t adc_config = NRFX_SAADC_DEFAULT_CONFIG;struct
> > adc_dev *adc;uint8_t *sample_buffer1;uint8_t *sample_buffer2;
> > void *adc_init(void){
> > nrf_saadc_channel_config_t cc =
> > NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
> > cc.gain = NRF_SAADC_GAIN1_6;
> > cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
> > adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
> > assert(adc != NULL);
> > adc_chan_config(adc, 0, &cc);
> > sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > adc_buf_set(adc, sample_buffer1, sample_buffer2,
> > adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
> > return adc;}
> > intadc_read(void *buffer, int buffer_len){
> > int i;
> > int adc_result;
> > int my_result_mv = 0;
> > int rc;
> > for (i = 0; i < ADC_NUMBER_SAMPLES; i++) {
> > rc = adc_buf_read(adc, buffer, buffer_len, i, &adc_result);
> > if (rc != 0) {
> > goto err;
> > }
> > my_result_mv = adc_result_mv(adc, 0, adc_result);
> > }
> > adc_buf_release(adc, buffer, buffer_len);
> > return my_result_mv;err:
> > return (rc);}
> >
> >
> > I then tried to modify it according to the new nrfx driver functions. The
> > modified code passed the complie however, the ADC value is always 0.
> Would
> > you please help check what was done wrong and how to make it work as it
> > was?
> >
> > The code I modified: commented the code with error and replaced by the
> > green highlighted code lines.
> >
> >
> > //nrfx_saadc_config_t adc_config = NRFX_SAADC_DEFAULT_ADV_CONFIG;
> > nrfx_saadc_adv_config_t adc_config = NRFX_SAADC_DEFAULT_ADV_CONFIG;
> >
> > struct adc_dev *adc;
> > uint8_t *sample_buffer1;
> > uint8_t *sample_buffer2;
> >
> > void *
> > adc_init(void)
> > {
> > //nrfx_saadc_channel_config_t cc =
> > NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
> > //cc.gain = NRF_SAADC_GAIN1_6;
> > //cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
> > nrfx_saadc_channel_t cc =
> > NRFX_SAADC_DEFAULT_CHANNEL_SE(NRF_SAADC_INPUT_AIN1, 0);
> > adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
> > assert(adc != NULL);
> > adc_chan_config(adc, 0, &cc);
> > sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> > ADC_NUMBER_SAMPLES));
> > adc_buf_set(adc, sample_buffer1, sample_buffer2,
> > adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
> > return adc;
> > }
> >
> >
> >
> > Thank you very much!
> >
> >
> >
> > On Wed, Jun 3, 2020 at 11:41 AM Miguel Azevedo <mi...@gmail.com>
> > wrote:
> >
> > > Hi Mo,
> > >
> > > If I understand correctly the new nrfx ADC driver is the one causing
> > > problems on the NRFX side. Our new driver doesn't wrap around the nrfx
> > > driver so it should be safe from whatever problems that new driver has.
> > > Instead we only use the nrfx HAL layer, which is proven to be a better
> > > option, since on nrfx driver code is more prone to chenges. Also the
> > > changes done on our ADC API were done so we would be able to roam
> > towards a
> > > better ADC API, so we don't have to use nrfx datastructures and types
> on
> > > app code and so we can have ADCs working the same way(as much as
> > possible)
> > > across different MCUs. Please take a look at this issue
> > > https://github.com/apache/mynewt-core/issues/2273 . We updated nrfx to
> > 2.x
> > > at the time because we did have an incompatibility related to tinyUSB
> at
> > > that time, so we needed nrfx to be on a version higher than 2.0.0 (this
> > was
> > > discussed on this mailing list last November). This led us to having to
> > > fully rewrite the ADC driver and update the PWM driver (which
> > unfortunately
> > > also wraps around the nrfx driver instead of using the nrfx HAL API).
> > Given
> > > the two aforementioned reasons I am opposing to your suggestion, the
> > driver
> > > works well and we need consistent APIs. I f you need I can help you to
> > > update your old code but I see no reason for us to regress. Feel free
> to
> > > reach me through this e-mail address or through mynewt's slack (my
> handle
> > > is mlaz).
> > >
> > > Thanks,
> > >
> > > Miguel
> > >
> > > On Wed, 3 Jun 2020, 16:42 Mo Chen, <sh...@gmail.com> wrote:
> > >
> > > > Hi dear development team,
> > > >
> > > > The newly released Mynewt (1.8.0) adopted a new version of nrf52
> driver
> > > > which is nrfx 2.1.0 (the last version was 1.7.0).
> > > >
> > > > However, the APIs have changed a lot. And the working code with nrfx
> > > 1.7.0
> > > > totally doesn't work anymore.
> > > >
> > > > I searched online and found no supported documents.
> > > >
> > > > I then reached out to Nordic for tech support and got the following
> > > answer:
> > > >
> > > > Basically, they said the support document is not available and they
> are
> > > > planning to backport the driver to 1.8.x in their own next version of
> > > SDK.
> > > >
> > > > It looks like there are a lot of issues with the newer driver. If
> they
> > > are
> > > > backporting their own SDK, I suggest we do the same. So that the code
> > > still
> > > > works and will be well supported.
> > > >
> > > > Maybe we can upgrade the driver after the official support document
> is
> > > > available and updated in their own SDK.
> > > >
> > > > Please seriously consider my suggestion, since this significantly
> > affects
> > > > our development progress and shown no benefits.
> > > >
> > > > Thanks,
> > > >
> > > > Below is the response by their tech support staff:
> > > >
> > > > ----------------------------
> > > >
> > > > Hi,
> > > >
> > > > As you figured, the nrfx 2.x API is not supported in the nRF5 SDK
> > exactly
> > > > because of the large changes in the SPI of the new nrfx_saadc driver.
> > The
> > > > driver have been completely rewritten to fix some issues seen with
> the
> > > old
> > > > driver. The new driver will be backported to nrfx v1.8.x in the next
> > > > release of nRF5 SDK, but the legacy driver will still be available.
> The
> > > > example code needs to be completely rewritten to support the new
> > driver.
> > > > Unfortunately, for now, we do not have any examples available for the
> > new
> > > > driver. I would recommend you to stick with the driver from nrfx
> v1.8.x
> > > for
> > > > now.
> > > >
> > > > Best regards,
> > > > Jørgen
> > > >
> > > > -----------------------------
> > > >
> > > >
> > > >
> > > > Mo Chen
> > > >
> > >
> >
> >
> > --
> > Mo Chen
> >
>
--
Mo Chen
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Miguel Azevedo <mi...@gmail.com>.
So use this as reference, you will probably need to do a few changes so it
compiles but this is the most updated code out there.
https://github.com/mlaz/mynewt-core/blob/adc_api_changes/apps/adc_test/src/main.c
On Wed, 3 Jun 2020, 19:05 Mo Chen, <sh...@gmail.com> wrote:
> Hi Miguel,
>
> Thank you for your replay and detailed explanation on the underlying works
> done to adopt the newer version of nrfx drivers.
>
> I really appreciate your offering help to have the code working.
>
> What we need help with is the example ADC code posted on the Mynewt
> official website which was based on Mynewt version 1.5.0 and it works on
> 1.7.0 but not with 1.8.0.
>
> Link of the example code: the highlighted part gave errors while compiling.
>
> #include <assert.h>#include <os/os.h>#include <string.h>
> /* ADC */#include "myadc/myadc.h"#include "nrf.h"#include <adc/adc.h>
> /* Nordic headers */#include <nrfx.h>#include <nrf_saadc.h>#include
> <nrfx_saadc.h>#include <nrfx_config.h>
> #define ADC_NUMBER_SAMPLES (2)#define ADC_NUMBER_CHANNELS (1)
> nrfx_saadc_config_t adc_config = NRFX_SAADC_DEFAULT_CONFIG;struct
> adc_dev *adc;uint8_t *sample_buffer1;uint8_t *sample_buffer2;
> void *adc_init(void){
> nrf_saadc_channel_config_t cc =
> NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
> cc.gain = NRF_SAADC_GAIN1_6;
> cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
> adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
> assert(adc != NULL);
> adc_chan_config(adc, 0, &cc);
> sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> adc_buf_set(adc, sample_buffer1, sample_buffer2,
> adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
> return adc;}
> intadc_read(void *buffer, int buffer_len){
> int i;
> int adc_result;
> int my_result_mv = 0;
> int rc;
> for (i = 0; i < ADC_NUMBER_SAMPLES; i++) {
> rc = adc_buf_read(adc, buffer, buffer_len, i, &adc_result);
> if (rc != 0) {
> goto err;
> }
> my_result_mv = adc_result_mv(adc, 0, adc_result);
> }
> adc_buf_release(adc, buffer, buffer_len);
> return my_result_mv;err:
> return (rc);}
>
>
> I then tried to modify it according to the new nrfx driver functions. The
> modified code passed the complie however, the ADC value is always 0. Would
> you please help check what was done wrong and how to make it work as it
> was?
>
> The code I modified: commented the code with error and replaced by the
> green highlighted code lines.
>
>
> //nrfx_saadc_config_t adc_config = NRFX_SAADC_DEFAULT_ADV_CONFIG;
> nrfx_saadc_adv_config_t adc_config = NRFX_SAADC_DEFAULT_ADV_CONFIG;
>
> struct adc_dev *adc;
> uint8_t *sample_buffer1;
> uint8_t *sample_buffer2;
>
> void *
> adc_init(void)
> {
> //nrfx_saadc_channel_config_t cc =
> NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
> //cc.gain = NRF_SAADC_GAIN1_6;
> //cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
> nrfx_saadc_channel_t cc =
> NRFX_SAADC_DEFAULT_CHANNEL_SE(NRF_SAADC_INPUT_AIN1, 0);
> adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
> assert(adc != NULL);
> adc_chan_config(adc, 0, &cc);
> sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
> ADC_NUMBER_SAMPLES));
> adc_buf_set(adc, sample_buffer1, sample_buffer2,
> adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
> return adc;
> }
>
>
>
> Thank you very much!
>
>
>
> On Wed, Jun 3, 2020 at 11:41 AM Miguel Azevedo <mi...@gmail.com>
> wrote:
>
> > Hi Mo,
> >
> > If I understand correctly the new nrfx ADC driver is the one causing
> > problems on the NRFX side. Our new driver doesn't wrap around the nrfx
> > driver so it should be safe from whatever problems that new driver has.
> > Instead we only use the nrfx HAL layer, which is proven to be a better
> > option, since on nrfx driver code is more prone to chenges. Also the
> > changes done on our ADC API were done so we would be able to roam
> towards a
> > better ADC API, so we don't have to use nrfx datastructures and types on
> > app code and so we can have ADCs working the same way(as much as
> possible)
> > across different MCUs. Please take a look at this issue
> > https://github.com/apache/mynewt-core/issues/2273 . We updated nrfx to
> 2.x
> > at the time because we did have an incompatibility related to tinyUSB at
> > that time, so we needed nrfx to be on a version higher than 2.0.0 (this
> was
> > discussed on this mailing list last November). This led us to having to
> > fully rewrite the ADC driver and update the PWM driver (which
> unfortunately
> > also wraps around the nrfx driver instead of using the nrfx HAL API).
> Given
> > the two aforementioned reasons I am opposing to your suggestion, the
> driver
> > works well and we need consistent APIs. I f you need I can help you to
> > update your old code but I see no reason for us to regress. Feel free to
> > reach me through this e-mail address or through mynewt's slack (my handle
> > is mlaz).
> >
> > Thanks,
> >
> > Miguel
> >
> > On Wed, 3 Jun 2020, 16:42 Mo Chen, <sh...@gmail.com> wrote:
> >
> > > Hi dear development team,
> > >
> > > The newly released Mynewt (1.8.0) adopted a new version of nrf52 driver
> > > which is nrfx 2.1.0 (the last version was 1.7.0).
> > >
> > > However, the APIs have changed a lot. And the working code with nrfx
> > 1.7.0
> > > totally doesn't work anymore.
> > >
> > > I searched online and found no supported documents.
> > >
> > > I then reached out to Nordic for tech support and got the following
> > answer:
> > >
> > > Basically, they said the support document is not available and they are
> > > planning to backport the driver to 1.8.x in their own next version of
> > SDK.
> > >
> > > It looks like there are a lot of issues with the newer driver. If they
> > are
> > > backporting their own SDK, I suggest we do the same. So that the code
> > still
> > > works and will be well supported.
> > >
> > > Maybe we can upgrade the driver after the official support document is
> > > available and updated in their own SDK.
> > >
> > > Please seriously consider my suggestion, since this significantly
> affects
> > > our development progress and shown no benefits.
> > >
> > > Thanks,
> > >
> > > Below is the response by their tech support staff:
> > >
> > > ----------------------------
> > >
> > > Hi,
> > >
> > > As you figured, the nrfx 2.x API is not supported in the nRF5 SDK
> exactly
> > > because of the large changes in the SPI of the new nrfx_saadc driver.
> The
> > > driver have been completely rewritten to fix some issues seen with the
> > old
> > > driver. The new driver will be backported to nrfx v1.8.x in the next
> > > release of nRF5 SDK, but the legacy driver will still be available. The
> > > example code needs to be completely rewritten to support the new
> driver.
> > > Unfortunately, for now, we do not have any examples available for the
> new
> > > driver. I would recommend you to stick with the driver from nrfx v1.8.x
> > for
> > > now.
> > >
> > > Best regards,
> > > Jørgen
> > >
> > > -----------------------------
> > >
> > >
> > >
> > > Mo Chen
> > >
> >
>
>
> --
> Mo Chen
>
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Mo Chen <sh...@gmail.com>.
Hi Miguel,
Thank you for your replay and detailed explanation on the underlying works
done to adopt the newer version of nrfx drivers.
I really appreciate your offering help to have the code working.
What we need help with is the example ADC code posted on the Mynewt
official website which was based on Mynewt version 1.5.0 and it works on
1.7.0 but not with 1.8.0.
Link of the example code: the highlighted part gave errors while compiling.
#include <assert.h>#include <os/os.h>#include <string.h>
/* ADC */#include "myadc/myadc.h"#include "nrf.h"#include <adc/adc.h>
/* Nordic headers */#include <nrfx.h>#include <nrf_saadc.h>#include
<nrfx_saadc.h>#include <nrfx_config.h>
#define ADC_NUMBER_SAMPLES (2)#define ADC_NUMBER_CHANNELS (1)
nrfx_saadc_config_t adc_config = NRFX_SAADC_DEFAULT_CONFIG;struct
adc_dev *adc;uint8_t *sample_buffer1;uint8_t *sample_buffer2;
void *adc_init(void){
nrf_saadc_channel_config_t cc =
NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
cc.gain = NRF_SAADC_GAIN1_6;
cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
assert(adc != NULL);
adc_chan_config(adc, 0, &cc);
sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
adc_buf_set(adc, sample_buffer1, sample_buffer2,
adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
return adc;}
intadc_read(void *buffer, int buffer_len){
int i;
int adc_result;
int my_result_mv = 0;
int rc;
for (i = 0; i < ADC_NUMBER_SAMPLES; i++) {
rc = adc_buf_read(adc, buffer, buffer_len, i, &adc_result);
if (rc != 0) {
goto err;
}
my_result_mv = adc_result_mv(adc, 0, adc_result);
}
adc_buf_release(adc, buffer, buffer_len);
return my_result_mv;err:
return (rc);}
I then tried to modify it according to the new nrfx driver functions. The
modified code passed the complie however, the ADC value is always 0. Would
you please help check what was done wrong and how to make it work as it was?
The code I modified: commented the code with error and replaced by the
green highlighted code lines.
//nrfx_saadc_config_t adc_config = NRFX_SAADC_DEFAULT_ADV_CONFIG;
nrfx_saadc_adv_config_t adc_config = NRFX_SAADC_DEFAULT_ADV_CONFIG;
struct adc_dev *adc;
uint8_t *sample_buffer1;
uint8_t *sample_buffer2;
void *
adc_init(void)
{
//nrfx_saadc_channel_config_t cc =
NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
//cc.gain = NRF_SAADC_GAIN1_6;
//cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
nrfx_saadc_channel_t cc =
NRFX_SAADC_DEFAULT_CHANNEL_SE(NRF_SAADC_INPUT_AIN1, 0);
adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
assert(adc != NULL);
adc_chan_config(adc, 0, &cc);
sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS,
ADC_NUMBER_SAMPLES));
adc_buf_set(adc, sample_buffer1, sample_buffer2,
adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
return adc;
}
Thank you very much!
On Wed, Jun 3, 2020 at 11:41 AM Miguel Azevedo <mi...@gmail.com>
wrote:
> Hi Mo,
>
> If I understand correctly the new nrfx ADC driver is the one causing
> problems on the NRFX side. Our new driver doesn't wrap around the nrfx
> driver so it should be safe from whatever problems that new driver has.
> Instead we only use the nrfx HAL layer, which is proven to be a better
> option, since on nrfx driver code is more prone to chenges. Also the
> changes done on our ADC API were done so we would be able to roam towards a
> better ADC API, so we don't have to use nrfx datastructures and types on
> app code and so we can have ADCs working the same way(as much as possible)
> across different MCUs. Please take a look at this issue
> https://github.com/apache/mynewt-core/issues/2273 . We updated nrfx to 2.x
> at the time because we did have an incompatibility related to tinyUSB at
> that time, so we needed nrfx to be on a version higher than 2.0.0 (this was
> discussed on this mailing list last November). This led us to having to
> fully rewrite the ADC driver and update the PWM driver (which unfortunately
> also wraps around the nrfx driver instead of using the nrfx HAL API). Given
> the two aforementioned reasons I am opposing to your suggestion, the driver
> works well and we need consistent APIs. I f you need I can help you to
> update your old code but I see no reason for us to regress. Feel free to
> reach me through this e-mail address or through mynewt's slack (my handle
> is mlaz).
>
> Thanks,
>
> Miguel
>
> On Wed, 3 Jun 2020, 16:42 Mo Chen, <sh...@gmail.com> wrote:
>
> > Hi dear development team,
> >
> > The newly released Mynewt (1.8.0) adopted a new version of nrf52 driver
> > which is nrfx 2.1.0 (the last version was 1.7.0).
> >
> > However, the APIs have changed a lot. And the working code with nrfx
> 1.7.0
> > totally doesn't work anymore.
> >
> > I searched online and found no supported documents.
> >
> > I then reached out to Nordic for tech support and got the following
> answer:
> >
> > Basically, they said the support document is not available and they are
> > planning to backport the driver to 1.8.x in their own next version of
> SDK.
> >
> > It looks like there are a lot of issues with the newer driver. If they
> are
> > backporting their own SDK, I suggest we do the same. So that the code
> still
> > works and will be well supported.
> >
> > Maybe we can upgrade the driver after the official support document is
> > available and updated in their own SDK.
> >
> > Please seriously consider my suggestion, since this significantly affects
> > our development progress and shown no benefits.
> >
> > Thanks,
> >
> > Below is the response by their tech support staff:
> >
> > ----------------------------
> >
> > Hi,
> >
> > As you figured, the nrfx 2.x API is not supported in the nRF5 SDK exactly
> > because of the large changes in the SPI of the new nrfx_saadc driver. The
> > driver have been completely rewritten to fix some issues seen with the
> old
> > driver. The new driver will be backported to nrfx v1.8.x in the next
> > release of nRF5 SDK, but the legacy driver will still be available. The
> > example code needs to be completely rewritten to support the new driver.
> > Unfortunately, for now, we do not have any examples available for the new
> > driver. I would recommend you to stick with the driver from nrfx v1.8.x
> for
> > now.
> >
> > Best regards,
> > Jørgen
> >
> > -----------------------------
> >
> >
> >
> > Mo Chen
> >
>
--
Mo Chen
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
Posted by Miguel Azevedo <mi...@gmail.com>.
Hi Mo,
If I understand correctly the new nrfx ADC driver is the one causing
problems on the NRFX side. Our new driver doesn't wrap around the nrfx
driver so it should be safe from whatever problems that new driver has.
Instead we only use the nrfx HAL layer, which is proven to be a better
option, since on nrfx driver code is more prone to chenges. Also the
changes done on our ADC API were done so we would be able to roam towards a
better ADC API, so we don't have to use nrfx datastructures and types on
app code and so we can have ADCs working the same way(as much as possible)
across different MCUs. Please take a look at this issue
https://github.com/apache/mynewt-core/issues/2273 . We updated nrfx to 2.x
at the time because we did have an incompatibility related to tinyUSB at
that time, so we needed nrfx to be on a version higher than 2.0.0 (this was
discussed on this mailing list last November). This led us to having to
fully rewrite the ADC driver and update the PWM driver (which unfortunately
also wraps around the nrfx driver instead of using the nrfx HAL API). Given
the two aforementioned reasons I am opposing to your suggestion, the driver
works well and we need consistent APIs. I f you need I can help you to
update your old code but I see no reason for us to regress. Feel free to
reach me through this e-mail address or through mynewt's slack (my handle
is mlaz).
Thanks,
Miguel
On Wed, 3 Jun 2020, 16:42 Mo Chen, <sh...@gmail.com> wrote:
> Hi dear development team,
>
> The newly released Mynewt (1.8.0) adopted a new version of nrf52 driver
> which is nrfx 2.1.0 (the last version was 1.7.0).
>
> However, the APIs have changed a lot. And the working code with nrfx 1.7.0
> totally doesn't work anymore.
>
> I searched online and found no supported documents.
>
> I then reached out to Nordic for tech support and got the following answer:
>
> Basically, they said the support document is not available and they are
> planning to backport the driver to 1.8.x in their own next version of SDK.
>
> It looks like there are a lot of issues with the newer driver. If they are
> backporting their own SDK, I suggest we do the same. So that the code still
> works and will be well supported.
>
> Maybe we can upgrade the driver after the official support document is
> available and updated in their own SDK.
>
> Please seriously consider my suggestion, since this significantly affects
> our development progress and shown no benefits.
>
> Thanks,
>
> Below is the response by their tech support staff:
>
> ----------------------------
>
> Hi,
>
> As you figured, the nrfx 2.x API is not supported in the nRF5 SDK exactly
> because of the large changes in the SPI of the new nrfx_saadc driver. The
> driver have been completely rewritten to fix some issues seen with the old
> driver. The new driver will be backported to nrfx v1.8.x in the next
> release of nRF5 SDK, but the legacy driver will still be available. The
> example code needs to be completely rewritten to support the new driver.
> Unfortunately, for now, we do not have any examples available for the new
> driver. I would recommend you to stick with the driver from nrfx v1.8.x for
> now.
>
> Best regards,
> Jørgen
>
> -----------------------------
>
>
>
> Mo Chen
>