In terms of boot time, I can imagine there are situations where it might be important

Sure, like in the product I mentioned before. It combines the ARM Linux system for the user interface and an ARM-based microcontroller for the product's main functions. The microcontroller has run through its bootloader and the power on self test and is ready to work before the kernel passes control to /sbin/init (no RAM-disk involved, the system boots directly from flash).

I would have liked to strip some unneeded features out of the kernel (why should it search and wait for unused or non-existing hardware), but alas, Yocto won't let me do this with a sane amount of work. Well, I could build my own kernel out of the Yocto tree and replace the vendor-provided one. But again, this takes some time. Likewise, my initial idea was to get rid of all init scripts, instead use some tiny init and daemontools to start all required software - essentially, X11, the main application, and during development, network, ssh, and a serial console. It could be done, and I'm sure it would reduce the boot time by a few seconds. The existing boot time is good enough, not as fast as it could be, and nobody complained. So it is unlikely that we'll invest time (and money) to reduce the boot time.

While the main product is powered, but the user interface is not needed, we can switch the entire display module to a deep-sleep mode. It keeps its memory content, but stops the CPU and cuts power to the LCD and most other peripherals, saving significant amounts of battery power. Waking up the display module takes about one second. When running on mains power, we don't even use the deep-sleep mode, but just switch off the LCD. Switching it back on is almost instantaneous. Sleep and display off modes are the common case, not booting. So the entire product appears to start within about one second or less most of the times, and in perhaps five or ten seconds when it was really switched off.

Not perfect, but good enough.

Alexander

Hi Alexander,

That's an interesting set-up; do I understand correctly you have two microcontrollers? I imagine that kind of a set-up should help a lot with stability (UI could crash without affecting the main uC) and timing (the main uC can do some real-time functions and at the same time you don't have to bother with setting up a real-time Linux kernel on the UI system).

Regards,
-- Hauke D

That's an interesting set-up; do I understand correctly you have two microcontrollers?

Correct.

I imagine that kind of a set-up should help a lot with stability (UI could crash without affecting the main uC) and timing (the main uC can do some real-time functions and at the same time you don't have to bother with setting up a real-time Linux kernel on the UI system).

Yes, all of that are very welcome effects of sharing the work-load between the two (quite different) processors. Plus, the bare-metal processor can do I/O at will, at reasonable fast speeds, without the need to write any Linux drivers. But there is another aspect, and it was the main reason for this setup.

(I'm intenionally a little bit fuzzy and unclear about our product and its development, I don't want to name or hint product names or company names, or even product categories.)

Our product is subject to some regulations, more than just the usual stuff that applies when you build a flashlight or a toaster. These regulations require that you consider all risks of the final product, and how to prevent them. From there, you classify your product in categories. If it can't hurt or kill anyone, fine, you can (nearly) get away with the flashlight and toaster rules. If pressing the wrong button, a typo in the code, or a faulty hardware component may severely hurt or kill people, bad luck, the hardest set of rules applies. You have to document and explain each and every little detail, every decision, you have to design and implement tons of test to cover all risks; including all hardware and software by third parties. Hello world under these rules still has only 10 lines of code, 50 if you count POD / doxygen comments as code, but also about 1 LOTR of paper work.

So, you really want to avoid that category. Our product is somewhere in between, and even then, hello world takes a significant amount of paper work. One way to reduce the paper work is to split the product into separate modules, and classify each module separately. Parts that fall under the "flashlight and toaster" rules get a way with very little paperwork, just above the noise floor.

In our case, we could split our product into four parts: The power supply module, bought form a third party, including all paperwork and stamps required; a real no-brainer. The battery, also bought from a third party with all paperwork. The display module, running Linux and our user interface application. And the main module, running our own bootloader and our own main application. Usually, both the display module and the main module would be subject to quite strict rules. But we explicitly designed the system such that the display module is as dumb as possible. It does not make any (relevant) decisions, it does what it is told by the main module. All relevant decisions are done by the main module. The display knows only one answer to commands from the main module: "Sir! Yes, Sir!" ;-) And if the display module does not behave as expected, the main module can power cycle it, as a last resort. This way, the display module could get into the "mostly harmless" category, with only a little bit of paperwork required; and with it, all of our code and all of the third party code running on the display module. Only the main module falls into a stricter category, and requires significant paperwork. The software running on the main module is again split into modules, and only those modules that have a risk associated need full paperwork.

The separation into modules goes even into the hardware: Power supply, battery, and display module are only connected by a set of wires per module to the main module. This way, it is very easy to see that the product is really "just" a combination of modules, and so the regulations must apply only to the modules. Our overall regulatory paperwork is somewhere between 1 and 2 LOTR.

Fun fact: The tester for the main module hardware uses at least 10 processors:

• a common Windows PC, running software written by us
• a main microcontroller interfacing the PC, running software written by us
• two more microcontrollers acting as slaves to the main microcontroller, running (identical) software written by us
• a fourth microcontroller simulating the battery, running software written by us
• a fifth microcontroller in a programmer for programming the microcontroller on the main module, connected to the PC, running third party software
• a sixth microcontroller in a barcode scanner, connected to the PC, running third party software.
• microcontrollers 7, 8, and 9 in USB serial converters, again running third party software

And yes, we really have fun making all of those processors talk to each other.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)