Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
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, 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 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
> 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, wrote:
> >>
> >> >
> >> >
> >> > > On 10. Jun 2020, at 17:26, Mo Chen 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.
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 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 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, wrote:
>>
>> >
>> >
>> > > On 10. Jun 2020, at 17:26, Mo Chen 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.
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 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, wrote: > > > > > > > > On 10. Jun 2020, at 17:26, Mo Chen 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.
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, wrote: > > > > On 10. Jun 2020, at 17:26, Mo Chen 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.
Hi Andrew, Would you please attach the blog post you mentioned? Thanks, On Wed, Jun 10, 2020 at 10:23 AM Andrew Stevenson wrote: > > > > On 10. Jun 2020, at 16:51, Mo Chen 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.
> On 10. Jun 2020, at 16:51, Mo Chen 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
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
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 #include #include
/* ADC */#include "myadc/myadc.h"#include "nrf.h"#include
/* Nordic headers */#include #include #include
#include
#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, _config);
assert(adc != NULL);
adc_chan_config(adc, 0, );
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, _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, _config);
assert(adc != NULL);
adc_chan_config(adc, 0, );
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
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
Re: Backport nrf52 driver nrfx 2.1.0 to nrfx 1.8.x.
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, 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 >
