|Don't ask to ask, just ask|
Re^18: CPAN failed installby afoken (Chancellor)
|on Nov 22, 2016 at 20:58 UTC||Need Help??|
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).
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:
And yes, we really have fun making all of those processors talk to each other.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)