On Saturday, December 9, 2017 at 1:47:29 AM UTC+5:30, Dennis Lee Bieber wrote: > > > Prior to a lay-off, my last four years were avionics -- > fortunately > mostly maintenance work for existing software (since my prior 30 years > experience qualified as "mainframe number crunching", so the entire > embedded/real-time world was a new experience). > > No experience with use of an OS as Linux in such applications -- > from > what I could tell, general-purpose OS with real file-systems was only > approved for things like monitoring/logging systems wherein the loss of > the > system would have no effect on the operation of the aircraft itself. > > The rest tended to follow two concepts: > > A) operation out of Flash memory (similar to what one would find on an > Arduino, TIVA C, and similar boards). > > B) operation out of RAM with firmware loaded from Flash memory (closer to > BBx/R-Pi, except the Flash is not a general file system and is read-only) > > Both likely used some sort of RTOS providing the core of tasking > and > IPC (and the highest level having fixed time-slice assigned to tasks with > watch-dogs for overrun detection). In both, analysts created memory maps > defining what code/data is placed where in memory. > > (A) tended to have just one copy of the firmware/data in the layout; > (B) tended to have two copies allowing for swap-over if the boot-up checks > detected corruption (and reducing the odds of "bricking" when loading > updates into one copy) > > In both, CRC checks were run during booting before passing control > to > the real RTOS/application. Data regions tended to have CRC checks > performed > periodically during operation (one assignment involved a board with > expanded Flash memory -- where the person responsible for the CRC found he > had to run it in phases as the new data region was too large to be CRCd in > the allowed time-slot). In (B) the CRC was also run before loading the > code > into RAM. > > A CRC failure would result in the code going into a "halt" state > (usually implemented as an endless loop) or an attempt to restart the > processor -- while control of the craft went to the second flight > computer. > > Power-glitches (ever watch all the lights flicker on a passenger > jet > while they swap over from ground generator to engine generators?) trigger > state save, and later checks of RAM contents (the restart logic would > check > a timer -- capacitor bleed down -- to determine if it needed to do full > reboot or take a fast start path), if reading all the RAM does not trigger > a CRC error, control is passed to the application at the position saved. > While a glitch was considered ~10 seconds with no power, it seems some > boards could keep RAM stable for hours after loss of power. > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected] <javascript:> HTTP://wlfraed.home.netcom.com/ > > Thanks a lot for the insight. This is very interesting and something which I have seen in medical implants too. There were a lot of checks with the scheduler and also their queues which I don't seem to recall. Also as you have said I too have seen/worked mostly on microcontrollers with some type of qualified RTOS for such regulated devices. Also as you have noticed usually they relegated the Application processor with Linux for monitoring.
Although I have not explored it, I feel that the design can be made much better now with the availability of Cortex M4 in AM57x and the i.MX7 series. With this you have the Application processor and the microcontroller in the same die thereby shrinking the board to a huge extent and also making development much more compact and also simplifying the implementation of safety to the system. The safety checks can be implemented during boot-up can be done using the POST framework in the boot loader. I have yet to explore this deeply and the possibilities are good. -Gautam. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/57004cdb-b52b-464a-85e2-a60c65ae018c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
