"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]

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.

[Rob Philip]

Thanks. 

[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.