[Uptrenda]

I worked at a company that was using these chips to control doors. They're extremely cheap chips, but writing code for them is not pleasant. Documentation is lacking and the tools people use to write code for it suck. Props to the devs who helped put this together.

[rurban]

I write baremetal fw for those chips. No debugger, extremely bad stdlib which I rewrote, no qemu. Horrible modem interface. But still much more pleasent than Linux FW or raspi's.

They are cheap, last 10 years with a single battery, and do only what they need to do. Also secure. No crazy attack vectors. And easily symbolically verifiable. And I wrote tons of simulators and fuzzers for them.

[DoingIsLearning]

Let me flip this around, I am looking for ways to improve testing, specially now that I am mostly remote. In your experience, what targets have a stress-free experience with qemu emulation?

[rurban]

Working on it in my github rurban/qemu-stm32 fork. Checkout supported platforms for qemu and better renode. There you also have debugging interfaces.

Stressfree qemu support was only for my even smaller avr targets, the 1281. But AVR is crazy compared to the Cortex-M4. We switched to arm completely, no avr's anymore. Anyway, no need for qemu or other emulators, when you can easily write simulators. You just throw in some mmaps, the simulated libc, the UART, and networking. Much better than emulators.

[patricktlo]

Your simulations sound super interesting, I'd love to read more if you're willing to write about it!

[jononor]

Not the parent, but I wrote a little bit about this here: https://www.jonnor.com/2017/03/host-based-simulation-for-emb...

The key thing is to make the majority of the code portable enough to run on a PC. I find the best way to do that is to keep things data-oriented, using Plain Old Data type data structures and pure functions as much as possible. Alternative view: isolate out any device-specific pieces, like I/O into as small and simple pieces as possible. When one takes this mindset one realizes that even things that are considered as "device specific", like device drivers usually have a lot of logic that can actually be separate from the I/O. And by having a swappable I/O backend (say for I2C) one can actually test the vast majority of this logic on a computer. One should also have an implementation of the Hardware Abstraction Layer (HAL) that is "host", allowing to run on a PC, potentially with virtual inputs and outputs. This allows to run essentially all of the firmware on a PC. If one uses a embedded-friendly test framework, like Unity, then one can also run the same tests that is used on the PC on the device - to make sure that there is no difference when ran on host vs device.

Unfortunately, the code from embedded device vendors is rarely amenable to this, so that code can end up as "untestable" under this scheme. For them portability" is only considered between their own hardware devices, not to a computer. Then one has to trust that they have done their own QA. Which is usually not that great - looking at you ST HAL....

[patricktlo]

That's a great article, thanks for pointing me to it :)

[bsder]

> Documentation is lacking and the tools people use to write code for it suck.

Okay, I'm going to ask "Compared to whom?"

Nordic has been one of the better BLE chip manufacturers in terms of documentation, in my experience.

Most places use Keil tools directly from ARM. So, if programming these sucks, so does programming most embedded Cortex M4 chips. (No argument. Keil sucks. However, that doesn't mean that Nordic sucks any worse than anybody else).

And now you can program Nordic chips using Visual Studio Code.

[hemogloben]

Sure, comparing BLE specifically. And Nordics chip / peripheral level documentation is fine, but their software stack documentation (at least as of 3 years ago when I was last working on BLE stuff) is fine at best. They released a new version of the API every 6-12 months with lots of backwards incompatible changes (a new major version every time...), referenced examples from previous API versions (but didn't port them to the new version), and added tons of new poorly documented compile-time config options to every API version.

All told I figured out how to make a reasonably complex chain of bluetooth devices work (largely by reading the source and comparing against old version API documentation to figure out differences), so it definitely could have been worse. But to imply that just because the documentation is BETTER than the competition that it is GOOD?

No. Its fine.

[coupdejarnac]

It kinda helps to have an EE background for anything embedded. Doing embedded stuff has always been a gritty experience since I started around 2000. I find Nordic tools fine, and they've been getting incrementally better. Either the VSCode plugin or Segger Studio works fine for development, and the devkits work fine.

[BoorishBears]

Say what you will about the hardware, but ESP-IDF is the gold standard for me now

[floatboth]

ehh… It is pretty easy to use but there's way too much bundled stuff in there, you're always under FreeRTOS, and Wi-Fi support is all proprietary blobs (but that's unfortunately the case with every embedded Wi-Fi chip… unlike Bluetooth LE with has multiple fully FOSS implementations)

[BoorishBears]

I don't know what you mean by "way too much stuff", it's mostly use what you want. It's easy enough to disable any features you don't want with their sdk config stuff

They used to even ship a "No OS" SDK for the 8266, but the demand just wasn't there, FreeRTOS is pretty solid for the core competency of their product after all...

[jkelleyrtp]

In contrast, embedded Rust is quite a pleasant experience on the nrf line, including the 52xx series.

[floatboth]

nRF52s are definitely not extremely cheap, they're high-quality fully-documented dev-friendly chips with lots of onboard resources. If you want cheapest BLE, there's some utter crap from Dialog Semiconductor that comes with a proprietary SDK in ROM and one-time programmable (!!) memory for the application (external flash can be used in development).

And you DO NOT have to use the Nordic SDK, there are lots of better and fully FOSS options — Apache Mynewt, libopencm3, Rust nrf-rs…

[wcunning]

Any chance I can reuse one of these boards given that I have a few of these test kits? Or are the tools so bad that it's not worth it?

[logbiscuitswave]

An nRF52 dev kit is like $30. It’s probably not worth the time and aggravation to try to repurpose one of these COVID tests unless you’re really determined. Nordic is one of the better vendors - their tools and docs aren’t too bad.

[floatboth]

You also do not have to use their tools. Use Rust with nrf-rs, or Apache Mynewt (with a fully open source BLE stack), or libopencm3, or…

[netr0ute]

At that point, why not just use something like the original SoC from the Raspberry Pi 1 and use the plethora of Linux dev tools available?

[Renaud]

Really not the same beasts. The Cortex M4 microcontroller is self-contained with every peripheral it needs (including BT and wireless stack) and its power consumption is very small compared to a SoC.

Also, it's not booting Linux at all. For these simplish one-purpose applications, you don't want the overhead and it probably would need more than the 24k or RAM onboard the nRF52810.

They could be using Zephyr though as it supports the Cortex M4 (it's a linux-like RTOS that can be heavily customised).

[colechristensen]

Cost, power, board complexity, reliability.

Embedded development is much different than what a lot of developers are used to.

[viraptor]

Also availability. The more basic the chip, the easier / faster it is to get 1k of them. (or to find a perfect/close match requiring minimal changes)

[varjag]

That's only a recent thing really.

[colechristensen]

No, short term and long term availability of a part in volume has always been a part of circuit design. The current situation has been a unique extreme of this, but buying a million count of an electronic part hasn’t ever been an arbitrary off the shelf affair. How many a distributor has for immediate shipping, the lead time for large quantities, and the end of life plans were always a consideration. Before though the problems you were trying to avoid were more like not delaying production for six weeks because a part was out of stock or whether you could keep building this board for the next ten years.

[varjag]

I would agree for million (depending on market segment, you could be talking straight with mfg then). But we were talking about 1k, a tiny quantity as far as production rounds go.

[viraptor]

It's a recent thing on a world scale. But it's always been an issue and applies to anything you buy - the more sophisticated, the fewer items are stocked in warehouses. It's not that they wouldn't be available, it's that once you start ordering hundreds, the lead time will change from days to weeks at some point.

[varjag]

Hundreds is really a loose retail quantity if we talk about microcontrollers, the first real price break point is typically 1000pcs. Smaller quantities are cut and priced by distributors themselves.

In normal times, most products not marked as EOL would be available in tens of thousands with short lead times.

[numpad0]

Nordic nRF5x chips has community Arduino support(which is very nice to me!) if that's what you want.