task planning

As lovely a suit as this patterned fabric would make, it is not the type of pattern that I had in mind. I was, of course, referring to software design patterns. I am a huge fan of patterns. I am very comfortable in the knowledge that a group of guys (well, gang actually) who are way smarter than I will ever be, devised, developed and documented sound techniques for tackling near any problem that I might face in my career as a software engineer. This may seem like overkill to… well… everyone likely to read this blog, but bear with me. One of my plans here is to take what I have learnt from many years of developing enterprise type apps and apply it to embedded development.

, what are the project management tools Part of the plan for the Micro Framework Grand Prix is to have teams developing and using different input devices. There had to be a more elegant way of providing a “pluggable” input device in my solution and retaining all of the core features than giving each team a specific copy of the code base with their dedicated files in place.

What do ya’ know? There is! (Lucky for me, or this could have been a very short post. Dashboard for projects, ) The strategy pattern fits this need nicely.

The intent of this pattern is to encapsulate a number of specific “strategies” in a way that makes them interchangeable and independent of the implementation of the client that consumes them. MS whacked a coat of paint on this one and called it the provider pattern in the .net framework. Probably a more appropriate name for its use here, to be honest. ( ) At the bottom of this post is a class diagram generated out of Visual Studio for my control system.

To the left you will see the concrete strategies for button, tilt and touch input devices and the controller that consumes them. (I may add another yet for a web service, so the cars can be controlled over a network.

) The radio transmitter for the cars is a very simple two channel device. Made even more simple by the lack of proportional control. Each of the joysticks depress one (and only one) of two little push-button switches. Makes sense, you can’t apply forward and reverse signals at the same time. A pretty neat solution with the “seesaw” joystick arrangement. Now - I’m not 100% positive, but from careful analysis of the circuit board, if I do apply both directions simultaneously when I replace the joysticks with my micro-controller driven circuit, I am pretty sure this would result in total protonic reversal!

Just to be safe, I thought I’d do something to prevent this horrifying occurrence potentially killing another possessed marshmallow man… The mediator pattern allows for loose coupling of “colleagues” and uses a “mediator” to implement the required communication between them. In my case, if I tell the car to go forward, I want the mediator to ensure that the reverse signal is cleared first. As I mentioned earlier, overkill, considering that having the channels of an embedded device tightly coupled in code is by no means a crime. Anyway, I now have what I would consider a pretty elegant software solution for this control system - extensible where I want and constrained where it needs to be. I have started with the electronics interface, I guarantee that won’t be so elegant, but I’ll get there.

task planner