Hello,
I'm in the process of designing a small hobby project using an embedded Linux board (such as the Raspberry Pi) and am having some trouble wrapping my head around my system architecture.

So the system is going to require a few separate processes, each of which share some common configuration information (Probably through a SQlite database). For example,
- There is going to be a process which monitors push-buttons connected to the GPIO pins and provides a simple menu interface on an 7-seg display connected through SPI.

- There is going to be a process which creates a web socket to listen for incoming connections from something like a Labview or Simulink GUI.

- There will probably also be a Html Web interface which will be able to relay/change configuration information.

- There will be another 'heavy-lifting' task which reads information from peripheral sensors (serial/i2c compass or range finder etc) and calculates results. This process will rely on configuration variables stored in the database that the other processes have the ability to change.

I'm used to bare-metal embedded systems where most of this would be in a single process and rely heavily on interrupts.

I'd like to take advantage of Linux as much as possible (and avoid trying to have it all in one multi-threaded/forked C program), so the processes would need someway to communicate between themselves.

I've been reading about UNIX domain sockets, POSIX message queues, FIFOs and other IPC's, and they look like they will do the job. I'm thinking I'd have to devise some message passing system to let process A let process B know that 'table foo has new data'.. So I guess I'd #define out all permutations of these events and pass messages to each process whenever a database write occurs?

Am I on the right track here or am I re-inventing the wheel somehow..

Your approach seems reasonable and conventional. You are creating a simple control system or SCADA system. Most of these are based on some kind of central database or data sharing scheme. Using a relational database to serve this purpose can be done, although it is a bit heavy and performance may become an issue if the system is intended to scale up. CORBA and similar technologies are often used as the basis for efficient and scalable data sharing in SCADA and control system software. Real-time OS's such as vxWorks tend to provide a more appropriate framework for real-time multitasking and the built-in named-symbol libraries can be an efficient light-weight data sharing mechanism, although the cost probably puts it out of range of a hobbyist.
If your system is composed of a sort of network of IPC schemes, it may become a maintenance and upgrade nightmare. I would consider an approach that uses relatively few of these, and tries to generalize the data sharing and event propagation system.
In contrast to the common wisdom, I see nothing wrong with selective re-invention of wheels or any other machinery. If someone hadn't reinvented the wheel, we might all still be using square wheels (although triangular wheels eliminate one bump per revolution).
--- rod.

1 members found this post helpful.

Above all else, start looking for frameworks that are designed to handle tasks similar to yours. No matter what you are doing here, you are not the first. You should be able to find a more-or-less industry standard framework that has been used and refined by many people with similar objectives, so that you can concentrate on what makes your particular application different, not what makes it the same.

"Actum Ne Agas" -- Do Not Do A Thing Already Done.

1 members found this post helpful.

Thanks for your replies I'll keep reading and see what I can come up with.

Cheers