Search Microcontrollers

Tuesday, April 22, 2014


When I have some spare time, I am still playing with my FPGA board, meanwhile I went through some on line training graciously offered by Altera and also some documents they make available on the web.

Wow, there is A LOT of valuable information available there, thanks Altera!

Fact is that FPGAs are incredibly flexible devices and with flexibility often you get complexity.

To be fair Quartus II partially helps out in dealing with such complexity, provided you are used to the complexity of an Eclipse interface at least!
That said, I must admit it is easy to get lost in the rich menus of the IDE, so I decided to investigate deeper one thing at a time.

A good starting point seemed to be the I/O section.

When, in Verilog, you define a module such as

module pong(clk, vga_h_sync, vga_v_sync, vga_R, vga_G, vga_B, quadA, quadB);
input clk;
output vga_h_sync, vga_v_sync, vga_R, vga_G, vga_B;
input quadA, quadB;

you can place it in the schematic design and verify that it has certain inputs and outputs (as defined in your module declaration)

Those inputs and outputs could be connected to other modules in your design, or they could be routed to connect to the external world (like in my example).
In the latter case, you need to attach them to input or output pins.

Once that is done, you still need to tell Quartus to which physical pins they (the input/output signals you defined) have to be connected on your device.

Turns out this is quite an easy task, in fact once you run the Processing-> Start-> Start Alaysis & Elaboration process, these signals become visible for the Pin Planner tool

The Pin Planner is one of the MANY tools/wizards you will have to deal with in Quartus II, it will allow you to perform two important functions :
1) You can assign your signals (nodes) to specific pins, this is quite straightforward, you have the list of nodes on the left and select the " Location " being the pin you would like to connect.
2) You specify the electrical configuration for your pin (actually for your I/O bank)

The I/O banks are similar to the GPIO ports in microcontrollers.
Typically in an MCU a GPIO port has 8 pins, an FPGA I/O Bank typically has more than that and the device I am using has 8 banks.
Now, one incredibly interesting thing is that FPGAs allow you to configure a bank with different Voltages (might vary depending on the device you are using) allowing you to interface external devices operating at different voltages!

However your settings must be homogeneous within the I/O bank, so you cannot have one pin at 2.5V and another one at 1.8V in the same bank, Quartus would complain about that.
To check your settings are consistent you can run the Processing -> Start - Start I/O assignment Analysis process.

Also the current strength can be configured in the same way :

You would imagine that's the place where you can also set an internal pull-up resistor for your inputs... but nope (according to the docs I found), that's  in the Assignment Editor

...where you can set a ton of parameters, for most of which I have no clue at all, cannot even imagine what they are for.
You can specify more than one parameter for the same Node, however some combinations of parameters are not valid, i.e. you cannot enable a weak pullup and define the pin as differential input (yup, also that!) at the same time.

So, long story short, I/O signals in an FPGA can be way more flexible than those on a MCU, you could probably use an FPGA as an extremely expensive logic level translator!

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!