I have about 20 nRF52840 boards deployed around my house for various automations.
Personally I've found that for casual experimenting and software development, the official nRF52840 DK board is your best bet. Here in the US it only costs around $50, and all of the samples in the nRF Connect SDK support it natively. It's also pre-wired for power measurement.
My first board was the nRF52840 MDK from makerdiary. I ordered it from Amazon because it was cheap and it had one-day delivery. Most of the NCS samples do not support the makerdiary boards as-is. You can usually add a dts .overlay file to the sample to get it working, but it will take a bit of extra effort. Having to tweak device trees right off the bat adds another step to the learning curve and makes it harder to try out random sample apps.
Over time I migrated to using the DK for development (the integrated debugger + serial interfaces are super handy) and then using the USD $10 nRF52840 Dongle boards for deployment. I program the dongle boards using a knockoff J-Link probe from Aliexpress and run them off battery power. I eventually stopped using the makerdiary MDK since it didn't really fill a niche for me. But YMMV.
One nice thing about the board in this article is that it has an external SPI flash, which could be useful if the nRF52840's 1MB onchip flash isn't large enough for your application. I use A/B partitions to support OTA updates and it's pretty easy to run over 512kB per image if your use case is moderately complex.
Non-obscure architecture, one of the most used Core in the world (Cortex M4), true Floating point coprocessor, non-chinese firmware for BLE, if are not afraid of doing full certification it can also be non-proprietary Wonderfull documentation. Ready made modules can be obtained at the same price as ESP32. You support EU chipmaker.
The non-RISCV ESP's are a very wonky architecture, and while there is lots of ESP code out there, finding stuff that just works is harder than one may think.
Meanwhile, pretty much all NRF52840 stuff you will run into just works, and works reliably.
The toolchains and underlying pieces are also basically only supported by EspressIf (yes some work is upstream, but unlike ARM Cortex, you won't find a lot of help from others on Xtensa).
Real debugging of NRF52840 stuff is also easier to do because of this - lots and lots of debug tools work.
You will also get much better documentation out of Nordic.
Now, this is mostly about Xtensa, and almost certainly one of the reasons that they are moving the ESP's toward RISC-V.
I don't have enough experience with the newer RISC-V ones to give you a view there.
For my use case, Zigbee was vastly preferable to WiFi (or BLE). IP stacks are complex, buggy, and require a lot of configuration -- even moreso if you add encryption into the mix. Zigbee was the simplest tool for the job.
Some of the newer ESP32 boards do support Zigbee but I don't think they were available yet when I started my project. Might be worth looking into ESP32-C6 now.
As others have mentioned, power consumption is also a consideration. My battery powered devices consume about 25uA and should theoretically last 5+ years on two lithium AAA cells.
this is the big one for battery-powered applications
NRF52840 is specified to use 1.5uA when deep sleeping with RTC wake-up, while esp32-c3 is 5uA, which sounds ok, but is not the whole story.
If you try to build something low-power with ESP32 you'll find that it takes a lot of time and energy to go from deep sleep to being able to transmit, while the NRF SDK is designed with that in mind.
The NRF current consumption also includes the built-in voltage regulators -- this works from 1.7v to 5.5v, with a regulated output for peripherals, so all it needs is a battery and some passives.
On the other hand the ESP32 is much more awkward -- it needs 3-3.6v, so you're going to need an external regulator, and a LDO with the required 500mA output current is going to have a significant quiescent current, and even then the voltages are awkward for lithium batteries once you consider the drop-out voltage.
The tl;dr is that it's easy to get multiple years out of a coin cell with an NRF-based sensor, and that's just not happening with any ESP32.
I have an old wemos ESP32 board that for some reason, the CP2102 IC heats up if connected to a USB charger, but works fine when connected to a PC. Probably some design flaw? Also that specific board is no longer available so if you 3D print an enclosure or make your PCB around it, it becomes useless. Compare that with boards from nRF or ST or Pico which will be available for a minimum of 10 years. Pico W is the same price as a ESP32 board.
The Adafruit nrf52940 feather is a great companion to the DK, since it has the 10 pin header on it for SWD programming. When the cable is connected, the DK switches to programming the offboard (Adafruit) nrf52840 so it's pretty much transparent. So easy to develop on the DK and deploy on the Adafruit.
Hi, nice to see the vendor participating in the HN discussion (and hopefully gathering feedback from users) :-)
One of the main factors driving me back to the DK board was the fact that many NCS samples take advantage of the 4 switches + 4 LEDs on the DK board. Even the light_switch sample uses all 4 buttons to trigger different functionality.
The smaller boards don't have room for these switches and LEDs, so you'd have to tweak the program to work around the hardware differences. And that's a big investment if you just wanted to play around with the stock sample code for a few minutes.
A more general critique of the NCS samples is that many of them require a great deal of "polishing" before you can use them in a real project. It would actually be helpful if NCS shipped ready-made overlays that allowed them to run on smaller boards like the MDK and Dongle, in a configuration that's closer to what a shippable product would look like. As it stands, a company that wants to ship a Zigbee bulb or switch has to do a lot of work to convert the samples into something usable.
Maybe this is worth filing some PRs on the sdk-nrf github.
When I worked for Particle,
I acquired a lot of Xenons - a gen 3 device in their lineup, all of which are based around the nRF52, that is no longer supported. They provided a path to turn it into a nRF52 dev kit, which I started doing immediately. I’ve been fully sold on the Nordic stuff, recently having done work with their nRF9160 that has LTE-M and NB-IoT modem as well as GNSS. Like most (all?) Nordic chips, the I/O pins are all mapped based on a config (can’t recall if fuses or flash) so you can bring the I/O to the pin that makes sense. Once you add in DMA, the standard interfaces, an Arm Cortex-M33 at 64MHz, AT commands to control the modem, you have a very powerful system on a chip.
I think the greater hardware community is sleeping on Nordic right now, tbh. I know innovation does not happen super fast but when you compare this to a similarly priced STM32 that does objectively less, it’s no contest for me.
Another point: Nordic radio stack (wifi/bluetooth/ant) uses 5-15% of power that Esp32 chips do doing the same thing - if you are building anything battery powered that transmits often it makes a huge difference.
If you want more compute power, you would use the 5340.
Which is 514 coremark for the application CPU (4CM/mhz) and 244 coremark for the network core (4CM/mhz).
Also, if you do it on a CM/milliamp basis, the NRF blows the ESP out of the water.
The network core is like 101CM per milliamp.
Turning on anything related to networking on the ESP32 adds 40-50ma vs 4ma on the NRF5340.
The NRF also has a real FPU, and accelerates more crypto than the ESP32 (and in a more standard way).
It is highly unlikely you will need more than the 5340 for home automation.
On a 5340, you would mostly run stuff on the lower power network core, and use the high power app core for "real" work. That works really well, and is easy to make work.
On the ESP32, trying to clock the cores differently is hard, and trying to use dual core at all on anything other than ESP-IDF is ... an exercise in frustration.
So you spend a lot of time trying to make it sleep, which is ... also hard to get right (IE in a way that actually reduces power meaningfully)
Don't get me wrong - i do recommend ESP32's to people who just want to mess around with arduino libraries and don't care much about power or longevity.
But if you are trying to something serious, i'd pick the 52840 or the 5340 every day of the week.
This is why I specifically mentioned radio stack, not the whole chip.
Simply having ESP32 radio stack powered, not even transmitting, means a continuous additional (on top of everything else) power draw of 40~50mA. That is A LOT.
Their standard devkit is too large, their USB dongle has the problem of requiring to be connected to a computer, so I suppose it works better as a dongle than something you could mount on a breadboard.
I tinker with embedded on Rust, and I spend more time on ESP32s than on the various nRF52s that I have. I only saw MakerDiary's boards recently, I hope that this can change.
As an aside, hobbyist programming in a language/platform that isn't well supported has the side effect that you end up spending more time growing trees instead of chopping them for wood.
I spent a lot of time on ESP32 embedded rust - i submitted patches to bluetooth, re-ported Nimble, ported libraries, hacked on esp-idf-hal, etc.
There is more there in theory. But it's definitely treading on fresh snow in most places.
In that sense, using embassy with the NRF52840 was much easier to keep working vs either bare metal ESP32 rust or ESP-IDF based ESP32 rust. It's also debuggable. Good luck on the esp32, which is hard to debug even in C++.
Also, rust 52840 bluetooth is rock solid because it's soft-device based.
nRF52840 Connect Kit is an open-source prototyping kit designed for connected projects. It is built using the nRF52840 SoC, which has protocol support for Bluetooth LE, Bluetooth mesh, Thread, Zigbee, 802.15.4, ANT and 2.4 GHz proprietary stacks. It provides Arm TrustZone® CryptoCell cryptographic unit as well as numerous peripherals such as USB 2.0, NFC-A, GPIO, UART, SPI, TWI, PDM, I2S, QSPI, PWM, ADC, QDEC to support a wide range of applications.
Particle uses (used?) thread for its local mesh network stuff. When I worked there, one complaint that was commonly fielded was it’s presence on the already crowded ISM band (2.4ghz) and that it has a very limited range.
Zigbee suffers from some of this but the protocol is much lighter and payloads smaller, which means the MCU can spend more CPU time and energy decoding messages. If we can get a chip that combines cellular with Bluetooth and LoRa, that would be a killer IoT platform.
I miss Particle's mesh support. It worked great for me in my tiny environment. I tried to get a thread border router running using zephyr on a xenon with the ethernet featherwing, but couldn't get it working.
The Ethernet featherwing was tricky to get working in isolation, I can’t remmeber exactly what is was, but I recall there being some workaround in their Device OS firmware that is (or at least at the time was) open source.
The mesh network stuff was cool but suffered from a strange internal product decisions that made it useless for most applications.
First off, it was not created with a specific customer in mind. Most customers using IoT platforms want cellular connectivity, to allow for zero-setup on the customer or installer-side, and the ability to push OTA firmware updates. Mesh also used a Thread which was not super useful at the time. The vision was that you would be able to have a local network with one or more redundant gateways that ingress and egress of data through a few links.
This created another problem: monetization. In the gen 2 era of Particle where most customers with significant spend connected via cell network, Particle were able to charge a high margin rate and get considerable revenue as a result of their mvno business. This promise of a mesh network, where you could potentially reduce the number of internet connected devices to 10% of your original allocation, required rethinking of pricing as to capitalize on the devices that were connected to the mesh network but not acting as a gateway. What they did next destroyed any chance at widespread adoption. They created the most convoluted pricing systems where they were directly charging fees for a mesh connected device to be connected at all, as well as per network. Particle, whose OTA product famously worked extremely well coupled with a generous free tier (for device management) and that was easy to understand, decided to go generally available with a crippled mesh product, no customers for it, and extremely hard-to-understand pricing. Developers originally flocked to them because they could be certain of the service and features of each tier and that it just worked very well, but they destroyed trust with developers who were the genesis of most of their inbound leads.
What they should have done was to launch the products with a mesh communication library and charged for the gateways, using one pricing model if it was a stand-alone device and an upgraded one that would allow it to route mesh traffic through the internet. Oh, they also should have fucking gone with LoRa just like everyone was asking because 2.4Ghz at its tiny power is just outside of range of anything actually useful for the customers who actually wanted mesh networks
There is space another mesh product that is sanely designed and priced reasonably. I can’t see it coming from Particle, however. If anyone wants to start this, hit me up - my contact info is in my profile.
Squeeze in Li-ion charging management on the next revision and you've got yourself a deal. That said this appears to be open source but closed hardware? I can only find a high level schematic.
If you can live with having some less IO and flash, consider looking at the nice!nano. It's a nRF52840 board in Pro Micro form factor, originally designed for DIY wireless keyboards.
Cheers. While the nice!nano is great it's the additional gpio on the nRF52 I want so I can do 24+ key diode/matrix-less split builds. I might just attempt my own breakout when I get a bit more comfortable with KiCAD.
I've played with the SEEED XIAO NRF52840 board, which contains a built-in LiPo charger. Programming via Arduino IDE, though it supports other routes as well. It's worked well for me so far. I've ordered mine from Mouser.
Should be easy enough. I ended up flashing my nrf52s from a programmer loaded onto an OG arduino clone I had lying around so that I could keep the nRF-DK board dedicated to running dev builds.
To give you an impression about how much trouble that was: I also bought a few dedicated general purpose programmer boards (cheap maker stuff), but in the end the arduino approach felt more accessible. Iirc the difference was that the purpose-built boards had more assumptions about what exactly they'd be used for baked into their documentation and I don't know enough about all that stuff to see through them
Personally I've found that for casual experimenting and software development, the official nRF52840 DK board is your best bet. Here in the US it only costs around $50, and all of the samples in the nRF Connect SDK support it natively. It's also pre-wired for power measurement.
My first board was the nRF52840 MDK from makerdiary. I ordered it from Amazon because it was cheap and it had one-day delivery. Most of the NCS samples do not support the makerdiary boards as-is. You can usually add a dts .overlay file to the sample to get it working, but it will take a bit of extra effort. Having to tweak device trees right off the bat adds another step to the learning curve and makes it harder to try out random sample apps.
Over time I migrated to using the DK for development (the integrated debugger + serial interfaces are super handy) and then using the USD $10 nRF52840 Dongle boards for deployment. I program the dongle boards using a knockoff J-Link probe from Aliexpress and run them off battery power. I eventually stopped using the makerdiary MDK since it didn't really fill a niche for me. But YMMV.
One nice thing about the board in this article is that it has an external SPI flash, which could be useful if the nRF52840's 1MB onchip flash isn't large enough for your application. I use A/B partitions to support OTA updates and it's pretty easy to run over 512kB per image if your use case is moderately complex.