I’m working on a hardware project that involves software controlling motors, grippers and the like. I can’t go into details on the project, but it’s quite a bit of fun.
I’ve learned a really important design principle for hardware interaction. I’m sure some of you that have more hardware experience than I do will simply say, “duh”, but I had to learn the hard way.
In version one, I made good objects for all of the components and then tied them together into a single device. They had base classes and such, good OO techniques.
It ended up being a pain in the kiester! Who would have thought!
A far better pattern to follow is the Actor pattern. Basically, you have a central state manager (ActorManager) that is responsible for giving each Actor (i.e. software addressable component) a chance to do its thing.
Each actor has access to a central state repository, and is responsible for writing it’s state to that repository as well. If it cares about another component, it looks in state for the information it needs, otherwise it does its thing and moves on.
As an example, suppose you have three axis on a gantry (X, Y, Z), and these axis have to move in such a way that they don’t collide in their container.
With a top down approach, like the first revision, the device has to talk to x, y, and z and do a bunch of work to determine if they’re in a state where they can move, if they’re going to do something bad, etc.
With the actor pattern, if X needs to know if Z is in a good position, it looks in state for Z’s position. If z isn’t in a good position, it does nothing, or if it’s in a good position, it moves. Simple. Y on the other hand, doesn’t care where Z or X are, so it can just move and does so. Z is the same. Simple.
Objects are still involved, they’re just much more loosely coupled.