Motors

[rscottm]

I checked some code into a motors branch in my fork. It implements most of the output commands. In doing this I have a few thoughts:

1. We need a Motor object that can manage two motors at once. Most of the output commands can support this, and the sync calls require it. We can get this easily by adding a constant (AD = A | D) and calling brick.motor_ad, but we do get some problems from interacting with the two motors (go forward) and then interacting with a single motor (reverse). The problem is that initializing the single motor automatically sends it stop.

2. The need to set the speed before calling start (or the motor gets into a weird state) is problematic. Maybe we can check the speed (using motor.read) before setting the speed to zero. If it's already running, there is no need to initialize it.

3. It might make sense to have a motor subclass for controlling more than one motor (or a base and two subclasses). There are only a few methods that can only be called in one or the other, so it might be ok to just throw an error if a method is called at the wrong time.

4. Keeping state information in the Motor object (e.g., the speed) is problematic. Once we have the other methods, there are too many ways to start the motor that will invalidate the state information (e.g., power=). I think we need to ditch this state information and use motor.read to retrieve the speed if it is needed.