5 ms·

Contrarian view: these days I don't care how much a microcontroller costs. In quantities I'm designing for, it doesn't matter, and the cost is dwarfed by the co

by jwr 6y ago

Contrarian view: these days I don't care how much a microcontroller costs. In quantities I'm designing for, it doesn't matter, and the cost is dwarfed by the cost of my time writing the software. I've spent a lot of time dealing with crappy and broken vendor libraries, erratas, SDKs and toolkits where the vendor changes their entire strategy every year or so, and I'm tired. At this point I wrote (I thnk) three I2C libraries for various devices and systems (they're on github) — I should never have to do that! These days I mostly use Nordic chips — not only does almost every device I design need BLE these days, but the chips are fairly nice, the SDK is developed, maintained and supported, and there is a refreshing feeling of sanity. Sure, a BMD-300 or BMD-350 module with an nRF52832 will be $10 instead of $1 or $2, but I will save so much time and frustration, that it's definitely worth it! A vendor starting to officially support Rust might change my perspective, but to this day I haven't seen any other vendor take software as seriously as Nordic does.

MrBuddyCasino 6y ago
If only they made ble+wifi capable ones.
- jwr 6y ago
  I actually consider the lack of Wi-Fi a feature. I couldn't find a scenario where Wi-Fi would add value as opposed to BLE. It consumes more power, forces you to use TCP/IP, which pulls in lots of complexity without great solutions (you need to deal with pairing, security, etc), is more complex to set up... I could go on. Solutions like Thread are relatively recent (in fact I still don't know if licensing has become more reasonable). BLE and Bluetooth Mesh give you tons of functionality with low power, in a complete solution. Do I really need my devices to have an IP address? I guess this depends on what you're building, but in most cases this is about home automation, sensors, lighting, toys, etc.
  - TeMPOraL 6y ago
    Say I'm doing home automation and I decide to go with BLE and Bluetooth Mesh (I didn't realize this was a thing). What's the recommended chip/device/design to bridge this Bluetooth network with "regular" computers?
    - jwr 6y ago
      I'm planning to use a BLE interface plugged into a Linux computer (RPi or something similar).
    - H1Supreme 6y ago
      I can't speak to BLE/Mesh, but the Thread protocol (which Nordic also supports) has the concept of a "Border Router". Which is exactly what you're looking for.
    - rraghur 6y ago
      Can anyone here comment on espressif's ble mesh implementation? I saw a few demos d went through their sdk samples a year and a half ago but those were pretty raw then
dalbasal 6y ago
Good points all. I think this highlights how important adoption curves, cost curves and volume are to the overall context. Going from $1000 to $100 can put something into the hands of experimental, hobby or light-commercial projects. It can enable new applications. These can be fundamental to setting an overall direction. Going from $10 to $1 is neither here nor there in those contexts. Cost, as you say, is virtually irrelevant unless/until volume is very substantial. Volume is not usually part of the early adopter game, and price, below a certain threshold is only relevant at high volume. Price (below some threshold) may never be a meaningful factor for a microcontroller built to control commercial lighting systems or whatnot. The old habit is that price really matters. As prices dropped, this opened up entirely new uses for microcontrollers. Applications that would have been unreasonable at $100 became possible @ $10. That's not the dynamic anymore.
- londons_explore 6y ago
  A lot of businesses need to demonstrate that a product is margin-positive... That means if you are making a new gadget to send out to users, and hoping to make money on data collection, a subscription service, ad revenue, etc., the unit cost of the hardware is critical to the business case, even if it isn't much money overall. Try telling investors "we made this weather station, and we will make money by selling data to NOAA". The very first question will be "how much does each station cost", and "how much will NOAA pay". Nobody asks how many engineering hours you spent writing the code to fit on the microcontroller, because the assumption is that in any successful business that becomes irrelevant. Perhaps investors should accept "Each weather station costs $1000, but we think we can get it down to $10". But most investors won't believe you if you say that...
  - dalbasal 6y ago
    In some cases, I agree. But to be operative in this way, you must be talking about a very high volume. Millions of units, or close. My point was not that cost never matters, just that $1000->$100 is not the same as $10->$1. If your weather station startup is using $10 microcontrollers, getting that down to $1 is probably not important. If you are building 10 million weather stations, it is important, but this is a pretty specific scenario that doesn't apply often. We say something similar with PC pricing. The cost of a functional PC never stopped falling, but that stopped being as important once a certain threshold was reached. Projects like RasberryPi do take advantage of continued cost reductions, but Pi is marginal relative to earlier cost reductions cause an explosion of PC use cases.
SV_BubbleTime 6y ago
Interesting take because I see the Nordic HAL (nrfx) as a little heavy. Just tracing out toggling a GPIO it’s at least 6 function calls, the register is abstracted to some unknown pointer called reg or cb (control block, not callback), they don’t ever seem to intend anyone to trace through their driver. I like the Nordic chips, the event system and DMA is very good. But even their events are abstracted out where you aren’t allow access to the ACTUAL interrupt, you get to send a callback that on ISR they promise to call for you with a context pointer when they allow it (SPI) and when they don’t you are in your own (GPIO event callbacks). Yes, Nordic does take it “seriously”, but also heavy and complicated. I’d love to see a light implementation of their drivers instead of a HAL that is supposed to cover all models all time. No one actually switches chips like that.
- jwr 6y ago
  I'm also worried about nrfx. But I think it is the price you pay if you want to have a BLE/Mesh stack running. You can't really go all bare metal anymore. The way I see it is a spectrum: on one end, you go bare metal and write your own startup code, TPM0_IRQHandlers and implement core stuff in assembly (been there, done that). On the other end, you run Linux and who knows what's happening on your extremely complex system and whether it will run at all the next day. I think Nordic is trying to find a balance inbetween.
  - SV_BubbleTime 6y ago
    All true. Nrfx has some stupid decisions made in it. Like #if #define where if you don’t “enable” something the variables aren’t ever defined. Which means for me I have some SPI code that throws errors when SPI INST 2 isn’t enabled. My code is still valid, it’s just that variables that used to exist no longer do. Annoying. It doesn’t cost anything to “enable” the peripherals in preprocessor. It’s ~47 instructions in the example I just checked to get a return from nrf_gpio_pin_read(some_pin) that’s not good. It also reminds me that nrfx and nrf aren’t the same and when you need to use one vs the other is anyone’s guess. I do like their ASSERT() and use it for my own things. It’s report function is weak so i can overload it with one that reports to my other FreeRTOS threads. Nordic isn’t bad, but they went a little overboard with the HAL. I don’t want “one code” that runs on all chips poorly. I want chip specific code that runs great and yes I’ll have changes to make if I switch chips, but that’s life! Not only can’t you go bare metal with BLE and real complexity, but with a modern RTOS and knowledge of when you need a thread there is no reason to on chips with 48Mhz and 512kB Ram. FWIW, I do recommend Amazon FreeRTOS but investigate their LTS version they are moving to if you look into it.
throwaway9d0291 6y ago
I think Espressif takes software fairly seriously, I really like ESP-IDF. As for Rust support, they're working on adding Xtensa support to LLVM [0] and someone has used it to build Rust [1]. It's not official support for Rust but it's official support for LLVM upon which Rust is based, which works too. [0]: https://github.com/espressif/llvm-project https://github.com/espressif/llvm-project [1]: https://github.com/MabezDev/rust-xtensa https://github.com/MabezDev/rust-xtensa
- dls2016 6y ago
  I'm new to the microcontroller world and am using ESP-IDF on the recommendation of a friend. Espressif's example code is pretty good! I was leaning towards STM32, but the ESP32 seems to do everything we need for now... pretty nice device for $5 or whatever.
  - tlavoie 6y ago
    I'm also new, and picked ESP32 devices on recommendation of a colleague. I've had great fun, learning a ton to get going. Available libraries have certainly made the process much easier.
foldr 6y ago
Random question: do you happen to have any experience with any of the Dialog Semi range of Bluetooth ICs? (E.g. this one: https://www.dialog-semiconductor.com/products/connectivity/bluetooth-low-energy/products/da14531 https://www.dialog-semiconductor.com/products/connectivity/b...). They're ridiculously cheap but don't have internal flash. I haven't had occasion to try them out so far, so I'm just curious if anyone else has.
- jwr 6y ago
  No. For uC Bluetooth, I only used Nordic chips. For general-purpose uC I have lots of experience with TI MSP430 and NXP/Freescale Kinetis K and KL lines. Nordic has by far the best SDK and support of those. Having seen the complexity of BLE and Mesh, I would be very wary of using a vendor if I didn't see excellent software support. For example I wouldn't even consider Kinetis for wireless solutions, having seen how bad their SDKs were. Hardware is relatively easy to get right, software is hard.
  - foldr 6y ago
    Thanks, useful info.
- brusselssprouts 6y ago
  I do, their SDK is OK... but Nordic is the clear leader on tooling and SDK quality. The DA14531 has OTP memory for the final firmware and you can program and run out of RAM for testing. The firmware is typically mirrored to RAM anyway so this is pretty much indentical to how it works after programmed.
  - foldr 6y ago
    Oh, interesting. I had assumed that the usual dev setup would involve external flash rather than running the code from RAM. That sounds quite a bit easier. It seems like Nordic is the way to go unless you really need to shave every cent off your BOM cost. Thanks for responding.
pantalaimon 6y ago
nRF52810 is plenty cheap too
headgasket 6y ago
Great points. Another metric besides solid SDKs with support and community is power usage. In fact, some sort of benchmark of lowest state consumption, and total “MIPW” (million integer Ops per watt or something similar) would be valuable. BTW The new espressif s2 has some low power Sleep modes that should allow long running times on a battery( no BLE tho...:-/ ); I think that’s more of a hard design constraint that economics can’t change. Cheers!
mysterydip 6y ago
There's definitely a market for stable, long-term supported (in terms of documentation/email/phone, and manufacture) hardware. I'm working on a multi-year project with many subcomponents and I'm tired of vendors upgrading and obsoleting. Version x worked just fine for my needs. Version y gains me nothing and adds risk and time in testing.
finnthehuman 6y ago
I don't think that's a contrarian view. Engineering time vs. BOM cost has long been an understood trade-off in component selection. It's even becoming a common position in software-only projects to scoff at the idea of performance-oriented design decisions; without doing so much as some quick napkin math to evaluate impact to hardware cost. They just buy more AWS time.
tluyben2 6y ago
> In quantities I'm designing for, it doesn't matter, and the cost is dwarfed by the cost of my time writing the software For low quantities I do that too, but once you get into 100s of 1000s or millions of units, every $0.01 more profit takes out any developer cost. We are at a few dimes per mcu and it makes a massive difference compared to the previous mcu which was just over a $1; you can hire a boatload of developers for that and not even notice it. Offtopic curious: from your profile: C64 BASIC, C64 Assembly, Logo, Pascal, C, C++, Scheme, Perl, Common Lisp, Clojure, ? => assume you use c/c++ for these controllers? I'm c or arm asm (our current controllers have 24kb free) but always interesting if people try to actually use anything else than c/c++. Like you say; maybe Rust, but it doesn't fit too nicely in your evolution => ? imho.
- steveklabnik 6y ago
  Ferrous Systems is doing a ton with various Nordic ARM stuff and Rust; it seems to be going pretty well.

by jwr 6y ago

MrBuddyCasino 6y ago

If only they made ble+wifi capable ones.

jwr 6y ago
I actually consider the lack of Wi-Fi a feature. I couldn't find a scenario where Wi-Fi would add value as opposed to BLE. It consumes more power, forces you to use TCP/IP, which pulls in lots of complexity without great solutions (you need to deal with pairing, security, etc), is more complex to set up... I could go on. Solutions like Thread are relatively recent (in fact I still don't know if licensing has become more reasonable). BLE and Bluetooth Mesh give you tons of functionality with low power, in a complete solution. Do I really need my devices to have an IP address? I guess this depends on what you're building, but in most cases this is about home automation, sensors, lighting, toys, etc.
- TeMPOraL 6y ago
  Say I'm doing home automation and I decide to go with BLE and Bluetooth Mesh (I didn't realize this was a thing). What's the recommended chip/device/design to bridge this Bluetooth network with "regular" computers?
  - jwr 6y ago
    I'm planning to use a BLE interface plugged into a Linux computer (RPi or something similar).
  - H1Supreme 6y ago
    I can't speak to BLE/Mesh, but the Thread protocol (which Nordic also supports) has the concept of a "Border Router". Which is exactly what you're looking for.
  - rraghur 6y ago
    Can anyone here comment on espressif's ble mesh implementation? I saw a few demos d went through their sdk samples a year and a half ago but those were pretty raw then

dalbasal 6y ago

Good points all. I think this highlights how important adoption curves, cost curves and volume are to the overall context. Going from $1000 to $100 can put something into the hands of experimental, hobby or light-commercial projects. It can enable new applications. These can be fundamental to setting an overall direction. Going from $10 to $1 is neither here nor there in those contexts. Cost, as you say, is virtually irrelevant unless/until volume is very substantial. Volume is not usually part of the early adopter game, and price, below a certain threshold is only relevant at high volume. Price (below some threshold) may never be a meaningful factor for a microcontroller built to control commercial lighting systems or whatnot. The old habit is that price really matters. As prices dropped, this opened up entirely new uses for microcontrollers. Applications that would have been unreasonable at $100 became possible @ $10. That's not the dynamic anymore.

londons_explore 6y ago
A lot of businesses need to demonstrate that a product is margin-positive... That means if you are making a new gadget to send out to users, and hoping to make money on data collection, a subscription service, ad revenue, etc., the unit cost of the hardware is critical to the business case, even if it isn't much money overall. Try telling investors "we made this weather station, and we will make money by selling data to NOAA". The very first question will be "how much does each station cost", and "how much will NOAA pay". Nobody asks how many engineering hours you spent writing the code to fit on the microcontroller, because the assumption is that in any successful business that becomes irrelevant. Perhaps investors should accept "Each weather station costs $1000, but we think we can get it down to $10". But most investors won't believe you if you say that...
- dalbasal 6y ago
  In some cases, I agree. But to be operative in this way, you must be talking about a very high volume. Millions of units, or close. My point was not that cost never matters, just that $1000->$100 is not the same as $10->$1. If your weather station startup is using $10 microcontrollers, getting that down to $1 is probably not important. If you are building 10 million weather stations, it is important, but this is a pretty specific scenario that doesn't apply often. We say something similar with PC pricing. The cost of a functional PC never stopped falling, but that stopped being as important once a certain threshold was reached. Projects like RasberryPi do take advantage of continued cost reductions, but Pi is marginal relative to earlier cost reductions cause an explosion of PC use cases.

SV_BubbleTime 6y ago

Interesting take because I see the Nordic HAL (nrfx) as a little heavy. Just tracing out toggling a GPIO it’s at least 6 function calls, the register is abstracted to some unknown pointer called reg or cb (control block, not callback), they don’t ever seem to intend anyone to trace through their driver. I like the Nordic chips, the event system and DMA is very good. But even their events are abstracted out where you aren’t allow access to the ACTUAL interrupt, you get to send a callback that on ISR they promise to call for you with a context pointer when they allow it (SPI) and when they don’t you are in your own (GPIO event callbacks). Yes, Nordic does take it “seriously”, but also heavy and complicated. I’d love to see a light implementation of their drivers instead of a HAL that is supposed to cover all models all time. No one actually switches chips like that.

jwr 6y ago
I'm also worried about nrfx. But I think it is the price you pay if you want to have a BLE/Mesh stack running. You can't really go all bare metal anymore. The way I see it is a spectrum: on one end, you go bare metal and write your own startup code, TPM0_IRQHandlers and implement core stuff in assembly (been there, done that). On the other end, you run Linux and who knows what's happening on your extremely complex system and whether it will run at all the next day. I think Nordic is trying to find a balance inbetween.
- SV_BubbleTime 6y ago
  All true. Nrfx has some stupid decisions made in it. Like #if #define where if you don’t “enable” something the variables aren’t ever defined. Which means for me I have some SPI code that throws errors when SPI INST 2 isn’t enabled. My code is still valid, it’s just that variables that used to exist no longer do. Annoying. It doesn’t cost anything to “enable” the peripherals in preprocessor. It’s ~47 instructions in the example I just checked to get a return from nrf_gpio_pin_read(some_pin) that’s not good. It also reminds me that nrfx and nrf aren’t the same and when you need to use one vs the other is anyone’s guess. I do like their ASSERT() and use it for my own things. It’s report function is weak so i can overload it with one that reports to my other FreeRTOS threads. Nordic isn’t bad, but they went a little overboard with the HAL. I don’t want “one code” that runs on all chips poorly. I want chip specific code that runs great and yes I’ll have changes to make if I switch chips, but that’s life! Not only can’t you go bare metal with BLE and real complexity, but with a modern RTOS and knowledge of when you need a thread there is no reason to on chips with 48Mhz and 512kB Ram. FWIW, I do recommend Amazon FreeRTOS but investigate their LTS version they are moving to if you look into it.

throwaway9d0291 6y ago

I think Espressif takes software fairly seriously, I really like ESP-IDF. As for Rust support, they're working on adding Xtensa support to LLVM [0] and someone has used it to build Rust [1]. It's not official support for Rust but it's official support for LLVM upon which Rust is based, which works too. [0]: https://github.com/espressif/llvm-project https://github.com/espressif/llvm-project [1]: https://github.com/MabezDev/rust-xtensa https://github.com/MabezDev/rust-xtensa

dls2016 6y ago
I'm new to the microcontroller world and am using ESP-IDF on the recommendation of a friend. Espressif's example code is pretty good! I was leaning towards STM32, but the ESP32 seems to do everything we need for now... pretty nice device for $5 or whatever.
- tlavoie 6y ago
  I'm also new, and picked ESP32 devices on recommendation of a colleague. I've had great fun, learning a ton to get going. Available libraries have certainly made the process much easier.

foldr 6y ago

Random question: do you happen to have any experience with any of the Dialog Semi range of Bluetooth ICs? (E.g. this one: https://www.dialog-semiconductor.com/products/connectivity/bluetooth-low-energy/products/da14531 https://www.dialog-semiconductor.com/products/connectivity/b...). They're ridiculously cheap but don't have internal flash. I haven't had occasion to try them out so far, so I'm just curious if anyone else has.

jwr 6y ago
No. For uC Bluetooth, I only used Nordic chips. For general-purpose uC I have lots of experience with TI MSP430 and NXP/Freescale Kinetis K and KL lines. Nordic has by far the best SDK and support of those. Having seen the complexity of BLE and Mesh, I would be very wary of using a vendor if I didn't see excellent software support. For example I wouldn't even consider Kinetis for wireless solutions, having seen how bad their SDKs were. Hardware is relatively easy to get right, software is hard.
- foldr 6y ago
  Thanks, useful info.
brusselssprouts 6y ago
I do, their SDK is OK... but Nordic is the clear leader on tooling and SDK quality. The DA14531 has OTP memory for the final firmware and you can program and run out of RAM for testing. The firmware is typically mirrored to RAM anyway so this is pretty much indentical to how it works after programmed.
- foldr 6y ago
  Oh, interesting. I had assumed that the usual dev setup would involve external flash rather than running the code from RAM. That sounds quite a bit easier. It seems like Nordic is the way to go unless you really need to shave every cent off your BOM cost. Thanks for responding.

pantalaimon 6y ago

nRF52810 is plenty cheap too

headgasket 6y ago

Great points. Another metric besides solid SDKs with support and community is power usage. In fact, some sort of benchmark of lowest state consumption, and total “MIPW” (million integer Ops per watt or something similar) would be valuable. BTW The new espressif s2 has some low power Sleep modes that should allow long running times on a battery( no BLE tho...:-/ ); I think that’s more of a hard design constraint that economics can’t change. Cheers!

mysterydip 6y ago

There's definitely a market for stable, long-term supported (in terms of documentation/email/phone, and manufacture) hardware. I'm working on a multi-year project with many subcomponents and I'm tired of vendors upgrading and obsoleting. Version x worked just fine for my needs. Version y gains me nothing and adds risk and time in testing.

finnthehuman 6y ago

I don't think that's a contrarian view. Engineering time vs. BOM cost has long been an understood trade-off in component selection. It's even becoming a common position in software-only projects to scoff at the idea of performance-oriented design decisions; without doing so much as some quick napkin math to evaluate impact to hardware cost. They just buy more AWS time.

tluyben2 6y ago

> In quantities I'm designing for, it doesn't matter, and the cost is dwarfed by the cost of my time writing the software For low quantities I do that too, but once you get into 100s of 1000s or millions of units, every $0.01 more profit takes out any developer cost. We are at a few dimes per mcu and it makes a massive difference compared to the previous mcu which was just over a $1; you can hire a boatload of developers for that and not even notice it. Offtopic curious: from your profile: C64 BASIC, C64 Assembly, Logo, Pascal, C, C++, Scheme, Perl, Common Lisp, Clojure, ? => assume you use c/c++ for these controllers? I'm c or arm asm (our current controllers have 24kb free) but always interesting if people try to actually use anything else than c/c++. Like you say; maybe Rust, but it doesn't fit too nicely in your evolution => ? imho.

steveklabnik 6y ago
Ferrous Systems is doing a ton with various Nordic ARM stuff and Rust; it seems to be going pretty well.