Myth-busting article about radiation hardened microchips for space applications
habr.com
habr.com
To me the actual title more properly reflects a good summation of the article:
"The ultimate answer to a question if COTS chips can be used in space is “Yes, but”. There are many opportunities, but also many constraints."
The (very interesting) main thrust of the article aside, I see this kind of sentiment a lot and I don't really understand it. Arduino's just a common dev board, running a standard microcontroller, plus some hand-holding libraries (which you can dispense with if you want.) Is there any actual legitimate reason that they're not suitable for production use? Or is it really just "real-embedded-devs-don't-use-Arduino" ego flexing?
Most of it is ego flexing, and coming from the field of software engineering; we are trained these days to recognize and squash this behavior, but it seems to be alive and well with those working in the embedded field.
Honestly, after years of working with all types of software on all types of platforms, the Arduino platform is pretty nice. It gets you up and running very quickly and anyone with basic programming knowledge can start creating electromechanical devices, while it also allows you to write more advanced software (with essentially C++).
All of that being said: there are a ton of garbage 3rd-party libraries released for the Arduino, with garbage code, no documentation, no tests, no support, and gnarly tutorials. So I see where some resentment comes from, but once again; it's unacceptable ego flexing.
Scheduling, real-time characteristics, safety and watchdog mechanisms, and resource management pose hard engineering problems, and are often a very unique mix for each application, and again the Arduino libraries are not typically considerate of such concerns.
Add to that the usual pressures of keeping per-unit hardware costs low, to the tune of shaving a few cents off the BOM by choosing extremely constrained microcontrollers, and bending Arduino to fit those constraints becomes an unfavorable proposition.
The biggest benefit of Arduino as I see it is in reducing the barrier to entry for starting a hardware project because you can just wire software and hardware modules together for a proof-of-concept, but it doesn't do much for production.
To be fair, as other commenters have pointed out, Arduino isn't always a good solution. This is the same in all of engineering though.
At work we tend to use Arduinos for production tooling a lot. Our main product is decidedly not an Arduino though. We have lots of constraints though, from form factor to battery life.
> As an engineer, I feel insulted. I got the impression that it's mainly CS students for which basic circuit theory is beneath them.
Not neccesarily endorsing or denouncing the view, but I found it interesting.
There's a fine-line between receiving a comprehensive and correct answer to your EE/software questions vs. getting snidely berated for being an idiot.
(Software has the same issue in similar cases)
I'm happy they learnt the "right" way. But I've got a different set of requirements and I've come from the top down rather than the bottom up
The main part of Arduino is the hardware abstraction library. Especially for the standard stuff, like iwc, spi, ... this hal makes your code portable between different microcontrollers!
The alternative to Arduino hal is to use the vendor libraries. By doing that, you lock yourself in to the specific controller you are using right now. Also, the quality of the official sdks often enough is joke.
The next thing is the library ecosystem. A device driver library, i.e. to use a certain sensor, from the Arduino evosystem will work on every microcontroller with Arduino support, which is a very very long list.
The arguments against Arduino?
It's not _professional_.
Yeah, try the vendor library, sdk and ide and tell me that's better ...
You are relying on code that _somr guy in the internet_ wrote.
Jup. That's how the whole industry works. If your are using windows, you are using code some guy at the internet wrote. Did you ever get recourse from MS after you got a BSOD? Relying on code from other people is how we are able to get anything done. If you wrote everything from scratch, you couldn't ever ship anything. And hey, you got that code from that guy on the internet for free. So do the world and yourself a favour, review the code and upstream any improvements you find!
The IDE sucks.
So does the vendor IDE and nobody is using that stuff anyway. Use platformio.org
There is many situations where Arduino is a valid option.
I think Andrei Alexandrescu has a good idea that he presented in his talk about compile time introspection^[1]. That combined with something like ARMs SVD, but vastly expanded to include practically all hardware resources, might be the future. That way you could use exactly what you need.
Of course the embedded world changes very slowly, so if this every does happen I'll be long retired...
Also, as for the Arduino HAL, what a REAL embedded dev would do is implement their own platform-agnostic library and then implement it on every microcontroller they use and... oh wait they've just reimplemented the HAL.
But basically there's nothing about Arduino that makes it magically always bad. Start with your requirements spec. If a piece of hardware meets those requirements, and it's cheaper than the other options, use it. Even if it's Arduino.
https://processing.org/reference/environment/
It's an interesting story, but you're right that it isn't exactly professional:
https://arduinohistory.github.io/
I do like the MSP430 fork called Energia. They're 16-bit MCUs with a focus on low power usage, and some of them have non-volatile RAM:
The restrictions (power/computational power) are very high and reliability is the major concern for this kind of systems, making development patterns like that absolutely necessary.
Arduino is fine for production if you are doing something (relatively) simple terrestrially, but space is a totally different beast.
You csn get clones in volume -- the whole dev board etc -- from China for $2 each in volume. Though recrnt restrictions on China suppliers is a headache.
I haven't tried creating my own large run of a product based on Arduino, but I wouldn't go into production paying for a retail-boxed Arduino.cc dev system.
Plus the reliability of boards plugging into other boards, reliability of clones, etc.
You can implement Dropbox with an FTP server.
My comment was to highlight that there's the ease-of-use and quality-of-life aspect as well that needs to be taken into account.
Another aspect is: there are some poorly documented idiosyncrasies in the standard library. I was personally bitten by the fact that delay disables interrupts (makes sense from one point- it makes for more accurate delay timing), which means you can miss receiving some bytes from serial port.
Also, almost universal lack of low power mode support excludes the use in some contexts (very low power battery powered devices).
The default behaviour of restarting when USB serial port is opened (can be worked around by disabling DTR toggling when opening serial port, but not supported everywhere).
Production won't like that there are no guarantee that the Arduino board you'll be able to buy in 5 years will be exactly the same as now (oh, we changed the USB-serial from FTDI to some other, and now the PC software doesn't auto-detect the correct serial port).
It's absolutely that. So people can achieve results with less effort and hardship. This is a good thing for the users but bad for the gatekeepers.
Yes, the arduino user will have achieved results without understanding as much, or having as much formal training. For some reason that upsets those who have.
I worked on a radiation hardened processor chipset that had to be very rad hard - total dose, prompt dose, SEU all had to be addressed. That required measures be taken at the process, physical layout and architecture levels while making it performant and low power. Conclusion: very difficult, but possible, and some very interesting problems to solve (like how to mitigate the effects of an SEU in the instruction register at the moment of execution).
I also was peripherally involved with testing COTS memory chips for radiation hardness. They only had a modest total dose requirement. That was messy for the reasons mentioned in the article, like the fact that the manufacturers are always tweaking process and design parameters to optimize for the commercial DRAM market. So from one lot to the next the radiation hardness was unpredictable. Conclusion: costly, time consuming and not sustainable.
I wonder if the FDSOI back-charge technique could be cycled to provide periods of immunity, then "dump" the stored charge (while holding the chip in reset), then become immune again..
Fascinating stuff! Mostly over my head! Literally! :)
Also, this site was chosen for publishing because it was easy and because they actually give you some audience. Getting the same attention at Medium would be much harder, and a copy of this text, which I posted at LinkedIn, got something like 60 views. LinkedIn has a great publication editor, by the way. If you have an advice on some better place where I could publish scipop texts about microchips, that would be really appreciated.
The problems with satellites are mostly due to competely different factors, not the state of radhard IC design. For example, transition from imported to domestic EEE components is painful, as the demand is much higher than industry's capacity.
This is complete news to me.
Lead free solder was mandated by the European Union's "Regulation of Hazardous Substances" legislation, whch was drawn up by a bunch of ninnies with no understanding of biochemistry, nor mathematics, nor epidemiology.
Electronic devices are more reliable with tin-lead solder rather than Aluminum based solders.
What are you talking about? None of the common lead-free solders contain any Aluminium.
Furthermore the primary concern in regards to lead is during wave soldering during manufacturing (where you do get lead vapor; hand soldering and tinning is not really a problem) and during recycling later on.
Hobbyists have to worry about the fumes from flux instead, and lead free solder requires more flux.
To me, all this talk about lead being so much better feels a bit silly. As a craftsman, I can see that lead is nicer to work with, and makes for more pretty results. As a dad, I'm pretty glad that every electronic object isn't laced with lead - in fact, I'm glad about every measure full stop that reduces the industrial usage of lead. One of these things is way more important to me than the other.
Heating soldering wire isn't creating lead vapors like leaded gasoline does.
But anyway - it's not really the point. The point is, I can confidently say that some idiot burning a trash bin isn't going to scatter lead all over the local enivroment - ditto a house fire, or a car crash, or somebody dumping a computer in a stream.