It's not official support for Rust but it's official support for LLVM upon which Rust is based, which works too.
Available libraries have certainly made the process much easier.
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.
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.
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.
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.
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.
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.
You might struggle to get an AA cell in them, though.
Putting WiFi on a sensor makes no sense when you still have to run a power wire.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
I saw a few demos d went through their sdk samples a year and a half ago but those were pretty raw then
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.