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.

[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