We've done quite a bit of experimentation with adding preemptive multitasking support to non-hard real time software running on MCUs at my current company.
After a lot of head banging and dead ends, I've come to the conclusion personally that the embedded community could really use an implementation of the POSIX threading APIs or some meaningful subset thereof for various platforms. They're already standardized, well understood/used, and aren't that hard to implement on an MCU.
Of course, there would probably be some semantics that wouldn't make sense to or may not be possible to implement on MCUs, and there would be work required to support different cores, but these tradeoffs seem better to me than reinventing the wheel and probably needing to make the same tradeoffs at some point down the line with a ground up new API.
For Arduino, exposing POSIX APIs wouldn't be very user-friendly. But wrapping something more user-friendly around them seems like a maintainable and extensible path for the project and community.
It's a really neat piece of software - you're right that it does have the ability to configure your system, routing tables in particular.
The Tailscale agent (thing that runs on your machine) changes the system routing table (at least on Linux) and uses policy-based routing (marks packets destined for the "Tailnet" specially) to build the overlay network. Since everything is done at L3 in the OSI model, iOS and Android clients (in the form of an app) are also available without needing root (jailbreaking).
There are some things it can't do owing to the whole thing operating at L3, but it's a really awesome implementation nevertheless. And just to add, they aren't the first to build a product like this, but they do it incredibly well and the time to value for most users is extremely short, made even better by the fact that the expectation is that the time to value will be long(ish) and painful.
Hey HN! At Andium we're tackling a big problem (climate change) with an unconventional approach (reducing the damaging impact of fossil fuel emissions today as they're phased out for renewables over the coming decades). We have a big mission, but one whose impact we hope will outlive us for generations to come.
Our team is passionate about working on hard problems, emphasizes collaboration and mentorship, and biases toward execution and delivery. Above all, we truly enjoy working together and learning from one another, a key ingredient to our success so far given the (seemingly) infinite scope of the problem we’re working on.
Send me a note at raryanpur at andium dotcom to learn more or apply - look forward to connecting!
It’s great to see this getting more mainstream attention. As the article says it’s widely recognized as a big opportunity to have an immediate impact, but unfortunately hasn’t attracted as much attention as it warrants until recently.
Thanks for offering your perspective on this. Solving climate change is first about getting to net-zero GHG emissions, or as close as possible. There are many companies working to reduce the release of CO2 and CO2 equivalents across different segments of the economy, from ag to construction to transportation. Many are focusing on developing and deploying alternative energies and capture technologies, which are great and needed. Our approach is to reduce the CO2 and equivalent emissions produced by O&G today. This is different from the mainstream viewpoint for sure, but especially in areas like methane venting (see links in my other comments) there is a large opportunity for immediate impact.
The short answer is that nobody knows for sure ... yet. Regulatory bodies, NGOs, and ESG-focused activist and impact investors are actively developing frameworks and methodologies for total life cycle GHG accounting. [1] and [2] are a couple of examples in the US from around the time the Paris Climate Agreement was signed. This area is evolving quickly as momentum has built over the last few years for a global approach to getting to net-zero emissions. We keep a close eye on this and continuously evaluate the latest developments in the context of product development ideation.
> I think realistically they are in the business of making O&G cheaper to extract through efficiencies that gain some climate merit (but very little). It's more like the limited climate benefit is an add-on to core business.
Respectfully, this is not the business we are in, but I understand how our current messaging could convey it that way. That being said, there is a strong incentive to build products that both address climate pollution and reduce costs. It's a fine line and one that we think about constantly at the company.
Thanks for the direct and detailed feedback, much appreciated. We're planning a website revamp post our Series A which closed a few weeks ago - will definitely relay this feedback to our team.
Hi, Andium here. Definitely understand the skepticism about our work with the oil and gas industry and its impact on climate change. The high level is that the world doesn't know whether society has reached peak oil. Even if it has, oil consumption will continue to be a major contributor to planet warming gases (CO2 and CO2 equivalents) for decades to come. While regulation plays catch up and alternative energy usage continues to ramp up over the coming decades (something we support fully), we're working to reduce the carbon footprint of the oil and gas industry today. Our flare monitoring product in particular (https://andium.com/products/andium-flare-tracking) addresses the venting of methane at upstream wells, an issue that is gaining increasing regulatory traction in the US.
Oof, yeah. Have spent so much time trying to get multiple devices to work reliably on the same bus. As more devices are added rise and fall time of the data line also becomes a thing. It can be really hard to get things working reliably and handle edge cases. Have also found different host MCUs are able to handle signal errors varyingly well. On some chips I’ve worked with the I2C peripheral won’t recover from an error on the line until the MCU is completely powered down and back up. This poses its challenges for overall system reliability.
All this is to say I’m always impressed that SparkFun has managed to build a product line around plug and play I2C with their QWIIC stuff. I’ve never used it though, so not sure how well it holds up with multiple devices.
> (you trust that those around you have your best interests at heart)
So true - this tracks my experience exactly. What I find interesting is that sometimes high trust is necessary but not sufficient, and other times it's both necessary and sufficient, for great teams. I've never found a situation where a great team stays great (or arguably ever was in the first place) without high trust, though.
Yeah that would be really cool, can imagine this being useful for very simple if this then that logic in dealing with peripherals. e.g. handling a broader range of sensor input and peripheral interrupts without having to turn the core on to do processing.
These are some really great points for when it can be better to use microcontrollers over microprocessors/applications processors. Agree that generally simpler is better, and microcontrollers are simpler than Linux SoCs for many things (maybe not in getting from zero to main(), but after that).
I would add that it really depends on the problem you're trying to solve, though. Microcontrollers are disadvantaged compared to Linux SoCs for many workloads other than low power and low latency (i.e. hard and soft realtime).
Totally agree here - IMO MicroPython is great for simplifying embedded development for beginners and broadening the group of people who are interested in taking the plunge. Arduino had/has the same impact (both the hardware simplicity and C SDKs in the IDE). It's intimidating jumping into embedded if step 1 is "use the vendor-supplied startup code to enter into `main()`, then start writing baremetal C with so-so (and in some cases no) C lib support owing to being on a resource constrained platform." MicroPython doesn't offer a full Python standard lib implementation, but the standard Python syntax is definitely more accessible to a broader group of developers who may not be familiar with C or Rust.
OpenMV has used MicroPython to great effect. It's really impressive what they've done, especially in the realm of porting vision algorithms to constrained platforms like Cortex-M's.
Agreed, simpler is better, especially since OP is coming at this from the perspective that software is a means to end. Few things are more discouraging than realizing you're in way over your head in Linux land and have no idea what's going on, then not having the time to figure it out to boot (as OP suggests they don't).