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.
RTEMS has been providing a real time, multi threaded, POSIX API on embedded systems for decades. It's got preemption, interactive shells, a libbsd port with networking, etc. It's popular in spacecraft, especially in combination with NASA's Core Flight System (cFS). I've run it on an STM32F4 and a Raspberry Pi.
BSP support is a little lacking in some cases. The raspberry pi is currently crashing on a call to fflush(). No idea why.
I really wish more people knew about it. As a matter of fact, I'll post about it here.
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.
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.
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.
Appreciate you posting. I would say that the adverse opinions from most people on the board stem from the fact that O&G has been intentionally gaslighting public discourse since the 80s and be helping oil and gas through cost efficiencies you are enabling them to maintain power and continue to pollute.
You might have a benefit to lowering the CI of each barrel minutely but really at the end of the day you are hurting the other industries that are trying to get a footing. That's why you are getting some negative feedback. Either through lack of knowledge of the history of the industry or intentionally painting a climate tech friendly perspective due to the new found interest at large of the general population / investing population.
To be honest, your homepage doesn't exactly give the impression you're a "saving the environment" company but rather you seem to be targeting businesses who wants to save costs. Here are some excerpts from your landing page (https://andium.com/):
- "At Andium, we’re saving companies millions of dollars annually, while increasing safety"
- "we offer an ecosystem of automated products and services that provide the next generation of remote monitoring capabilities"
- "Increasing site visibility while reducing onsite time, manual labor, and human error equates to major cost savings, and saving our clients’ time and money is in our DNA"
- "We've spent countless hours developing our technology and created the first-ever thermal imaging solution for safe, cost-effective tank-level management that has saved our clients millions at scale"
If you're truly in the same bucket as "problems like climate change and food insecurity" problems, you probably want to update your core messaging across your website
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.
The challenge in selling to O&G companies is they don't really care about climate initiatives. They do have concerns but its not their bread and butter there fore you have to package your sell in other ways such as cost efficiency.
> 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.
True my apologies for incorrect statement. The business you are in is IOT for O&G. Ensuring that flaring/leaks are monitored. That said that has some beneficial climate impacts but is mostly a worker safety issue and a regulatory infraction problem. A balancing act for sure (good products / reducing costs)!
Very late to this discussion, but O&G absolutely cares about sustainability and climate change ... because there are a ton of activist investors who care about it.
So they have to "put on their Sunday best" or they get shellacked in socially responsible index fund investor calls and press.
To be fair though, if you're targeting a business with marketing (e. g. a website) you probably want to speak to the first-order problems the business is having (e. g. cost savings, safety) not to second-order problems that those outside the business are most concerned with (e. g. climate change, food insecurity), even if your company is _also_ invested in reducing second-order problems.
speaking frankly, you shouldn't advertise your company on a job board for "problems like climate change and food insecurity" if those problems are just problems you wanna fix on the side instead of the main problems you're working on solving.
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.
Honest question, but doesn't enabling the Oil & Gas industries to reach peak effectiveness have the opposite effect?
What I mean by this, O&G right now is highly ineffective and to fit into regulatory limit they need to downscale operations just to have a "reserve". By allowing them, for example, to monitor the Flare and other things, don't you actually allow them to increase the production because now they have the data and means how to squeeze effectively into the limits?
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.
Cool product, I think limiting flaring is one of the more important ESG mandates in the oilfield right now.
Andium looks somewhat similar to Rebellion Photonics (recently sold to Honeywell), although the use case is different. Not sure if you’re familiar with their product.
Your company may not be actively bad, and maybe it's having a slightly positive effect, but it doesn't sound like it belongs in a list of companies trying to solve problems like climate change.
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.
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.
QWIIC is pretty nice to use from the wiring perspective. Not just for the plug and play nature but also the fine gauge of the wire in the cables. It makes it a lot easier to create little one off devices without going the printed circuit board route.
And with Adafruit also adopting the standard there are more options for 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.
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.