Migrating from SDK8 to SDK12: app_timer_create crashes

[Jarmo]

What is the difference between SDK 8 and SDK 12 related to app_timer? I have used it like:

APP_TIMER_INIT(
	APP_TIMER_PRESCALER, APP_TIMER_MAX_TIMERS,
	APP_TIMER_OP_QUEUE_SIZE, false);

err_code = app_timer_create(&m_timer_id, APP_TIMER_MODE_REPEATED, timeoutHandler);

and this used to work. However, with SDK 12 I had to change the APP_TIMER_INIT like:

APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_OP_QUEUE_SIZE, false);

And eventually, my code crashes at the app_timer_create() (I think). What could be the reason?

FEEDBACK: Could you please provide legacy support with your new SDKs, i.e. backwards compatibility with old SDKs. This way, you are generating huge amount of extra work for your customers. Like in this case, you could have been provided identical compatibility APP_TIMER_INIT macro and provide a new one with different name, if really needed. I am extremely frustrated updating our code base to match your new ideas. END OF FEEDBACK

[Wojtek]

This change is not a big deal and gives better memory flexibility than in older SDK. You have to declare timer by macro, not the old way.

Instead of using

static app_timer_id_t m_timer_id;

You have to use:

APP_TIMER_DEF(m_timer_id);

It makes the macro reserve exact amount of memory for all the timers instead of setting the limit by definition.

about feedback: It could be hard for them to give compatibility with older SDKs, when you are updating from really old SDK 8 to SDK12. I would personally prefer more simple SDK instead of growing overhead (now it is already huge! hard to compile some examples in keil!) - backwards compatibility would complicate it even more... I just keep my old apps based on S110 on the old SDK, and new ones using new SoftDevices on new SDK.

[Jarmo]

Thanks, I just found the same solution. This kind of macro initializers are a horror and cannot be used inside a structure. Often, I would like to put this kind of variables inside a structure to manage object oriented approach. This is not possible now.

What comes to your comment, staying on old SDK is not possible when hardware is updated from nRF51 to nRF52, like in this case. Yes, the SDK is huge and more complicated than it would need to be. Yet, you still lack clear and easy API's especially for handling the BLE. For example, compared to ST's SDK your SDK has much harder learning curve (though I wasn't dealing with ST's BLE). On the other hand, your code quality in terms of amount of bugs might be quite good.

Please, get rid of those acronyms. It causes just extra pain trying to find out what all those "ans", "bas", "bps", "cscs", "dfu", "dis", "gls", "hrs" etc really mean :(

[Wojtek]

About keeping them in a struct: you always can put pointer to timer in a struct. But i really see no use of that. These timers are static variables anyway, so there is no memory saving keeping them other way. I just put timers on the top of each file, which i treat like a class, so they are accessible only inside the file.

About acronyms: bps = blood presure sensor. if i see something like ble_bps etc i easily know what it is. They are just standard services defined by SIG. Unless you build your app on these sometimes over-complicated examples, there should be no confusion with those acronyms... I just create files for each of my service, like ble_my_service (ble-layer), and then app_my_service (application layer and handlers), and everything is clear that way. No need to use any of those weirdos

[Jarmo]

You did not get the point. When trying to get inside into your SDK you have to examine what the heck those acronyms mean, in order to understand if you need a particular component, or not. The same acronym-horror exists everywhere in your code, almost all API function names are using acronyms. Guess how much time a developer needs to use just to peek and poll what a single function name means? Instead, function names could be written clearly, by using clear descriptive english words. That is called self-documenting-coding.

[Wojtek]

For my understanding, when i see ex.:ble_bps_meas_s

I know that it is:

• ble
• blood pressure
• measurement struct

Everything is 100% clear.

But I may not understand Your problem correctly as I am not working on standard services, so I don't use that standard services example API... I think it would be really hard to name the function: sd_ble_gatts_sys_attr_set so one could understand it better, without knowing what is gatt server, and its system attributes. I am not really experienced embedded dev, but I found this API naming quite good.