"integration/nrfx/legacy" directory in SDK 15.0

[Rob Philip]

I am porting software built with SDK 14.2 to SDK 15.0

It looks like some files have been moved from "components/drivers_nrf" to "integration/nrfx/legacy". The first one I've encountered is nrf_drv_clock.c but I see that there are others. 

Have these files/apis/whatever been deprecated? Are there "new" ways to do the things provided in these legacy files? I notice that (for example) many of the examples still use these "legacy" functions...

Any insights would be helpful. 

[Jørgen Holmefjord]

Hi,

This is described in the release notes for SDK 15.0.0:

** Drivers and libraries **
 - The way peripheral drivers are handled in the SDK has been reorganized:
     - Replaced existing drivers with the "external" drivers from nrfx project. See github.com/.../README.md for more information on nrfx.
     - New drivers from nrfx are located in "..\modules\nrfx".
     - Drivers replaced by nrfx are removed from "..\components\driver_nrf".
     - A glue layer is added to make the nrfx driver compatible with SDK and the SoftDevice.

Best regards,
Jørgen

[Jørgen Holmefjord]

Yes, you can read more about this in the SDK 15.0.0 migration guide as well.

There will be more examples migrated to using the new drivers in future SDK releases. In most cases, it should be sufficient to change the names of function calls and configurations as described in the migration guide.

If you are facing any issues, please post your question in a devzone question and we will help you resolve it!

[Rob Philip]

I will have give that a try. I would have happily begun with the "integration" code, but it doesn't work for UARTE1

I get 

'NRF_UART1' undeclared here (not in a function); did you mean 'NRF_AAR_Type'?

'NRFX_UART1_INST_IDX' undeclared here (not in a function); did you mean 'NRFX_UART0_INST_IDX'?

when I try to define the UARTE1 structure 

SSI_NRF_SERIAL_UART_DEF(serial1_uart, 1);

[Jørgen Holmefjord]

There is no UART1 peripheral available, only UARTE1. Please make sure you set UART_LEGACY_SUPPORT 0 in sdk_config.h.

[Rob Philip]

Right - but it's a Nordic macro that is generating the error (i copied it to remove the "static")

Do you mean I should set UART_LEGACY_SUPPORT to zero or one? 

[Rob Philip]

I wonder if somebody there can build me an example for using UARTE1 on with SDK 15.0? The "legacy" shim layer doesn't compile/work for UARTE1, and there is no apparent documentation that I can find. I can figure it out, but an example would speed things up immensely.

[Nguyen Hoan Hoang]

It would probably better to use drivers from this library.  It is independent of the SDK and more importantly, it doesn't require 3000 defines to enable it.

example use case can be found on this blog. other UART example codes

[Rob Philip]

Unfortunately your code seems to be written in C++. Since I am working on a commercial product, using a toy language doesn't work for me.

The SDK code, once you're familiar with how it works with its many defines, is easy to use and most importantly written in C. My only problem was that they changed the SDK from 14.2 to 15.0 and my existing code didn't work properly - once I figured what they had done it was easy enough to adapt. 

Your drivers would get more attention if they were written in C rather than C++

[Nguyen Hoan Hoang]

Well, sorry to disappoint you but the drivers are both C and C++.  You can use either one.  Secondly C doesn't get more attention than C++.  Which language do you think Arduino & mBed are written ? Well, it's C++.  Thirdly language does not matter.  How you implement it does.

[Rob Philip]

Sorry. Your link only seemed to point me at .cpp files and I guess I didn't look carefully enough to see drivers in C.

I've been doing embedded work since 1988 and haven't ever seen anyone successfully use C++. Lots of people do "application" code on C++ and then interface to device drivers written in C. 

Anyway .. arguing about programming languages is like arguing about religion or politics and I don't discuss either.

[Nguyen Hoan Hoang]

Ah, an old lad like me.  Not many of us here.  Now you've seen one successful C++.  I started implementing Object design in since 1996.  It was in an SCSI to IDE RAID system.  It wasn't easy to do the switch.  I started learning C++ around 1988 but never able to really use it until that day.  As I said language is not the important.  You can do object in C too.  It is just a little more difficult.  Object programming is not wrapping all functions in a class.  It is a way of thinking.  C or C++ the same, C++ is not slower nor C is faster.  How you write the code that makes the difference.  As you can see Arduino and mBed use C++ but they are not object oriented design.  They just use C++ as language.