Add documentation on using Device Management client in single-thread mode

[janjongboom]

This adds compatibility with MBED_CONF_NANOSTACK_HAL_EVENT_LOOP_DISPATCH_FROM_APPLICATION and significantly reduces memory, as the 6K nanostack event loop thread is no longer loaded. On K64F this yields:

Before:

Base (with memory tracing enabled)
===================================
Total Static RAM memory (data + bss): 78176 bytes
Total Flash memory (text + data): 426913 bytes

Heap size: 43701 / 117384 bytes (max: 50738 bytes)

After:

Total Static RAM memory (data + bss): 71520 bytes
Total Flash memory (text + data): 427020 bytes

Heap size: 43257 / 124040 bytes (max: 50286 bytes)

So about 7K less RAM. Unfortunately I cannot name the macro something better, as this is mandated by nanostack, and they don't include any configuration file where we can override the macro.

@screamerbg

[janjongboom]

I'm not sure if we should enable this by default, given that one of the design goals of the library is:

• Runs separately from your main application; it does not take over your main loop.

[janjongboom]

Note that this yields an increase in stack usage on K64F.

Old:

Stack size: 4040 / 6000

New:

Stack size: 4424 / 6000

[0Grit]

@janjongboom If the event queue supported event priority, could events for SMCC, and MCC not be posted to a global event queue?

[janjongboom]

@loverdeg-ep Interesting question (cc @geky), and yes I'd think so. I thought about moving these events to the global event queue (we already have one), but that would require increasing the stack size for that thread, which would defeat the purpose.

So I want this on the main thread, but the downside is that the user app also has to use EventQueue which is not always the case; which is why we can't make it mandatory.

[0Grit]

Besides the natural thread context of the processor I'd like to ditch threads completely. Prioritized events would enable either a single event queue or queue's that ultimately post to the global event queue.

This of course means needing to synchronize with any synchronous libraries but I appreciate the simplicity and path towards fully going async that it would provide.

[janjongboom]

@loverdeg-ep Yeah, I would not be opposed to this. I think it'd be better if we move this discussion to mbed-os repository though. Better visibility from core team.

Note that I have an example of doing Mbed OS 5.12 plus Pelion with barely any threads (only main, idle thread, timer thread) here: https://github.com/janjongboom/pelion-ready-plus-azure (driven purely by size requirements, but still).

[0Grit]

Good point, I should not be assuming everyone's visibility is full stack.

[screamerbg]

@janjongboom How would you like to proceed with this PR? For example, why not have MBED_CONF_NANOSTACK_HAL_EVENT_LOOP_DISPATCH_FROM_APPLICATION as a config key to SMCC (mbed_lib.json). E.g. non-thread-mode which defines macro MBED_CONF_NANOSTACK_HAL_EVENT_LOOP_DISPATCH_FROM_APPLICATION.

[janjongboom]

@screamerbg You cannot do that, because MBED_CONF_NANOSTACK_HAL_EVENT_LOOP_DISPATCH_FROM_APPLICATION is already a macro managed by Mbed OS config system.

[MarceloSalazar]

@janjongboom How would you like to proceed with this PR?

[geky]

Hi, may apologies for me taking so long to get to this.

Would an alternative solution be to provide both a low-priority and high-priority queue even if no rtos is present?