Search Microcontrollers

Friday, April 11, 2014

Stellaris Launchpad - Stepper Motors

I just noticed I had a post in my drafts, almost ready to be published, it was lying there since some time...

Stepper motors are fun, right?
You can easily find cheap stepper motors that can be driven by MCUs, they need a driver circuit as MCUs cannot provide enough current via their GPIO ports, but these drivers are normally just a set of simple transistors.

I experimented with a  small 28BYJ 5V Stepper Motor which contains a gearbox that allows it to deliver a decent torque and precision (sacrificing the rotation speed).

There are libraries for Arduino and maybe even for ARM Cortex MCUs, not sure about that, but, as usual, I wanted to get my fingers dirty and experiment a bit.

A typical driver for this motor is the ULN2003 driver, which is just a darlington array that delivers just enough juice for the 28BYJ (500mA).
Those darlingtons can also be activated via a 3.3V GPIO, base resistors and protection diodes are already included in the package... pretty easy, no?

For the 28BYJ only 4 transistors are used, common is connected to +5V.
You need an external power supply to provide this 5V as you need 500mA, remember to connect the ground of the additional PSU to the launchpad ground.

So, the circuit itself is quite simple, I used a simple board for the ULN2003, which I bought together with the motor (it is quite common) so I did not have to mess around with soldering etc.

The motor has 4 phases that must be activated in the correct sequence of 8 steps to obtain a clockwise rotation or in the opposite sequence should you want to achieve a counter-clockwise one.

Easiest thing to do is to create an array with the 4 bits and the 8 steps cycle.

unsigned char steps[8] ={0b0001,0b0011,0b0010,0b0110,0b0100,0b1100,0b1000,0b1001};

each one of those bits should be addressed to a GPIO pin, I used pins  D.0, D.1, D.2 and D.3 which can be found on the J3 connector of the launchpad. 

So, the first step 0b0001 would set D.0 high and the three other ones low.

I then decided to use a timer with an associated interrupt to cycle the steps.
Setting the timer value is key because we are dealing with a  mechanical thing here, it has inertia and therefore can reach a maximum rotation speed that cannot be exceed (it would stall).
Setting the correct speed depends also on the load you have attached to the motor.

Of course providing a nice acceleration ramp lets you achieve higher rotation speeds, however I am not sure it is a good idea in a real application because if the motor misses a few steps due to exceptional load, then you might be driving it at a speed it cannot achieve starting from zero, and would remain stalled. 
You can try that, simply block the rotation when it runs faster than it can from still and see what happens.

Ok, back to my test program.
I wanted to use the two user switches on the launchpad to make it rotate 180deg in each direction.

I then created a variable int cntSteps = 0;  which represents the number of steps to be executed, if it has  a negative value then I will traverse the steps array backwards.
This is done in the nextStep() procedure.
I also need a int step variable to identify the position within the array of the current step.

void nextStep()
if (cntSteps>0)
if (step<7) step++; else step=0;
if (step>0) step--; else step=8;
GPIOPinWrite(GPIO_PORTD_BASE, 0x0f, steps[step]&0x0f);

Depending on the sign of the cntSteps variable I cycle through the array and finally output the 4 bit value (masked, just in case) to the GPIO port D.
I also added a blue led on if turning in one direction and red if turning in the opposite one.
When the motor is still, the LED is green indicating the system is ready to receive another command. 

This is visible in the Time Interrupt Handler (you can find more info on interrupts here)

// timer interrupt handler
void timerIntHandler(void)
    if (cntSteps!=0)

If we need to move (cntSteps!=0) then the next  Step is executed else, the LED is turned green.

Interrupt handlers must be registered, that's  done in the setup_ccs.c file of the project, in the #pragma DATA_SECTION(g_pfnVectors, ".intvecs") structure.

In my case, I used two interrupt handlers, one for the two switches and one for the timer0_A, I located the position of the GPIO PORT F and TIMER 0 A and then replaced the defaultHandler with the procedures I created in my main.c file.

Since these procedures are defined in main.c, you need to declare the external before the int vec structure we just discussed, still in startup_ccs.c :

//------------- custom int handlers
extern void timerIntHandler(void);
extern void switchIntHandler(void);

Ok, now let's see how the user switch interrupt handler works.

// switch interrupt handler
void switchIntHandler(void)
if (cntSteps==0)
                        &GPIO_PIN_4 > 0)
else addAngle((double)-180.0f);


As you can see I created a single handler for both switches, this is possible because they are both on the same GPIO port (F).
Using the interrupt on F.0 is not trivial and requires some funny coding, but I will dig into that later.

The addAngle procedure is quite simple, it converts an angle into a number of steps knowing that there are a total of 4076 steps in 360 degrees (not really sure of that value, I found it online, you may want to double check eventually) taking into account also the reduction gears.

// -- adds a specific number of steps depending on the needed angle
void addAngle(double deg) // 4076 steps
double newAngle =deg*4076/360;
  cntSteps += newAngle;

Finally , we are just missing the setup part.

// configure mcu clock speed
void setClock()
 //25 MHZ

// stepper timer setup
void setTimer(int stepsPerSec)
    TimerLoadSet(TIMER0_BASE, TIMER_A, 
            SysCtlClockGet()/ stepsPerSec);
    TimerEnable(TIMER0_BASE, TIMER_A);

These two procedures set up the MCU clock to 25MHz and prepare the timer to fire an interrupt stepsPerSec times each second.
We are just missing the gpio setup part and here I had to do something  a bit unconventional.
If you check the launchpad schematics, you will notice that the user switch 2 has an additional connection called WAKE

Practically by default this switch generates an NMI (Non Maskable Interrupt) used to wake the CPU from sleep modes.
Unfortunately this functionality interferes with the Interrupt handler for SW2 (D.0), unless you " massage"  it properly.

  //workaround for pin_0 to nmi
I am note really sure what it does, I just found it online and it works, you add that to your GPIO configuration and magically sw2 can be serviced with an interrupt handler.

The complete GPIO setup is as follows :

// GPIO & Interrupt configuration
void setGPIO()
  // to read switches
  // used to output stepper signals

GPIOPadConfigSet(GPIO_PORTD_BASE, // identifies the GPIO PORT
0x0f,                 // identifies the pin within the GPIO Port
GPIO_STRENGTH_8MA_SC, // sets the strength to 8mA with Slew Rate control
GPIO_PIN_TYPE_STD);   // sets the pad control type to push-pull

    // setup LEDs
    //turn LEDs off

    IntMasterEnable(); // enable processor interrupts

    //workaround for pin_0 to nmi

    // set the two switches as inputs
         GPIO_PIN_TYPE_STD_WPU); // configure input pads
// interrupt set to falling edge since the switches are normally "high"
// they indeed know how to have fun, lol :P

If you check again the switch schematics, you will notice that when they are pressed, they are connected to ground, so it is appropriate to use a falling_edge interrupt to detect when they are pressed.
In my case this is important because I am using a single ISR for both switches and I need to check which one is pressed, if I used a raising_edge interrupt, the ISR would have been activated when the button was released and I could not tell which one of the two was released by reading the GPIO port.

finally, the main cycle is trivial :

int main(void) {
 cntSteps = 0;
 setTimer(800);//steps per second
 while (1) {}// do nothing, interrupts will handle that
} // main
You can find the full code here

Have fun with stepper motors, interrupts and switches!

Friday, April 4, 2014

Experimenting with the FPGA - Configuration Device

Hello again, did not have much time to play with the fpga board, but enough to discover a few things that I thought I may share with you, should you run in the same issues.

First of all, I bought a cheap DEV board, that does not come with any kind of manual (not even a link to download it form the web), but I guess if you need a manual then you should leave these boards alone.

It features a Cyclone IV E, a cheap 622C8N, what else do you need to know, after all? :)

Ok, I tried/studied/experimented with a funny pong game that outputs to a VGA monitor.

I did not connect it to the monitor yet, did not have time to solder a connector, but managed to probe the HSync and VSync signals with my DSO and they are as expected.

So I have been experimenting a bit with little verilog modules in Quartus II etc.
A funny thing I noticed is that each time I power cycled the board (or pressed the reset button), it would revert to the test program that was loaded when I received the board.

It is a bit weird if you come from the MCU world, but if you think it does make sense : FPGAs store their configuration in RAM, meaning that each time you reset them, they are completely blank, you need to pump in the configuration from a serial eeprom.

So, I figured out that each time I was writing the configuration to the RAM and not the eeprom itself, maybe there was some kind of option in the USB Blaster programmer...
Nope, not there, so I started checking the board schematics to see if I could locate the configuration device (the serial eeprom).

Sure enough I found a device in the JTAG section of the schematics that looked like a serial configuration storage, labeled EPCS4S18, which really looks like an Altera code related to Cyclone devices... a quick search on the web confirmed my first impressions.

Now, the interesting part is that my board comes with two programming sockets, with the same 10 pin JTAG standard connector , but only one is labeled JTAG, the other one, as visible in the schematics is labeled "AS".
Even more interesting is that the AS is connected to the EPCS4 device.

So, I figured that if the two ports had the same connector -probably- it was enough to connect the USB blaster on the AS one.
I left the quartus programmer on the JTAG option and obviously it gave me error, fair enough.
So I checked which other options were available and found an "Active Serial Programming" which kind of makes sense having a connector labeled AS, no?

Unfortunately as soon as I switched to Active Serial, a warning popped out telling me that I had no devices listed in the programming window that supported such mode.
The only device I had in my list was the Cyclone IV... but wait, I was actually trying to program the eeprom this time, not the fpga!
Clicked on "add device" (after accepting the Active Serial option which removed the FPGA device from the window) and there I found my beloved EPCS4!!
Now, I just needed to point to the binary file to be loaded... doh! The open file dialog filters for a different binary format called POF (instead of the common SOF used to program directly the FPGA chip).

Some more googling led me to this document which explains that serial configuration devices use Active Serial (which is supported by USB Blaster) to be programmed and they need this POF thing that is actually generated in Quartus II (File -> Convert Programming Files).

The process is quite straightforward :

1) Select your configuration device  (EPCS4 in my case)
2) Click add File
3) Select the SOF file generated by the compiler
4) Click "Generate"

Then, in the programmer tool :

Make sure you connected your usb blaster to the AS port (if you have  a board similar to mine), add the EPCS4 device, tag the program/configure option and finally "start".
The process is way slower than configuring the RAM, but it worked for me, and after resetting the board, the newly created configuration was active.