I haven't followed RT Linux but if Linux is to be industrialized, it absolutely must support realtime operation.
Linux ... is like a restless bull in a rodeo, it cannot be ridden more than 5 minutes, Linux is a bad beast for cowboys on the console, and it cannot be certified, not even for the lowest DO178B level E ... it's too "rolling" and completely out of control, in fact, there were several attempts (e.g. FNM Linux 2012, aka Linux revisioned) to do it ... all failed in avionics. Sorry.
But, in the Formula One Management (Automotive/FOM), we have a couple of Linux gears on the car. They are a kind of "routers with an antenna" that download data to the ground during the pit stop
Maybe they should use Forth like NASA ?
If you can elaborate a solid plan and a framework which allows the analysis of system designs *prior* to development, and *if* this does support an architecture-centric, model-based development approach throughout the system lifecycle, and if *Forth* can find its place in this making things better ...
... then -YES- you have a solid chance to convince AADL-guys to approve Forth
Your work is fascinating and so are your posts
I'm definitely not here to do convince anyone to use Forth, I'm a technician myself and have no understanding of the rigorous methodologies that highly skilled professionals use for mission critical areas.
I doubt that many do.
I remember when NASA accountants tried to close the Orbiter Software Testing Team because the Orbiter hadn't suffered from any bad software for a long period ... so they saw that department as a waste of money ...
NASA had two teams, the software writers and the software testers. Apparently the groups were kept totally separate and not permitted to fraternize.
I haven't followed RT Linux but if Linux is to be industrialized, it absolutely must support realtime operation.
Linux ... is like a restless bull in a rodeo, it cannot be ridden more than 5 minutes, Linux is a bad beast for cowboys on the console, and it cannot be certified, not even for the lowest DO178B level E ... it's too "rolling" and completely out of control, in fact, there were several attempts (e.g. FNM Linux 2012, aka Linux revisioned) to do it ... all failed in avionics. Sorry.
Several IFE (in flight entertainment) systems are Linux based (you can plainly see this during booting). While those aren't safety critical (obviously), I suspect they may still be DO178B-E (no safety impact) certified.
While those aren't safety critical (obviously), I suspect they may still be DO178B-E (no safety impact) certified.
Ummm, I have recently seen two projects for helicopters, both are sort of high-tech parking sensor which uses four LIDAR each with dual lightwave. This system has the highest IP-requirement for the hardware (waterproof, acid-fog proof, etc) even if the software is not critical in term of mission-critical because it's only used at the beginning and at the end of a mission, so someone proposed to convert an already existent (already tested and debugged) AXIM System, which is Linux based.
AXIM is not for avionics, but it has the same IP-class for the hardware. So it looked a good deal, and they tried somehow to make it Level D compliant. They worked hard and they didn't fail, and the unit got almost approved. But then AADL guys pointed out that ... well, a helicopter might use the LIDAR even during the mission, for example, to discover a high voltage cord or little objects during a low flight, so the system requirements got escalated to Level C, and the Linux proposal got again abandoned because not compliant and too expensive to be made compliant, especially because in the meanwhile the Company which produces the LIDAR sensor ... well released a new model with a new kernel driver which requires a new kernel (back porting from kernel v4.* to kernel v3.* is usually problematic, I mean not impossible, but it consumes a lot of time), and this would have requested more work to re-certify everything.
... this is what I mean with being too rolling.
The only commit I have ever seen about Linux is about a Light controlling system also able to play DVDs for the passengers' entertainment, and it's considered a sort of "aesthetic accessory" (level E) mounted inside a not-military helicopter
NASA had two teams, the software writers and the software testers. Apparently the groups were kept totally separate and not permitted to fraternize.
Yup, with only two partners, the company will break out at the first skirmish, while with three partners ... the third can mediate.
So, this is probably the main reason why we have QA and AADL guys. One of their duty is to address and readdress problems from devs to testers and vice versa, in a way that is not exactly democratic, but that it works
QA guys also interface our lawyers with the customers lawyers (which is a very hard job), while AADL guys interface managers and all the big-guys with money (lenders, which is probably the hardest job).
Maybe they should use Forth like NASA ?
If you can elaborate a solid plan and a framework which allows the analysis of system designs *prior* to development, and *if* this does support an architecture-centric, model-based development approach throughout the system lifecycle, and if *Forth* can find its place in this making things better ...
... then -YES- you have a solid chance to convince AADL-guys to approve Forth
Yup...
Now you may be able to use Forth in some very restricted parts of your system without having to go to this full extent, if you can prove that whatever the Forth part does is NOT critical (meaning amongst other things that it would be well isolated from any critical path). Good luck with that... (and anyway, if it doesn't do anything critical, it wouldn't really qualify as a replacement for any approved language...)
Interestingly, one obvious thing that could be in favor for Forth is the extreme simplicity of the language and the tools to compile or interpret it. Correctness for the tools themselves should be pretty straightforward to assert, whereas it certainly is no picnic for a typical C compiler (not even talking about C++ and ADA). Now of course there are many other aspects that would NOT be in favor for Forth though...
Toyota Unintended Acceleration is perfect example of
safety-critical coding gone wrong. Further reading would be Barr group
slides containing some analysis & comments. The best part is watchdog reset in a timer tick ISR (page 41).
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328. Personally, I include the entire set of Arduino compatible boards that can be used with the Arduino IDE + libraries. I bought an Arduino Uno years ago just to see what the fuss was about. Then I bought an Arduino Due (with cortex-m3) mainly because it had more RAM and I wanted to use it for data acquisition. Then I discovered Teensies. I have a half dozen Teensy 3.6 (cortex-m4) and just got a Teensy 4.0 (cortex-m7 @600MHz, 1MB RAM, 2MB flash.) I consider all of them Arduinos.
FWIW, I rarely use the IDE to write code; I use Notepad++ and use the IDE as a compiler. Is this a sophisticated and flexible programming system? Heck no. But it's entirely adequate for its intended purpose.
About me: I am an EE. Currently I spend about 1/2 of my time as an educator and the other 1/2 as a consultant. At my last full time job I designed embedded systems. I didn't program them though, and I typically let the software engineer pick the MCU. When I needed something in the lab with GPIO for control or data collection, I started by reprogramming an existing product; usually something with a 16bit PIC. Then I discovered Arduinos and never bothered trying to repurpose existing boards. I used them to control prototypes of other products that didn't include in on board MCU, or some that did have their own MCU but needed to be tested through some low level interface.
Again, I had piles of non-Arduino boards with analog and digital io at my disposal. All I had to do was program them. But when I found out I could spend $20 on a Teensy and cut my coding/debug time by an order of magnitude, I pushed all of those other boards into a box and put it on the shelf.
Did I or anyone else at that company ever consider incorporating an Arduino into one of our products instead of a $2 PIC? Of course not, that would be silly. Point is, I found good uses for both $2 MCU's and $20 Arduinos.
A project that I'm currently working on as a consultant involves reading a 3-axis accelerometer, doing a little DSP, then sending the result over Bluetooth. My first prototypes used the ADXL343 accelerometer (same that I will use in the final product) connected to a Teensy 3.6. With this I was able to perform both proof of concept and develop the DSP. There's only a few hundred lines of code and that include a command interpreter. The only thing missing is Bluetooth. For the commercial product, should I design in the Teensy coupled with more hardware for Bluetooth? Should I consider an STM32 because it's the new Z80? Maybe I should program it in Forth too...
No, I'll use a TI CC2640R2F. It includes a general purpose MCU, as well as a Bluetooth module, but the real reason I'll use it is because the tools and libraries available from TI will make programming the thing way easier than programming a PIC or STM32 from scratch to perform the same job. I expect that the time to write and debug the code will be reduced by a factor of 4 or 5. Hey, that's the same reason I used the Arduinos for prototyping!
Toyota Unintended Acceleration is perfect example of safety-critical coding gone wrong. Further reading would be Barr group slides containing some analysis & comments. The best part is watchdog reset in a timer tick ISR (page 41).
The timer ISR clearing the watchdog is fantastic stuff.
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328.
Right. Those who have definite opinion that "Arduino sux", most likely have no idea what Arduino *actually* is or simply don't care because they have divinity (like Forth) to worship.
Toyota Unintended Acceleration is perfect example of safety-critical coding gone wrong. Further reading would be Barr group slides containing some analysis & comments. The best part is watchdog reset in a timer tick ISR (page 41).
The timer ISR clearing the watchdog is fantastic stuff.
makes sure the interrupts are running
The users here - generally - arrive with burned fingertips, and fried components.
The - typical - ‘retail’ Arduino user gets hot & bothered if their project doesn’t do ‘what they wanted it to’ - despite lacking any hardware or programming experience to achieve their wish.
Ouch.
The - typical - ‘retail’ Arduino user gets hot & bothered if their project doesn’t do ‘what they wanted it to’ - despite lacking any hardware or programming experience to achieve their wish.
Ouch.
That is by design.
What is Arduino?Arduino was born at the Ivrea Interaction Design Institute as an easy tool for fast prototyping, aimed at students without a background in electronics and programming...
A worldwide community of makers - students, hobbyists, artists, programmers, and professionals - has gathered around this open-source platform
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328.
Yeah, like people who think that Linux == PC, or motor vehicle == internal combustion engine. Just because 99% do doesn't mean they
all do. In fact there is no guarantee that an 'Arduino' will have
any MCU in it at all! It's one of the charming things about it. Hardware agnostic, and so simple that anyone can just upload a sketch and... "No, not
that Arduino, you idiot!"
the problem I often see, is those players that purchase a ‘board’ that can blink a LED- expect it to solve their home automation, irrigation and robotics needs by throwing on some shields and a few buggy instructable libraries.
No concerns for power, compatibility or suitability to the role at hand.
This isn’t criticism of individuals, but simply a dim hope they might
Read the book before they criticise it.
I've learned a lot from reading books. I've also learned a lot from making mistakes. I'm grateful for both opportunities.
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328.
Indeed. In some senses, Arduino is a better "bare basics" library than most vendor's libraries. Because Vendor libraries are NEVER portable to other Vendors :-(
Whereas Arduino is portable to ... quite a few different architectures (sadly, it's weak point is that will tend to support only a couple of chips in each family. So there is SAM3X8E support via Arduino Due, but ... not Other SAM3 chips, nor SAM4, nor SAM7... Not without some effort, anyway.
Arduino is not really portable in the usual sense of the word. It’s a hack job. The header file is the only really portable so they rewrite the implementation from scratch for each platform. Each port has its own nuances. Read the source code for digitalWrite for example.
I think the point is that the code is the same. You say digitalWrite, well to achieve the same thing on many different platforms you will be using many different register names so code for one family will never wor on another.
That's the main problem though. Each hardware implementation is different. On AVR for example it does unholy things with PWM internally on digitalWrite. Other platforms it doesn't.
If one bitches let alone about different GPIO register names, he/she probably just should not program MCUs at all.
...and shall return to writing java applets.
Certainly not bitching about that. Bitching about the futility of hiding it all behind the same API call.
In fact hiding the differences where possible makes it more like java! And it has the same weird ass edge cases as java.
That's the main problem though. Each hardware implementation is different. On AVR for example it does unholy things with PWM internally on digitalWrite. Other platforms it doesn't.
Yes true. You will be reduced to the lowest common denominator. Your standard code will only be able to do as much as the least capable device. digitalWrite is a simple example of a universal function that with little work you can implement bare bones but as the periphery gets more complex it can be useful to have agnostic code but one has to understand that micro-controllers are that different that doing it this way severely limits your options.
Yes I was furious to find "weird shit" to be going on with 2 of the PWM outputs on the Mega having been unfortunate enough to pick those exact 2 channels that have the issue. I recently found that the UNO has an issue where the PWM channel disables itself when other channels are written to. I tried reporting it on the forum, but they wanted to see my code. So I think now that they are trying to support so many platforms bugs are creeping in.
java
I still have some love for my old TiniJava/S390 tiny board made around the year 2001, when Dallas semiconductors and Maxim tried to put a Java Virtual Machine on an 8051 MPU under steroids: 21bit on the address bus, 40Mhz clocked with a built-in ethernet, an FTP client/server in the firmware allowing the user to download your code via FTP. It looked futuristic for those years!
It was before Arduino, before everything, and Oh, you can program an 8051 in Java!!! And virtually a program that runs on your PC can even run there.
There was a technology called "jump51" under the hood, but seriously ... people have always tried to bypass the JVM to directly access the hardware, sometimes with a lot of assembly code directly called from Java. And things went even worse when they launched the S400 model, more advanced than the S390, faster, with more ram, more whistles, and bells, but on which "practically" you needed to hack the java code made for the S390.
So ... Java on MPUs ... what has been?
That's the main problem though. Each hardware implementation is different. On AVR for example it does unholy things with PWM internally on digitalWrite. Other platforms it doesn't.
Yes true. You will be reduced to the lowest common denominator. Your standard code will only be able to do as much as the least capable device. digitalWrite is a simple example of a universal function that with little work you can implement bare bones but as the periphery gets more complex it can be useful to have agnostic code but one has to understand that micro-controllers are that different that doing it this way severely limits your options.
Yes I was furious to find "weird shit" to be going on with 2 of the PWM outputs on the Mega having been unfortunate enough to pick those exact 2 channels that have the issue. I recently found that the UNO has an issue where the PWM channel disables itself when other channels are written to. I tried reporting it on the forum, but they wanted to see my code. So I think now that they are trying to support so many platforms bugs are creeping in.
Yeah don't even bother with bug reports. I reported one in the Arduino IDE which stopped it actually working using a USBasp for nearly a year. Had to drop back a version or two of the IDE. That was what finally killed it for me to be honest.
Then I discovered AVR-libc which is pretty good. I managed, within a week, to turn my entire codebase into interrupt and timer driven where the CPU was asleep nearly all the time. Doing that in Arduino was hopeless.
Also being GCC and make based I have extensive experience of that so it was just slinging shit together.
java
I still have some love for my old TiniJava/S390 tiny board made around the year 2001, when Dallas semiconductors and Maxim tried to put a Java Virtual Machine on an 8051 MPU under steroids: 21bit on the address bus, 40Mhz clocked with a built-in ethernet, an FTP loaded on the firmware, you downloaded your code via FTP. It looked futuristic for those years!
It was before Arduino, before everything, and Oh, you can program an 8051 in Java!!! And virtually a program that runs on your PC can even run there.
There was a technology called "jump51" under the hood, but seriously ... people have always tried to bypass the JVM to directly access the hardware, sometimes with a lot of assembly code directly called from Java. And things went even worse when they launched the S400 model, more advanced than the S390, faster, with more ram, more whistles, and bells, but on which "practically" you needed to hack the java code made for the S390.
So ... Java on MPUs ... what has been?
And JavaCard. I bet no one remembers that. I actually crapped on a toilet powered by Java once too at an exhibition. Impressive that the dunny had more brains than my phone at the time.