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