Hardware driver support for FreeRTOS?

[maxv]

Hi,

Warning: This might be a bit of a rant.

Is there going to be an effort made to make more of the nRF52 hardware drivers compatible with FreeRTOS?

Hopefully constructive: I really am not enjoying dealing with the nRF chips on such a procedural level, as the API seems to be really fragile and I've spent too much time trying to workaround seemingly trivial issues:

1. The SDK focuses a bit too much on perfection (-Werror for unused variables and functions?) and is really unforgiving.
2. Integrating different examples together has left a lot to be desired, as everything has to be done essentially manually, including comparing Makefiles to see which pieces of library code and which components need to be added specifically to MY project Makefile in order to get a peripheral working with the provided drivers.
3. I'm pretty sure I'd love it more if there was a standard .a library for each hardware revision of chip, and I simply link against that. (Let the linker sort out what's not getting used, and encapsulate all of the PAN fixes into the library.)
4. The current rm -rf / build everything again methodology is pretty painful.
5. There is way too much use of the bsp.h BSP package, and the transition from doing development on an nRF52 DK board to a custom board is kind of painful, as most of the examples are littered with BSP code.
6. There's a ton of undocumented preprocessor magic that is happening, that takes a ton of digging with Jump to Source activities to understand.

Thanks, Max

[Susheel Nuguru]

Hi Max,

1. This is the first time I hear that someone is not happy with trying to be close to perfection. I agree that at the time of development this is not needed, but it is not hard to remove -Werror flag from your makefile if you do not like it. Yes, when it comes to compiling our rules are very unforgiving, no warnings. We consider that if there are warning, then the developer has forgot something. This is good rule when we are releasing something, but at the time of development, it can get annoying so you can comment it out.

2. How would you recommend for the Makefiles to look so that they are easier to be integrated with other examples? We are open for opinions and if it makes good difference, we can try to change them in the future.

3. We started with KEIL and got a good expertise in it. We tried to improve using packages and other combinations. Now we are putting more efforts into GCC and IAR support. Your suggestion is reasonable, I will convey this to the developer who makes this libraries. Can't promise anything here.

4. Good Point, I agree.

5. Agree with endnode.

6. I know there are lot of defines there and we are trying to get better with the documentation. Is there any specific module that made you spent lot of time digging?