Conclusion

With this installment we have pushed very hard against the limits of what is reasonable to do with discrete components and high level code. It might not look like the code presented here is particularly special, but it was designed to be as deterministic as possible for this real-time application. In this way the motors speed is as uniform as possible. By the way, here is a little experiment for you MS-DOS/Windows users. Take a look on an oscilloscope at the pulse timings when running the PWM code in a Windows shell and when running in native MS-DOS mode. If you do this experiment, you will never have to ask the question about whether it is reasonable to run a true real-time application from Windows... you will know the answer.

In a typical microcontroller that might be used in an embedded application that needs to control a DC motor, you are likely to have an onboard timer or I/O coprocessor that can be used to generate the motor control signals. This type of feature should certainly be taken advantage of if it is available, it can potentially help you to avoid needing to use a more powerful (and more expensive) processor for a given application. But if you follow what we did here, you will understand the principle of DC motor control regardless of the implementation details that your application will dictate.

Now that we can turns things off and on and move things around we need to focus our attention on measuring how the real-world is responding to our manipulations. Without input we can't really control systems. Next time, we will begin looking at getting input from the environment.

Please send your comments, suggestions and criticisms to me through Forth Dimensions or via e-mail at skip@taygeta.com.

Skip Carter is a scientific and software consultant. He is the leader of the Forth Scientific Library project, and maintains the system taygeta on the Internet. He is also the President of the Forth Interest Group.