Hacker News Reader

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

[1]: https://github.com/MabezDev/rust-xtensa

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.

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.

> 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.

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

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!

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.

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.

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.

There are things I would build many of if they cost $2 instead of $20. Say a medium-resolution 3D volumetric mapping of temperature and humidity in my house becomes reasonable at $2/node, but not at $20/node. I think scale still applies at this level, but fewer hackers are thinking in terms of swarms. There are transformative applications at scale that could be interesting even to individual hackers, but scale is its own niche, just as IoT in general is a niche.

True, and I think that sitting back and thinking... we will come up with such applications. These aren't hard rules.

It's a matter of extent though, not absolutes. Hobby, experimental & light-commercial applications do not often need millions of units. If they don't, the difference between a $1 & $10 controller doesn't matter in the way the difference between $10 & $100 matters... in more cases than not. Other considerations (eg the dev already knows the more expensive platform, maturity, etc.) can easily override

High-volume swarm applications could change the reality. You need a nexus between low end and high volume. Swarms might be that. These aren't that common though, and "high volume and cheap" is usually a large company thing.

IE, if you browse around kickstarter, most microcontroller applications fit into OP's scenario. The cost of the microcontroller is not that operative. There are undoubtedly some exceptions.

Interesting idea. How would you power a swarm like that?

Great point :-)

I don't know how to build an $2 device. Especially given that in any small device I've designed, power management always took 30-60% of board space and device cost. You reach the upper bounds if it uses a Li-Po battery.

There is a big gap between powering a hobby device from a bench power supply and building an actual end-user solution.

EDIT: I'm reading the answers here and it's clear I did not clearly communicate what I meant. Taping a board to a bunch of AA batteries is not an actual end-user solution. Neither is hanging a couple of boards off a bunch of wires. I was talking about products, something you might expect to pull out of a retail box and use.

Those mentioning PoE clearly haven't designed a device that is powered with IEEE 802.3af-2003 :-) (I have, and I have the battle scars to prove it). PoE doesn't mean you can just connect the wires and call it a day.

In a way designing a $2 device is simpler, as the low price means a low component count.

Having built a Dash Button clone with an ESP8266:

1. Choose a microcontroller that will run on <3 volts, and power it directly from two AA batteries in series. You have neither the power budget nor the financial budget for anything more complicated than that.

2. Your microcontroller should spend 99.99% of its time in its lowest power sleep mode. When sleeping, the microcontroller should consume <10μA and the other, non-microcontroller circuitry should consume the same amount.

These are rock-bottom power levels, expect to remove any status LEDs, USB-serial converter/in-circuit debugger chips, and even linear regulators compared to a development kit.

You don't have to use an ESP8266 like I did - a more experienced guy might have chosen an MSP430 or something similar.

3. Given you can only leave sleep mode 0.01% of the time, i.e. 8 seconds per day, if it takes 1 second to connect to wifi, send a message and get an acknowledgement back, you can only do that 8 times per day. If you want to update more often, you'll need something faster to connect and send a message. This is why many smart home systems use 433MHz to a base station, rather than using wifi directly.

4. A $2 budget won't include a case until you're making fairly serious volumes. Repurpose something you were throwing out, or wrap it the circuit in electrical tape, or go over budget but declare victory as you could hit the target in larger volumes.

For cases, matchboxes are ~20p a go: https://www.ebay.co.uk/itm/SET-50-PLAIN-WHITE-EMPTY-MATCHBOX...

You might struggle to get an AA cell in them, though.

4. Just encase it in a blob of hot glue!

You can use ESP-NOW instead of WiFi, although I'm not sure how quickly that connects and how much power it uses. I think it's much less than WiFi, but do double-check.

I wonder if single twisted pair Ethernet that's being standardized with PoE might become popular for cheap sensor devices...

Putting WiFi on a sensor makes no sense when you still have to run a power wire.

I don't know how it turned out, but a friend of mine was talking about running a DC power loop round his house alongside the AC one. The idea was that he could pull 5-12v lines off that for powering things like motion sensors, or even tablets being used as control panels, rather than having the house scattered with USB wall warts.

What's potentially interesting is the 802.3bt PoE standard, power up to 55W or 90-100W. And data.

What PoE switches are compatible with that right now? I would love to wire the house with that.

I'm not sure. Though I see a whole lot of chatter from chip makers trying to sell solutions into that market. Sounds like they have figured out you can run lighting and and other IoT stuff off it.

If you think about it most current IoT stuff blows. You need power for the device. And then you're using shit like WiFi for data. And even worse shit like Bluetooth for configuration. Security is a big big problem because it's brittle and conflicts with consumers need for stuff to just work. PoE solves all of those issues.

Yes, even having my CCTV cameras on PoE is such a pleasure. Just one cable to worry about.

The single pair ethernet web pages gave me the impression that it is aimed at industrial applications - the connectors alone look like they would cost $2

https://singlepairethernet.com/en/

There are LoLin ESP32 boards that cost around $3 and will take a JST-SH 1S lipo connector natively (and charge the battery, IIRC).

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...

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.

> The old habit is that price really matters.

This is a good point. I actually always sort by price when selecting components — not just to be cheap, but also because less expensive components are generally more popular and widely used, which means they are better support, better availability and better longevity.

But — to all those who worry about price — I would suggest looking back and checking how many devices you actually built in the past? Was it singles, tens, perhaps hundreds? At these price points, how much would you save using a $1 uC instead of a $5 uC? Is it tens of dollars? Perhaps hundreds?

Now compare that to the cost of your time spent developing and maintaining the software. At any reasonable hourly rate you pick for yourself, you're probably better off going with the uC that has good software out of the box.

If you decide to build your devices in commercial quantities, that's when price optimization begins to matter, and somebody will care about fractions of a penny. But that somebody won't be you: going beyond single thousands involves a different set of skills.

Even in the 10s of thousands, these price differences should probably be a secondary issue for many commercial contexts... at least at the startup end of the game.

If you are producing a $40 microwave, smart bulb or somesuch... shaving dollars off component costs is operative. I think this supports your original point rather than detracts from it. This is the mass production game, a mostly big company game.

Microcontrollers have reached a cost point where the dynamic has inverted. The people who need to care about a new, cheaper-than-ever mc are large companies, not startups, hobbyists and niche product designers. There will be lots of exceptions, especially hobbyist use case... but generally.

There is such a thing as cheap enough.

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.

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.

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.

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/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.

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.

Thanks, useful info.

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.

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.

If only they made ble+wifi capable ones.

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.

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?

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.

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

I'm planning to use a BLE interface plugged into a Linux computer (RPi or something similar).

nRF52810 is plenty cheap too