LeSving wrote:
It has been running for two years now without a single incident of any kind.
I am sorry, but this statement alone only says that a condition that will trigger an error simply has not happened, yet. It in no way proves that the system is fault tolerant, or anything like that. Granted, it also does not disprove anything, but can hardly be considered an endorsement.
ortac wrote:
Also, the G5 shows TRK not heading, is it not set up with magnetic heading input?
The G5 is not offered as an HSI and is not interfaced with a magnometer so it can only derive track from the gps input.
There’s quite a lot to do even on a G5. I don’t believe the G5 has a COTS (crap off the shelf) general purpose operating system running on its SOC, it boots far too quickly for that. So someone at Garmin has probably written a low level OS for their small devices. That person probably has a different skill set to the people who do the higher level stuff on the device. Even a minimal tiny OS for a SOC can be quite a bit of work, about 18 months ago I did a big portion of one for a small ARM SOC on a contract because the guy who was making the system simply didn’t have enough time to do both parts of the system he was building. We didn’t even have a way of displaying on the screen at the time, I had to write all of the stuff to just make characters appear on the screen (while it’s not rocket science, it takes time to do properly, and we were pretty constrained on CPU cycles). The “datasheet” for the SoC was over 1600 pages long, and it was only a small device!
I get your drift, but I think it depends on where you are starting from.
At work, we are starting an ARM project. The thing runs at about 80MHz and is fiendishly fast compared to the “old” micros – even though the RISC CPU eats codespace like there was no tomorrow… 64k of old code takes up 256k on this one 
You get loads of software with the development kit. You get an RTOS. You get two TCP/IP stacks – one non-RTOS (runs as a state machine) and another for the RTOS (obviously preferred as a future path). I am not doing the initial integration and left it to a much more clever colleague who drops in on Mondays. It took him about 10 man-days to get it basically all working, to the stage where you can hang processes onto the RTOS and display stuff on the huge colour LCD. Boot-up time is perhaps 1 second.
There is no need for a box like the G5 to run embedded NT4 (like Avidyne do in some boxes) or linux (like nearly all consumer IT stuff uses; various ripoffs). It is just a straightforward bit of embedded code.
The whole of the project will be written in straight C. No assembler.
So I don’t think this is especially difficult. The AHRS stuff will be bought-in as a module, as will the GPS receiver probably (or the GPS will be lifted from another Garmin product).
Peter wrote:
64k of old code takes up 256k on this one
You might want to turn on the compiler flag to build with Thumb rather than arm32! Or otherwise, the old SOC had a the kitchen sink instruction set! (RISC doesn’t necessarily mean fewer instructions, it really means load-and-store architecture, it’s a bit of a misnomer. There are plenty of RISC ISAs that have more instructions than some CISC ISAs).
LeSving wrote:
That is detailed and deep knowledge and understanding about the process, or nature of the problem you want to solve.
Yes. Things become much easier when the developer also is an application domain expert. Which I would say it the reason Peter’s software works well.
alioth wrote:
(RISC doesn’t necessarily mean fewer instructions, it really means load-and-store architecture, it’s a bit of a misnomer. There are plenty of RISC ISAs that have more instructions than some CISC ISAs)
The “R” in RISC (“reduced”) and “C” in CISC (“complex”) refers to what each instruction does. Not the number of distinct instructions. It is often rather pointless to count the number of instructions anyway. Do you consider different addressing modes to make instructions different or not?
Well, bytes are cheap but when you get to the point where a TCP/IP stack on a Z80 is 50k and on an ARM 32F it compiles to 150k and the biggest FLASH you can get from that mfg for a few quid is 256k, then you need to think about it at least a little… but this won’t affect the G5 which sells for so vastly more than the component cost.
I still think the G5 is a nice one-man home project, taking about 1 man-year if you have to do it all from nothing, but know the hardware platform well and have the basics (RTOS, comms, SPI, ADC, LCD, etc) done and debugged
I’m surprised your TCP/IP stack is so much larger, which makes me think they aren’t from the same source code. The linked chip definitely supports Thumb (IIRC most of the Cortex-M only support Thumb) which is pretty compact. Also when comparing Z80 and ARM, you can often do stuff in fewer instructions on ARM because it has true general purpose registers (on Z80, there’s an awful lot of things you can only do with A or HL so you inevitably end up having quite a lot of code that’s just shuffling stuff between registers, and the ARM microcontrollers still have the barrel shifter so bit bashing tends to take a lot less code than on the Z80 where you might have a big unrolled section of rotate instructions). Unfortunately some of the vendor supplied libraries for ARM Cortex-M are pretty hideous. Fortunately, writing something more sane (and more targeted to your application) isn’t too hard…
I’ve done an awful lot of asm on Z80 (it was the chip’s 40th anniversary, we did a small expo on it at the University of Zaragoza during the week of Engineering and Architecture back in November – and as you probably know the ‘classic’ 40 pin DIP Z80 is still manufactured 40 years on, albeit in cmos) and a reasonable amount on ARM using Thumb, and given the choice I’d much rather write for ARM :-)
tmo wrote:
I am sorry, but this statement alone only says that a condition that will trigger an error simply has not happened, yet. It in no way proves that the system is fault tolerant, or anything like that. Granted, it also does not disprove anything, but can hardly be considered an endorsement.
That is true, but fault tolerant with respect to what? The system is build more like several dozens (100 or so) of smaller “pieces” that interfaces with other “pieces” and the surrounding. Each of those have been tested when we developed them, for all possible inputs and outputs. Fault tolerance and error reporting are built into each “component”, no data entering a “component” shall make an error. It’s also high level, running on a Linux RT OS and is multi-threaded, each “component” with it’s own thread, each thread with it’s own priority. If one thread should crash, it will simply try to restart the thread, or reboot if that doesn’t work. The OS itself might of course crap up, as well as the hardware, but so far they have not.
Hmm, when thinking about it I guess we actually had some kind of software developing process that addressed errors from the very beginning after all, but I didn’t think of it as such, only as ordinary engineering practice to make things work (the usual systems engineering way).
Most errors and bugs that can happen are interfacing errors, wrong or inaccurate specs typically. It’s on this systems level everything happens. It’s this part that requires detailed and deep knowledge of the process. “Built according to specs” is one thing, it’s just that when making something new, like the G5, 99% of the engineering is making those specs, making it all fit together, and changing specs as things develop. I just don’t see why that should require a large team unless the job is large (lots and lots of programming).
The plan was (and still is) to develop a more “commercial” version than the prototype version. A more “to the point” hardware and software solution, but I’m not so sure anymore. The customer is very happy, cost of hardware/software licenses is a non-issue, power consumption is a non issue, and keeping it high level enables non programmers to do and fix things.
Major news – Garmin have just received EASA validation of their G5 Electronic Flight Instrument FAA STC for certified aircraft, covering over 500 types!
The only change is that the installer must ensure the aircraft has a valid EASA type certificate.
