original posted by Charles Jarvis on 25th August 2008.

Since the last update, we've made a good deal of progress. Last time, we had the motor driver hooked up to a couple of switches and a few logic gates as a simple prototype. Now, the system is controlled completely digitally, save for the motor driver which can't be implemented in VHDL (we don't want to release the magic gray smoke inside the Cyclone II chip). The first picture below shows our current setup.



As can be seen in this picture, we have the breadboard with the SN754410 on it, now connected to one of the expansion ports on the DE2-70. The ports on the expansion slot are controlled by the program shown below. Right now, the program only controls one motor but that can be easily expanded by simply copying, pasting, and changing a few numbers and letters. In the background of the photo, next to the breadboard, is an upside-down prototyping board, generally used for soldering. Instead, we are using wire-wrapping so that we have a semi-permanent prototype. The only problem is easily locating connectors made for wire-wrapping since the technology has mostly been phased out, but electronics surplus stores generally have them. The reason we are using wire-wrapping is because way too often, many senior design projects at Trinity come to an end with their final prototype still on a breadboard. Not everyone knows how to solder, or is good at soldering. I didn't learn how to solder until this past school year, when I needed to make a sturdy prototype for my senior design project. I'm mediocre at it, but I'm a lot better than I was a year and a half ago when I was so inept with a soldering iron that I burned my right pinkie pretty good and nearly dropped the iron right into my lap. But that said, wire-wrapping is a good middle ground since it's more permanent than a breadboard but doesn't have the learning curve that soldering has.



This is the "program" that controls the motor. The program has four modules it uses to operate (it should evident which one is which): A clock divider that takes the 50MHz system clock and divides it down into decades starting at 1MHz, a RAM module for memory, a PWM generator which uses a 20ms cycle and allows pulse widths from 0ms to 20ms, and the logic circuit used to turn braking and direction signals into signals that the SN754410 can use. The PWM generator uses the toggle switches on the DE2 for input. Since we wanted to have the full range of 0ms to 20ms available to us for use, we had to use 5 bits for data. Since this allows for numbers up to 31 (11111 in binary), there is a line of VHDL code in the PWM module that caps the high-time value at 20ms, even if it is being given a value greater than 20 (confusing enough? :) ).The big accomplishment this week was adding addressable memory to the system. Its data input is the 5 bits for pulse width high-time, 1 bit for braking, and 1 bit for direction. Different presets can be applied to different addresses in memory, thus allowing for fast switching between low and high speeds in different directions. Currently, the input method used, as mentioned before, is the toggle switches and push-buttons on the DE2. The first 8 switches (7 to 0) are used for PWM-Brake-Direction input, the next 4 (11 to 8) are used for the address, the leftmost push-button is used as the write-enable for the RAM, and the rightmost push-button is used as the enable for the PWM generator. Eventually, this will be controlled via PCI, which is the supreme goal for both the robot arm and the visible motor. The nice thing about controlling everything this way is that the code is very easily ported between mechanical systems. Since we're using DC motors in both instances, I can use this exact same software to control the DC motor mounted to the model motor. Of course, in that case, a single MOSFET will be used as opposed to a full-fledged H-Bridge IC, since the model motor will be using only one DC motor and will have unidirectional rotation.



The other good thing is that we now have both of our PCI Dev Kits in. Seen above is the MAX II PCI development kit mounted and operating with the Efika. Now we just need to write some code on the Efika end and we should be up and running. The Cyclone II PCI Dev Kit doens't fit inside the OpenClient case so we're going to work on fixing that by getting a PCI riser and mounting the Cyclone II Dev Kit on top of the case.