I would be astonished if Garmin cannot (and do not) update the firmware in their embedded modules as part of a normal run-of-the-mill update.
The Garmin firmware is updated across all modules during the regular updates.
USFlyer, the world is nowhere near as simplistic as you make out.
It is completely standard these days to include firmware updates for submodules as part of an overall software update on the parent unit. You don’t necessarily need special hardware to update firmware in a module such as an AHRS unit.
I would be astonished if Garmin cannot (and do not) update the firmware in their embedded modules as part of a normal run-of-the-mill update.
edit missed the other posts saying the same thing!
I thought “big data” was the one on the black thingamajig…
Firmware is a special form (subset) of software. Therefore it is software.
But like a lot of IT terminology, what does and does not count as firmware is not clearly or universally defined. Is a bunch of C++ code written for a PIC or AVR “software” or “firmware”? If the later then does the same code become “software” when compiled for Windows? It’s largely a meaningless distinction.
But in any case, it’s a lot clearer what “firmware” is than what “the cloud” or “big data” is. Another two meaningless phrases invented by marketing people in IT companies.
Sorry USFlyer, I respectfully disagree. Our business makes control units for the auto industry, and these days the firmware can be updated quite easily, sometimes we have a dedicated port on the device, but more often it’s done over the CAN network on the car. Tesla update firmware over the air whilst the car is sat in the garage, and the owner need not know anything about it.
In general there is a bootloader that cannot be so easily re-flashed.
Firmware for a particular device is readily testable, but the bigger the system and the more different systems talk to each other the more difficult it gets. Software should be structured such that a database update cannot sabotage it, but these things are of course still possible.
One would have hoped that avionics has significant software testing; the testing in the automotive industry, particularly for safety critical parts, is substantial.
However, notwithstanding the above, I am a believer in “glass” instrumentation. As has been mentioned before the probability of software failure is substantially lower than vacuum pump failure for example.
Peter wrote:
This is complete nonsense.
Against all forum rules: +1
And if I may elaborate: firmware is indeed a subcategory of software, it is executable code, usually produced by a compiler and/or assembler. The difference is that firmware is permanently visible to the cpu, normally to be executed at boot time, whereas “normal” executables (such as your favourite spreadsheet, web browser, music/video player, &c) are loaded from disk to RAM to be there executed.
Software is ‘soft’ that means it can be easily and readily changed and may be more prone to ‘bugs’ because the changes are done more often. Firmware is NOT software
This is complete nonsense.
Software is ‘soft’ that means it can be easily and readily changed and may be more prone to ‘bugs’ because the changes are done more often. Firmware is NOT software. It is embedded code in a EPROM or PROM and is not committed to that state unless it is well debugged. To change firmware one must either replace the PROM, or reload the EPROM using special hardware. Microcode is even more static…it resides unchangeable in the design of the chip like a UART or a device controller (similar to what AHRS and ADHRS uses).
Software is found in general CPU machines with rotating or solid state disk and RAM.
There is no evidence that glass panel systems are ‘buggy’ and dangerous to use due to software issues. The code base for an avionics panel is well tried and tested. They have been around for decades now. New features are constantly being added by Dynon and Garmin and those may experience some issues, but those problems will not affect the basic six-pack of instrumentation on the panel.
Most things these days that involve “intelligence” have a processor, which is typically a PIC, Atmel AT-something, ARM (rapidly taking over the embedded scene AFAICT), and some extended temp range applications use the old 8051 cores.
The data and address buses don’t leave the package and there is no hard disk, but it’s all definitely “software”.
The susceptibility to bugs, and vulnerabilities to “not previously seen” external data, is still there.
The main positive factor is that the software probably doesn’t get changed for years, and there is little or no external data going into the code. For example my Sandel SG102 AHRS 100.000% definitely contains a processor (it has RS232 and ARINC429 serial comms to the aircraft, and interfaces to the MT102 fluxgate via RS422) but there is no serial (digital) data going into it, except when running the RS232 laptop config. The data going out of it, both analog and digital serial, is obviously OK. So if it worked for a bit, it should continue. But…
Search here for “1/2012” and read on… 
USFlyer wrote:
AHRS/ADHRS are embedded devices part electronics (discrete device chips) and part mechanical (gyros etc). They do not have a general CPU, RAM, disk. The firmware is chip based and not updated by anyone except the manufacturer. That would require removal of the device and shipment back to the factory…
I think you’re splitting hairs. You’ll probably find that most of these DO have a general purpose CPU, RAM and flash – but it’s all integrated into a single chip (the microcontroller) rather having an external CPU bus. But that ARM M0 core inside your AHRS is most certainly a general purpose CPU core. The real difference is the CPU bus never leaves the microcontroller die, but it’s still very much there, and still has RAM, flash ROM and peripherals attached to it.
