Cellular: Fix queue scheduling for bare metal

[kivaisan]

Description (required)

Cellular event queue was not dispatched at all in case of bare metal build. This commit fixes the problem by chaining cellular queue with shared event queue.

Summary of change (What the change is for and why)

Documentation (Details of any document updates required)

---

Pull request type (required)

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results (required)

[X] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers (optional)

@AriParkkila @AnttiKauppila

---

Release Notes (required for feature/major PRs)

Summary of changes

Impact of changes

Migration actions required

[ciarmcom]

@kivaisan, thank you for your changes.
@AriParkkila @AnttiKauppila @ARMmbed/mbed-os-wan @ARMmbed/mbed-os-maintainers please review.

[0xc0170]

CI started

[mbed-ci]

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_greentea-test

[kivaisan]

Greentea test fail does not seem to relate this PR.

[kjbracey]

This makes me nervous that you're going to cause large scheduling delays on the shared event queue (which has a guideline of <~100ms event duration) while waiting for an AT command response. Wasn't that the reason for having a separate event queue thread in the RTOS build in the first place?

Still, large scheduling delays are better than nothing working at all. And I suspect you may have occasionally ended up blocking the shared event queue waiting for an AT mutex anyway even in the RTOS setup.

[bulislaw]

We have some changes queued to backport (uhm it sounds easier than it will be) to introduce standard/high priority levels for the bare metal queue past Mbed 6. That should allow us to make sure higher priority work won't be blocked, would it mitigate this issue?

[kjbracey]

would it mitigate this issue?

Not if the events do "send AT command, block waiting for response", as I think they do.

Within-queue priority levels don't really help that much (in general), because the responsiveness is determined by the longest-running event on a queue.

You can't pre-emptively stop a slow low-priority event from running when someone queues a high-priority one.

Priority levels can be useful, but only if both high and low priority events have similar execution time. Eg in Nanostack we did the work to have long-running crypto (on slow 16-bit platforms) break itself up into fraction-of-a-second units, and schedule that repeatedly at low priority.

[0xc0170]

CI started

[0xc0170]

deadcee

Nice sha there , noticed while checking SHA for CI 😄

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts