Bluetooth bare metal implementation without binary blob

[Waldi1]

Hello,

I have a question regarding the nRF5340 microcontroller or similar.
Usually, when programming UART, I2C or SPI bare metal, one is using interrupts, register and buffers in RAM.
Even more complex transmission channels such as ETH with the TCPIP protocol or USB can be programmed bare metal,
for example data pages are allocated in the memory and their pointers are written to the corresponding registers in the µC.
Next step is then to implement the protocol.

But is it also possible to program the bluetooth module of a Nordic Semiconductor microcontroller bare metal?
Without binary blobs, just by using registers, interrupts and internal RAM?
I understand that the next layer (protocol) can be complex. However, I would really like to recreate the Bluetooth stack with interrupts and registers.

Many thanks.

[Hugo Habicht]

Hi Waldil.

I often think the same way when I see this Microsoft style SDK bloatware with thousands of functions, structures, parameters, constants (and not to forget all those lovely and totally useless, confusing and C-code obfuscating macros) that nobody needs where you can spend a day trying to get something working that you could write yourself in much less than 1..2 hours...

But I think what you are trying to do is not possible. As far as I understand the radio portion of the ICs is a hardware black box with another software black box called "softdevice" to interface with it. That is Nordic IP that they don't publish. I am not aware that radio register documentation is available. Maybe there is a low level access possible to the softdevice (read softdevice documentation) where you can implement the bluetooth protocol yourself. Not sure though why you'd want to do that apart from educational exercise.

Regards,

[Nguyen Hoan Hoang]

Yes, it is possible.  The IOsonata library did implement bare metal drivers more performance and simple to use than the SDK without all precompile hard coded defines jungle.  It can be used with or without softdevice.  The radio part however is not documented but you can have a look at the ESB and Gazell code in the SDK. It is recommended to use softdevice for the Bluetooth stack because it is certified. You can bypass the SDK completely and talk directly to the softdevice instead.  It gets worst when comes to the nRF53 series which forced you to use nRFConnect SDK Zephyr which is a nightmare.  Not only you got those defines jungle, there are also toolchain jungle and scripts jungle too. 

[haakonsh]

However, I would really like to recreate the Bluetooth stack with interrupts and registers.

I strongly advice you not to attempt to create your own bluetooth stack. It requires a lot of engineering resources to create a proper one. 

If however you're interested in creating a proprietary protocol using the 2.4GHz RADIO peripheral you're looking at a much easier goal. You can study the sample in NCS/nrf/samples/peripheral/radio_test.

-edit:
You can take a look at zephyr's BLE controller, it's open source, but lacks optimizations for the nRF series RADIO. Also the SoftDevice contains radio optimizations that are not available to the public. 

[Hugo Habicht]

Hi Nguyen,

thank you very much for the link, we were not aware that alternatives to that nordic sdk exists! Will certainly look into that.

And thank you for the hint with the nRF53 software, we will stay well clear of those devices in the future. I think the nRF52 is a nightmare already, totally bloated and simple things made complicated. The hoops you have to jump through to get a simple I2C sensor connected is unbelievable. To quote Donald Knuth: "They could have done better".

Regards,

[Waldi1]

Thank you for the answers. 
Building a bluetooth stack is not a primary goal, you recognized that correctly. 
I have a climatic chamber and a rotation rate table on which sensors are to be tested. 
The idea was to avoid the slip rings and transfer the data wirelessly. 
Maybe the bluetooth stack is more complicated than TCPIP (I've implemented a simple one here, too). 
The idea of ​​simply taking RADIO and implementing your own transmission is great. 
Disadvantage: you can no longer visualize the data on a cell phone.