I've been working on the firmware without actually doing a whole lot of coding. I'm kind of circling from the outside to suss it out without rushing in. My ideal is to improve the quality and so I'm looking into best, or at least better practices. Recently, I've been reading Making Embedded Systems. I recognize the risk of brown-nosing here as it's written by one of the judges, but it's also on my mind right now. See, I have no formal training in engineering, and in order to improve I need to see things in practice. This book contains some really nice design patterns for better organizing firmware, and shows examples of how to implement them. The book I discussed previously, turned out to be a bit too theoretical, which is fine if you have the training but left me wondering "ok, but how?"
Anyways, some of what I've been working on includes the following diagrams. For the record, these kinds of diagrams are not discussed in the book. The first two are use cases. This one represents a sequence of actions, and invoked methods that occur when someone remote controls a Moti-enabled robot:
The second shows a sequence of events that occur when someone is recording a sequence of manual manipulations of a Moti enabled robot, and then plays them back:
These diagrams are not exhaustive. There's more steps involved. However it's enough to suggest that the model for breaking code apart could work. Okay, so having done the use cases I went on to make a UML class diagram. Now, I can imagine that many think it's a waste of time, but for me I wanted to try using one of the tools available to clarify each class and their relationship before writing them.
One thing I realized making the class diagram was that I could decouple the network hardware from the network protocol. Maybe that in itself made it worthwhile.
Anyways, it's all still new to me so If you see anything wrong with the diagrams please let me know. It's been a fun exercise and quite the opposite of how I usually dive right in...I kind of feel like George Costanza: