Can BeagleBone Black's OS booting time could be a problem in a harsh vibrational environment?

GoogleGroups
1

Hi all,

I’m a beginner in the microprocessor environment, and my job is to find the “best” microprocessor board to be able to perform some data monitoring inside a harsh vibrational environment (Rocket).

I looked on all the Beaglebone Black’s proprieties and it would be suitable for the project, but one of the members of my team suggest to avoid using a microprocessor (with OS) and go for a microcontroller instead (no OS) like the Arduino because if the vibrations cause a sudden loss of power, the (longer?) booting time of the OS could cause a bigger loss of data.

I would like to hear some of your experience on the subject and some recommendations if you have some, it would be greatly appreciated!

I have the feeling that vibrations would not be enough to cause loss of power if the connections are well connected, but still, I can’t be sure.

Thank you,

Jo D.

2

On Wed, 16 Jan 2019 13:20:42 -0800 (PST),
thejodenis14@gmail.com declaimed the
following:

Hi all,

I'm a beginner in the microprocessor environment, and my job is to find the
"best" microprocessor board to be able to perform some data monitoring
inside a harsh vibrational environment (Rocket).

  Given the environment -- your first task is to eliminate anything not
suited to that usage. So... anything with socketed chips will be out (older
Arduino UNO used a socketed AVR processor).

  What does the monitoring do? Log to persistent memory? Send telemetry
via a radio link? Activate a self-destruct if the parameters go out of
range?

I looked on all the Beaglebone Black's proprieties and it would be suitable
for the project, but one of the members of my team suggest to avoid using a
microprocessor (with OS) and go for a microcontroller instead (no OS) like
the Arduino because if the vibrations cause a sudden loss of power, the
(longer?) booting time of the OS could cause a bigger loss of data.

  If there is any realtime aspect, you would want to avoid common Linux.
The BBB PRUs would support realtime -- but the "firmware" gets loaded as
part of the Linux boot, so if there is any chance of processor restarts
that may not be desirable -- not to mention that uncontrolled power-loss
can corrupt the file system! (You do not want a R/W file system if you are
subject to power drops... Everything should be in a read-only memory
system, with logs maintained in either a volatile memory [hence lost if
power fails] or in a separate flash/EEPROM which can be, if corrupted,
reformatted [again losing older logs]*)

  For something more powerful than an AVR... Arduino DUE (are they still
made), or a TIVA C 123 (EK-TM4C123GXL) may be candidates (TI-RTOS modules
for the latter, and I think FreeRTOS has been ported to DUE).

I have the feeling that vibrations would not be enough to cause loss of
power if the connections are well connected, but still, I can't be sure.

  As mentioned -- exclude anything with a socketed processor <G>

* in a previous life, I did work on some avionics... that was set up with a
power-loss detection circuit/interrupt, with capacitors to run the
processor long enough for a safe shutdown (eg: store processor state). No
"OS" (it did have an RTOS) that required massive file system operations. It
relied upon finding garbage in part of RAM to determine if it needed to
cold-boot, or could restore the saved state and resume where the interrupt
triggered.

3

Have you considered the PocketBeagle. Its power would be a soldered battery connection. It is much smaller than a BBB. And per the issues raised by Dennis reply, I believe all chips are soldered in. There is a working port of freeRTOS with TI starterware on GITHUB which boots fairly fast.

4

Hi Dennis,

Thank you for your detailed comment, and sorry for my late response!

What does the monitoring do? Log to persistent memory? Send telemetry
via a radio link? Activate a self-destruct if the parameters go out of
range?

The monitoring will acquire data from a sensor during the flight, and send them to the general flight system (using normal electrical wire) which will send everything back with radio link. So we can say that the board will not be the main computer in the system, but just an external data collector (collect-compress-send). We plan to add redundancy to prevent data corruption.

What is your opinion about Graham’s suggestion; PocketBeagle working with freeRTOS with TI starterware?

I really like your Arduino DUE suggestion, how would you compare his speed versus the PocketBeagle’s?

Arduino DUE:

  • Microcontroller with clock speed of 84MHz (AT91SAM3X8E)
  • SRAM of 96KB (Two banks: 64KB and 32KB)

PocketBeagle:

  • Processor Ocatvo Systems OSD3358 1GHz ARM Cortex-A8
  • 512MB DDR3 RAM Integrated

I don’t get how to compare a Processor with RAM versus a Microcontroller with SRAM. (I know that the SRAM is faster than the RAM, but how I could know in advance which is faster?)

Thank you a lot for your time

JD

5

On Mon, 21 Jan 2019 11:25:53 -0800 (PST),
thejodenis14@gmail.com declaimed the
following:

I really like your Arduino DUE suggestion, how would you compare his speed
versus the PocketBeagle's?

Arduino DUE:
- Microcontroller with clock speed of 84MHz (AT91SAM3X8E)
- SRAM of 96KB (Two banks: 64KB and 32KB)

PocketBeagle:
- Processor Ocatvo Systems OSD3358 1GHz ARM Cortex-A8
- 512MB DDR3 RAM Integrated

I don't get how to compare a Processor with RAM versus a Microcontroller
with SRAM. (I know that the SRAM is faster than the RAM, but how I could
know in advance which is faster?)

  Unless the RAM is so much slower that wait states need to be inserted
you probably don't need to be concerned with the difference -- the main
core of the Beagle is clocked at over 10 times the speed of the Arduino.
Being in the core vs an external chip removes the delays in driving
external memory -- and the overhead of DRAM refresh cycles, but faster
clock speed overwhelms that overhead. If the overhead were even 5 cycles,
the DRAM is still being accessed twice as fast.

  In an Arduino, the SRAM is used solely for dynamic data (variables in
code). The code itself sits in FLASH which is mapped into the processor
address space, and executes out of that flash memory directly (hence the
fast restart capability -- the chip start-up basically jumps directly to
the loaded program). The banks probably won't come into play -- I suspect
the compiler(s) are smart enough to insert bank switching (which, true, may
take a processor cycle or two -- so optimizing variables to minimize bank
swapping is a later enhancement for the program). The DUE M3 core does not
have floating point hardware (TIVA C 123 uses an M4F core with 32-bit
floating point).

  In the Beagle, the eMMC/SD Card is /not/ mapped into the processor
address space -- it is treated as a "disk" drive. The boot sequence has to
first load an OS image from eMMC into RAM before it can transfer control to
the OS. The OS then loads the application into RAM, sets up process control
structures, etc. before transferring control to the application. Even with
FreeRTOS (most RTOS systems I've been exposed to put all onus on the
application for communication access) your application is still an image
that has to be copied from eMMC to RAM before it gets control. OTOH: since
your application code is also loaded to RAM, you have RAM accesses for both
code and data (a small enough program may end up within cache, which would
reduce the RAM hits if you have a small enough main loop)

{NOTE: one source
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwi2ksj414DgAhVGja0KHfoWCCcQFjAAegQICxAC&url=http%3A%2F%2Fmeseec.ce.rit.edu%2F551-projects%2Ffall2014%2F2-2.pdf&usg=AOvVaw0MN7jq264ir-9NoAOuOJw7
indicates that a total cache miss results in a 20 cycle overhead}

  And if you need to use the PRUs, you'll have to figure out how to load
their program binaries from within your application. The PRUs in a Beagle
run, as I recall, at 200MHz -- so technically, if your application can run
in a PRU, it would be faster than the DUE... But still delayed by the
start-up overhead of the OS (you have to load the main OS before you can
load the PRU program).

  In both, if you need networking, you might be looking at building
lwIP - Wikipedia into your application (though Arduino
does have a library for the Ethernet Shield and uses SPI to talk to the
shield, letting it handle the Ethernet hardware connection)