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