Category for Cordio?

Meta
1

Should there be a top level category for Cordio?

Or will it’s maintenance be owned by PacketCraft?

1 Like
2

Hi Garrett,

Basically, the major maintenance effort would be on Packetcraft, so we don’t have a plan to create a new category for Cordio yet.

Thanks for asking.
Desmond

3

Here on Forums there are only three threads so far regarding CORDIO:

  1. This thread redirects from CORDIO to PacketCraft. This was the first place I heard about PacketCraft. I am a bit confused - should I use PacketCraft or CORDIO? Why there is no mention about PacketCraft on CORDIO website? Will API of PacketCraft be compatible with current mbed API or cordio API or will it itroduce yet another API? Is there any sort of architecture and roadmap available?

  2. Missing CORDIO BLE DFU (for NRF).

  3. Missing CORDIO BLE UART (for NRF).

MBED-OS switched to CORDIO as default stack. Now another stack shows up. The question is should I start with CORDIO or wait for another stack? What about self-compatibility?

Is even CORDIO production ready? Is it proper time to switch from Nordic SDK to ARM CORDIO BLE…? When clients are demanding results and work needs to be planned in short time is it feasible to work with CORDIO to get DFU and UART done yourself in lets say two months? My products are not experiments, they must work in real life. Some customers are already angry for some functional issues and delays. This results in measurable loss of cash and trust :frowning:

4

Agree completely with @cederom sentiments.

It especially hurts right now because the PAN team is busy with other stuff.

@mbedAustin

1 Like
5

Hi @cederom,

For clarity, PacketCraft is the company developing the Cordio stack now (it’s not yet a new stack :slight_smile: ). Therefore any bug in the stack should be reported to PacketCraft.
The Cordio stack is still supported in Mbed OS and our intent is to update it regularly. It’s production ready has been used in high-volume shipments for years.

This is something we should make clearer, I can see how confusion could arise.

Regarding your other points - the Nordic “UART” is a basic service to emulate a simple serial port-style link. It’s not a standard BLE feature so this implementation is Nordic-specific.

In terms of firmware update we understand this is an important feature and have it in our backlog, but we need to prioritize it against other roadmap items.

Don

1 Like
6

Thanks @donatien for the clarification!

You say:

Is the roadmap public? I saw on Github the different PR labels for up-coming versions but it’s not clear what makes the cut or not.

Is there public info available somewhere?

1 Like
7

Thanks @donatien for clarification that PacketCraft will not change CORDIO BLE API, so we can consider it stable and shift towards it away from vendor specific stacks even if it will take some more time to get/create more features.

I know that Nordic-BLE-UART is their own hack. But this is amazingly versatile solution. I suppose lots of people would be glad to have CORDIO-BLE-UART as a registered SIG service! Just as much as working CORDIO-DFU which is already part of the standard :slight_smile:

1 Like
8

The more time i invest in BLE with Mbed, the more i get confused about it… so i completely agree these should be made clearer:

  1. Does Cordio stack relate in any way with MBED BLE API? If yes how? If no, why are there 2 different methods for the same purpose that just leads to confusion?
  2. Which is considered to be more capable of these two?
  3. Which is considered to be more future proof in Mbed OS?
  4. Where can i find any Mbed OS relevant documentation/info about the Cordio stack?

Peter