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.

[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. 

[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.

[haakonsh]

Why can't you use nordic's BLE controller 'blob'? 

Do you insight into the inner workings of the stack, if so, why?

Is it size limitations? 

[Waldi1]

Because until now I wrote SENT, SPI, UART, I2C, USB and ETH bare metal. I would like to keep it that way, if possible, to have full control of size and speed of a firmware, even by inserting ASM code.
I don't understand why the vendor locks the hardware interface that way (not NordSemi, it looks promising, but until now I found all other vendors have only binary blobs, especially for WiFi). Is it due to hardware errors that are fixed within Blops?

[haakonsh]

Waldi1 said:

Is it due to hardware errors that are fixed within Blops?

That is often the case, but there's also the fact that silicon vendors have implemented proprietary [read secret] features that would be exposed by an open source stack. 
A BLE stack also has to be tested and qualified. Each release of our SoftDevice has gone through extensive integration, regression, and conformance testing, to the point that you'd need a prohibitive amount of resources to even come close to the code quality. It's also already optimized for speed and size, again, to the point where it really makes no sense to re-do it. 

You can ofc use the Zephyr BLE controller, that way you have full control, but at the cost of code quality. 

With the nRF53 you have the option of running the BLE controller and host on the network core. If you can accept a binary blob in the BLE controller on the network core, you have the whole application core to yourself. You don't need to run zephyr on it, you'd only need to implement the application side of the IPC — Interprocessor communication. 

[haakonsh]

@Waldi1 : 

You can check out the ble_app_uart example. It's the quickest/easiest way to stream data over BLE.