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 >
