SBC are easier to program for, you can trivially ssh in later and fix/update things.
Meanwhile mcu are… tricky.
For an example I wanted to measure co2 level.
It took me about a week to write it in raspberry pi zero w2. It captures data, stores it in sqlite, then every so often transfers to Postgres.
To do the same in esp32 took a couple months ( including storage and updates)
Ngl it sounds like you architected that wrong then? The ESP32 should've issued an API request to some other server that runs the sql and whatnot. That shouldn't take months. I've done that in like a few minutes with adafruit's stuff
It’s easy to do something that will work for weeks. It’s hard to do something that will last years.
For example, how does it handle wifi going down? Does it recover gracefully? Does it manage to save the data during downtime and reupload it all afterwards?
How does it handle updates through wifi? OTA updates are important for 10 devices deployed, but is not easy.
Honestly I would much rather handle that sort of project in an embedded environment and not something running linux.
esp-idf has answers for all those questions. You can hook up an SD card to buffer measurements when the network is down, reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected, and OTA updates are a solved problem with many different strategies to choose from.
>Honestly I would much rather handle that sort of project in an embedded environment and not something running linux.
That’s because you haven’t done it. There’s a lot more code to write in embedded case and lots of pitfalls to fall into.
>OTA updates are a solved problem with many different strategies to choose from.
No. Just no. Esp32 provides nice libraries to do update but acquisition/logic/code to use that is up to you. You still have to write a lot of code around the libraries and more importantly — debug and think of how to use it.
For example — let’s say you pushed an update that crashes early in boot (or other points). No problem, you’ve designed an AB update system so you just roll back to A.
Not so fast because A partition will try to update back to the botched update after roll back. Causing device to go into a update/crash loop and killing the esp32 in the process (flash has a limited number of erase cycles)
So you say “ok I’ll just store the update number in flash and only update 3x times before blacklisting”.
Well congrats now you gotta go write more code! And this time you get to have fun with nvs library which is great but not trivial. And once again if you make a bug you’ll face either a dead and recoverable device or dead for real device.
>reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected
>Generally, it is easy to write code in "sunny-day" scenarios, such as WIFI_EVENT_STA_START and WIFI_EVENT_STA_CONNECTED. The hard part is to write routines in "rainy-day" scenarios, such as WIFI_EVENT_STA_DISCONNECTED. Good handling of "rainy-day" scenarios is fundamental to robust Wi-Fi applications.
How well does your code handle “I’m connected to Wi-Fi but don’t have an IP?” Or it has an ip but can’t hit your server? Or it can’t hit dns? There’s a bunch of errors and transitionary state that just sucks.
Meanwhile you mention “just buffer the data in SD card”. Once again, write a pile of code, and then put a layer on top of it to store your data. This is a more straight forward problem but adding data to SQLite file and then sending it out is just so much easier.
And then you have to work with time. “Just buffering data” also requires keeping track of time because now you can’t use receive time as your capture time. Now you gotta write more code to synchronize the time on esp32 to your server which is a solved problem on Linux.
> That’s because you haven’t done it. There’s a lot more code to write in embedded case and lots of pitfalls to fall into.
I haven't done _this particular_ project, doesn't mean I'm not confident in working on embedded systems. So yes, I still stand by my statement that I would much rather do this sort of project in an embedded environment.
Your pessimistic "no. just no." style of writing doesn't convince me. Every problem you listed is an engineering problem you have to consider no matter what platform you're on, and none of this theoretical project is novel. There are solid approaches to each problem, whether it's in an embedded context or something like Linux.
I'm just saying that _I_ personally would prefer to handle it in an embedded context.
Meanwhile mcu are… tricky.
For an example I wanted to measure co2 level. It took me about a week to write it in raspberry pi zero w2. It captures data, stores it in sqlite, then every so often transfers to Postgres.
To do the same in esp32 took a couple months ( including storage and updates)