Bluetooth bare metal implementation without binary blob

RE: Bluetooth bare metal implementation without binary blob

Waldi1 — Tue, 29 Sep 2020 08:52:52 GMT

That's the point with bare metal development. We do not want it simple way.

We need a detailed description of the registers and how to initialize the module. That means which peripheral clock, which GPIOs in which order etc. Which interrupts are triggered when, how do you initialize DMA for the module.

Understanding how the data flow is designed is also very important. You actually always understand this in the process when you read the register descriptions and examples, but it already existed before, when the developers wrote VHDL / Verilog, they had an idea of how the module should work and how the interaction between PHY, registers, interrupts, DMA and memory is. Why not write it down?

That's what bare metal is about.

RE: Bluetooth bare metal implementation without binary blob

haakonsh — Mon, 28 Sep 2020 07:42:21 GMT

@Waldi1 :

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

RE: Bluetooth bare metal implementation without binary blob

Nguyen Hoan Hoang — Fri, 25 Sep 2020 18:10:15 GMT

This where IOsonata library comes into play. It encapsulate the difficulties of the SDK to provide a simple way to write Bluetooth firmware. Here is an example of how much code you need to write to advertise an incremental number every second. The whole firmware code you need to write is 4 function calls and a configuration data. More details on this blog page.

/**-------------------------------------------------------------------------
@example	BleAdvertiser.cpp

@brief	BLE non-connectable advertiser

This demo show how to advertise an incremental counter in the manufacturer
specific data.  The counter increments every second.

@author	Hoang Nguyen Hoan
@date	Dec. 19, 2017

@license

MIT License

Copyright (c) 2017, I-SYST inc., all rights reserved

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

----------------------------------------------------------------------------*/
#include <string.h>

#include "app_util.h"

#include "istddef.h"
#include "ble_app.h"
#include "iopinctrl.h"

#define DEVICE_NAME                     "Advertiser"

#define APP_ADV_INTERVAL                MSEC_TO_UNITS(100, UNIT_0_625_MS)
#define APP_ADV_TIMEOUT_IN_SECONDS      MSEC_TO_UNITS(1000, UNIT_10_MS)

uint32_t g_AdvCnt = 0;

const BLEAPP_CFG s_BleAppCfg = {
	{ // Clock config nrf_clock_lf_cfg_t
#ifdef IMM_NRF51822
		NRF_CLOCK_LF_SRC_RC,	// Source RC
		1, 1, 0
#else
		NRF_CLOCK_LF_SRC_XTAL,	// Source 32KHz XTAL
		//NRF_CLOCK_LF_SRC_RC,
#ifdef NRF51
		0, 0, NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM
#else
		0, 0, NRF_CLOCK_LF_ACCURACY_20_PPM
#endif
#endif
	},
	0,						// Number of central link
	1,						// Number of peripheral link
	BLEAPP_MODE_NOCONNECT,	// Connectionless beacon type
	DEVICE_NAME,			// Device name
	ISYST_BLUETOOTH_ID,		// PnP Bluetooth/USB vendor id
	1,                      // PnP Product ID
	0,						// Pnp prod version
	false,					// Enable device information service (DIS)
	NULL,					// Pointer device info descriptor
	(uint8_t*)&g_AdvCnt,   	// Manufacture specific data to advertise
	sizeof(g_AdvCnt),      	// Length of manufacture specific data
	NULL,
	0,
	BLEAPP_SECTYPE_NONE,    // Secure connection type
	BLEAPP_SECEXCHG_NONE,   // Security key exchange
	NULL,      				// Service uuids to advertise
	0, 						// Total number of uuids
	APP_ADV_INTERVAL,       	// Advertising interval in msec
	APP_ADV_TIMEOUT_IN_SECONDS,	// Advertising timeout in sec
	0,							// Slow advertising interval, if > 0, fallback to
								// slow interval on adv timeout and advertise until connected
	0,		// Min. connection interval
	0,		// Max. connection interval
	-1,		// Led port nuber
	-1,		// Led pin number
	0,
	0,		// Tx power
	NULL	// RTOS Softdevice handler
};

void BlePeriphEvtUserHandler(ble_evt_t * p_ble_evt)
{
}

void BleAppAdvTimeoutHandler()
{
	g_AdvCnt++;

	BleAppAdvManDataSet((uint8_t*)&g_AdvCnt, sizeof(g_AdvCnt), NULL, 0);
	BleAppAdvStart(BLEAPP_ADVMODE_FAST);
}

int main()
{
    BleAppInit((const BLEAPP_CFG *)&s_BleAppCfg, true);

    BleAppRun();

	return 0;
}

RE: Bluetooth bare metal implementation without binary blob

Andres — Fri, 25 Sep 2020 17:50:59 GMT

For those of us that prefer bare metal, Nordic has provided the "nrfx" modules. These headers and source files help a lot to get code up and running with minimal bloat. I wish the same concept can be applied when writing a Bluetooth application. In the case of a Bluetooth application you want to start with one of the Nordic examples and pair it down to the essentials. Unfortunately, this is extremely difficult since the examples are really tied to almost every part of the SDK. The file dependencies get out of hand quickly and then you spend days just to get the basic example running in your code base.

In my view the SDK and its examples are good to get you started with nice looking demos but when you really try to do production code ... well good luck.

RE: Bluetooth bare metal implementation without binary blob

haakonsh — Thu, 24 Sep 2020 11:33:20 GMT

[quote user="Waldi1"] Is it due to hardware errors that are fixed within Blops?[/quote]

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.

RE: Bluetooth bare metal implementation without binary blob

Waldi1 — Thu, 24 Sep 2020 10:16:15 GMT

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?

RE: Bluetooth bare metal implementation without binary blob

haakonsh — Thu, 24 Sep 2020 09:40:18 GMT

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?

RE: Bluetooth bare metal implementation without binary blob

Waldi1 — Thu, 24 Sep 2020 08:42:30 GMT

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.

RE: Bluetooth bare metal implementation without binary blob

Hugo Habicht — Thu, 24 Sep 2020 07:44:24 GMT

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,

RE: Bluetooth bare metal implementation without binary blob

haakonsh — Thu, 24 Sep 2020 07:12:20 GMT

[quote user=""]However, I would really like to recreate the Bluetooth stack with interrupts and registers. [/quote]

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.

RE: Bluetooth bare metal implementation without binary blob

Nguyen Hoan Hoang — Wed, 23 Sep 2020 20:36:42 GMT

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.

RE: Bluetooth bare metal implementation without binary blob

Hugo Habicht — Wed, 23 Sep 2020 18:53:27 GMT

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,