Nordic Semiconductor Acquires Memfault
nordicsemi.com
nordicsemi.com
This is a very exciting day for us (after a very intense few months). We've known the Nordic team for years and could not think of a better partner to grow our platform.
Happy to answer questions, if you have them.
> The three founders of Memfault - CEO Francois Baldassari, CTO Chris Coleman and VP Developer Experience Tyler Hoffman – will reinvest 30% of their share sale proceeds in Nordic Semiconductor shares, totalling approximately USD 13 million.
https://n-fuse.co/devices/tinyCurrent-precision-low-Current-...
There's an unofficial Python library as well. I have power consumption tests running as part of my automated firmware test suite.
and godawful software. the SDK for their NRF52/3/4 is pure madness, i haven't even managed to set up the toolchain, documentation always out of date. They used to have another toolchain for the older parts, but good luck setting it up now.
I think that is genuinely the reason espressif is eating everyone's lunch. All the old players in the IC business have such inexcusably bad SDKs that the acceptably designed and documented ESP-IDF framework just makes the most sense to use. Why would I spend six weeks fighting with Nordic SDKs with their weird system-wide installation when ESP-IDF can be set up in five minutes isolated to your user directory?
Seriously, it takes longer to find the correct Nordic SDK installer than it does to git clone, idf.py install, ./export.sh
And Nordic's weird documentation web portal is just egregiously bad. Espressif puts it in a static HTML page with a selector for the framework version. It's simple, elegant, and fast.
I did like using the NRF52 once it was finally behaving, but the ESP is just so easy.
Sounds very similar to ST.
Also, no mandatory login walls for toolchains and datasheets gets them a lot of goodwill in my book.
Microchip tooling: download, double click, install, just works. Zero need for any framework, good bare metal support. a C project is an actual C project. Granted, if you use that MCC piece of shit you're in for a bad time, but going bare metal require zero effort, a single include file if you need to access peripherals, and you actually have documentation to do so.
ST tooling: sort of almost just works, more effort but you can still go bare metal with relative ease.
Current nordic: it's actually a zephir project, thousands of files to generate and compile. No options to go bare metal. (used to be possible with the older SDK, or so they tell me. Too bad i can't seem to be able to let a project compile with the old SDK, or set up the IDE for intellisense with the new SDK, but i haven't had enough time yet.)
Bonus: Espressif. At least their VSCode integration really just works. The peripherals are frustrating and severely bugged though and there can be supply chain issues, and that's the reason i'm looking at nordic for some BLE-enabled project, because the ESP32 parts won't cut it for this or that reason (usually the basic yet still bugged peripherals).
But i'm willing to put up with microchip's BLE modules again (i evaluated them several times over the years, always a disaster. But not the newer based on PIC32MZ, and the price have come down to be reasonable.) if the only option with nordic is the zephir monstruosity.
Let me write simple Makefile, give me thin layer over CMSIS called SDK and that's all I need. Don't make things harder than they should be, my project is simple, I don't need operating system for it.
It's true that the learning curve is very step, but their idea is reasonable.
The execution is ... not that good at this moment imo. It's nearly impossible to debug device tree "macro hell", the preprocessor is not designed to debug that, and they abuse the hell out of it.
Also i'm wondering why you dont want "RTOS", in Zephyr setup, your entry point is still old boring "main" loop.
Espressif's toolchain and SDK are in a git repo that you add as a submodule, or in a directory anywhere you want.
If I want to use microchip or Nordic on a new machine I have to go through this whole process of installing and configuring everything. My ESP projects simply involve a git pull and I'm done.
Nordic was a special pain in the ass because I had to hunt for the exact correct version of the SDK which was hidden away because it's a few versions old. If I need to do the same for espressif, it's literally just a git switch away.
Espressif is in an entirely different league from ST, nordNordic, et al. They're not even playing the same game. Espressif wants anyone and everyone to use their stuff and ST seems to actively hate developers and only want to work with companies buying tens of thousands of units. Like, ST cripples their USB programming tool to only accept 'genuine' ST parts. It's frankly disrespectful.
like "component" directory in cmake, or just call our "cmake function" to include this source files. Or modify this variable to add your custom dir.
Why they can't just stick with vanilla cmake ?
That's the reason i run Zephyr on esp32, no cmake nonsense from espressif.
But for the most part, I find it pretty easy to ignore and use a more vanilla style of cmake. It all works fine without the component stuff
Be Linux or don't be Linux, but don't be halfway between the two.
I have a lot more hope for PX5.
We have lower power bare metal systems, think AVR/STM stuff (in the 1Mhz to 50Mhz range with 128K or less of RAM) here FreeRTOS, no freeRTOS, custom driver code and some basic application code makes sense. For simple to very complex systems.
Then there's 1Ghz+ stuff with an MMU and 2GB+ RAM. Linux makes sense here.
Companies are now making chips 200Mhz+, 4MB RAM, with no MMU. This is precisely where Zephyr excels, you want a full networking stack? Switch that on. A file system, easy. Driver for some more complex thing? Maybe an SDIO radio? boomboom
Schematics: https://www.nordicsemi.com/Products/Development-hardware/Pow...
SigmaDelta gets pricy if you want higher speeds though. But it's possible.
Looks like the PPKII can do up to 1A.
Their newer SDK based on Zephyr RTOS, I didn't work with it, but I think it's mostly open source as well.
Strong agree with all those comments - it’s a great little tool at a great price!
The idea of Memfault is like Datadog for IoT stuff. The reality of Memfault is that everyone just uses it to push OTA firmware upgrades through the cloud, and capture stack traces on crashes. Sometimes you bolt on their metrics later, but 95% of the value is in OTA firmware upgrades and crash reports.
Nordic has started to assemble a juggernaut of a tech stack, and a collossal moat. They keep most of their Zephyr contributions outside the main source tree, in something they call the nRF Connect SDK. They've been developing vendor-specific extensions to Memfault's SDK for years.
The upside with Nordic is you get a complete embedded tech stack out of the box. The downside is that, if their stack doesn't doesn't offer what you need, you have to grapple with the incomprehensibly complex SDK in the entire industry. For some companies, it works great. For others, it's an attractive nuisance.
I don't know how much actually changes for either company with this acquisition. It probably isn't good news if you're ST, Infineon, or Microchip.
I'm assuming Nordic gives the company the support and reach their mission and discover a more workable business model.
This doesn't feel right to me. Back in the day when I started in embedded systems you would have to get it right before you shipped it. That had it's own problems of course, but at least you knew where you stood and if something worked well it would continue to work well until the hardware died.
Also I think the right word grammatically is continual not continuous. I suspect they changed it because continual software upgrades sounds terrifying.
Nordic chip is super impressive and power efficient compared to ESP32
Sounds great, but does it actually mean lock-in, in reality?