| [reply] |
I have appended to my post to better explain what I meant.
So, using an AVR or PIC as a "smart" I/O handler (under the control of a Pi or other, similar device) makes a lot of sense.
Yes, that setup can work fine.
But you can also switch the roles of "boss" and "worker". This gives you a microcontroller (like an AVR, PIC, or a "small" ARM) that is nearly instantly up and running as the "boss". It controls the peripherals that connect to the real world (sensors, actuators). It has a small code-base (unlike a full Linux distribution, even an embedded one), so in the worst case, you can and do check audit the entire design and source code. And often, the software design allows for real-time applications, i.e. guaranteed response times under all conditions. So it is quite natural to make all important descisions on the microcontroller. The "real" computer, i.e. something like a Raspi, other embedded Linux systems, an industrial computer, a tablet, or an off-the-shelf PC, is just a "worker". It may take some time to boot. It makes no important descisions. It just runs a user more or less fancy user interface, under control of the microcontroller. It may do other "unimportant" things, like post-processing data from the microcontroller, or communicating with other systems (e.g. poll a job queue, write results). And in case of a PC, it can often be replaced quite easily.
Such setups can often be found in medical and laboratory environments, due to standard requirements. Implementing the core functions with hard requirements on a microcontroller is simply much easier than the "messy" environment of conventional operating systems, where processes can be swapped out or blocked by other processes that require memory and / or CPU time. Imagine a life support system that stops working for 10 min to install an OS update package, preventing the control process for the life support hardware from controlling the hardware.
Typical interfaces between microcontroller and computer are RS232 or RS485, because U(S)ARTs are simple and easy devices and require no special hardware on the computer side of the connection. CAN is often used for long connections in noisy environments. And as more and more microcontrollers can behave as USB device and at the same time, RS232 becomes an extinct standard in the PC world, USB is used more and more. Under the hood, USB is often just ending in an FTDI controller that connects to the controller's U(S)ART, so RS232 is not yet dead. IEEE-488 is often found on electrical lab equipment, like power supplies, frequency counters, function generators, multimeters, oscilloscopes, but it is a dying standard that is more and more replaced by USB.
I've written some more in an older thread: Re^18: CPAN failed install. For a little bit more context, start at Re^14: CPAN failed install.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |