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 <miguella...@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, <shanyechu...@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
