Stellaris Launchpad - NRF24L01 radio - Part 1

I have a couple of digital radio transceivers hanging around my desk since quite some time, so I decided to finally try them out.

These are cheap Nortel NRF24L01 devices, it is common to find them in small breakout modules that communicate via SPI protocol.

Some have an 8 pin connection, some others a 10 pins one, they are just the same in fact since the 10 pins one have 2 VCC and 2 GND pins, normally pins are marked on the silkscreen.

WARNING : The chip works at 3.3V (VCC) which is fine with the Stellaris, but should you use it with an arduino or another 5V MCU make sure you provide a proper VCC. The digital signals are also at 3.3V, but they are 5V tolerant.

There are popular libraries for Arduino / AVR for them and even a Stellaris library for the Energia environment  ( Arduino-like for the Stellaris Launchpad).

I actually prefer to use them in my common environment, plain CCSV5 with driverlib support, so I decided to write my own module.

You can find the datasheet of the module here (Sparkfun site, they sell those little boards too).

I reverse engineered code snippets found on the web, from the various libraries and managed to write my own code.

First off, since we are dealing with a SPI connection we are going to have  a SCLK, MISO , MOSI connection, plus a CE (Chip Enable), a CSN and an IRQ generated by the module itself.
So, it is a sort of " rich" SPI interface.
While the first three (MISO, MOSI and  SCLK) are managed directly by the SSI module of the Cortex M4F, we still need to manage manually the other three signals using 3 GPIO conections, two outputs and 1 input for the IRQ.

I decided to use SPI on port SSI1 (uses pins D.0, D.2, D.3) and the GPIO port E to drive CE, CSN and IRQ -E.1, E.2, E.3- (I saw a library on the web using this setup and found it quite smart, since the connections are all aligned on the launchpad connector).
I stored these values in variables, just to allow for some flexibility in configuration

unsigned long NRF_GPIO = GPIO_PORTE_BASE;
unsigned long NRF_PERIPH_GPIO = SYSCTL_PERIPH_GPIOE;
unsigned char CEPIN    = GPIO_PIN_1;
unsigned char CSNPIN   = GPIO_PIN_2;
unsigned char IRQPIN   = GPIO_PIN_3;

Then I created an init function to enable the needed ports, set up the SPI etc :

void setSPI()
{
  unsigned long dummy = 0;
  SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI1);
  SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); // SPI
  SysCtlPeripheralEnable(NRF_PERIPH_GPIO); // CS, CE, IRQ
  GPIOPinConfigure(GPIO_PD0_SSI1CLK);
  GPIOPinConfigure(GPIO_PD1_SSI1FSS);
  GPIOPinConfigure(GPIO_PD2_SSI1RX);
  GPIOPinConfigure(GPIO_PD3_SSI1TX);
  GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_3 | GPIO_PIN_2 | GPIO_PIN_1 | GPIO_PIN_0);
  SSIConfigSetExpClk(SSI1_BASE, SysCtlClockGet(),
                 SSI_FRF_MOTO_MODE_0,
         SSI_MODE_MASTER, 1000000, 8);
  SSIEnable(SSI1_BASE);
  GPIOPinTypeGPIOOutput(NRF_GPIO, CEPIN| CSNPIN);
  GPIOPinTypeGPIOInput(NRF_GPIO, IRQPIN);
  while(SSIDataGetNonBlocking(SSI1_BASE, &dummy))
   {}
}

The while cycle at the end is there just to remove from the FIFO whatever garbage data might be eventually present.

The NRF24L01 chip is quite versatile, can operate on various channels and can easily manage communication on a network of addressable devices.
To allow this flexibility, the chip is configured with a set of registers, so the first thing we need to implement are the functions to read from and write to these registers, plus the CE / CSN handling.

The process is quite simple :
Each register has a 5 bit address (documented in the data sheet, but since I am lazy I just imported an existing .h file that defined them all -you can find it here-) and if we combine these 5 bits (r rrrr) with 001 in the 3 MSBs (001r rrrr) then we have a 1 byte command that, when delivered via SPI, tells the chip we want to write the register r rrrr.
The following byte is the value we want to store in the specified register.
Reading is similar , but we will add 000 in the 3 MSBs instead, so the command for reading r rrrr is 000r rrrr .
Details about reading values will be discussed later.

However, for the chip to respond we need to properly manage the CE and CSN signals.

The chip is enabled when CE is asserted LOW and when there is no communication from the master, CSN should be HIGH, so this is our initial setting.
Then, before sending data via SPI, CSN must be transitioned to LOW and finally back HIGH once the communication (writes + reads) is terminated.

void setCE(unsigned char val)
{
  if (val>0)
 GPIOPinWrite(NRF_GPIO, CEPIN ,CEPIN); //CE HIGH
  else
GPIOPinWrite(NRF_GPIO, CEPIN ,0); //CE LOW
}

void setCSN(unsigned char val)
{
  if (val>0)
GPIOPinWrite(NRF_GPIO, CSNPIN ,CSNPIN); //CSN HIGH
 else
  GPIOPinWrite(NRF_GPIO, CSNPIN,0); //CSN LOW
}

The two setCxx functions are quite obvious, not particularly elegant I have to admit, but they get the job done.

void sendChar(unsigned char ch)
{
  SSIDataPut(SSI1_BASE, ch);
  while(SSIBusy(SSI1_BASE)) {}
}

sendChar is a helper function that outputs a byte to the SPI port, I added a while loop to ensure data is flushed out before leaving the function, I am not 100% sure we need that, but it helped me when debugging the line with my DSO.

void _writeReg(unsigned char addr, unsigned char val)
{
  setCSN(0);
  sendChar(W_REGISTER | addr);
  sendChar(val);
  setCSN(1);
}

unsigned long _readReg(unsigned char addr)

{

  unsigned long result = 0xff;

  setCSN(0);

  sendChar(R_REGISTER | addr);

  while(SSIDataGetNonBlocking(SSI1_BASE, &result)){}

  sendChar(0xf0); //whatever value, used 0xf0 because 

      // it is easily visible with the oscilloscope

  SSIDataGet(SSI1_BASE, &result);

  setCSN(1);

  return result;

}

_writeReg is quite a straightforward implementation of what I described before (W_REGISTER = 0010 0000) while _readReg is a bit trickier :
First thing notice the while loop used to throw away data right after the read register command.
This is needed (you can check it with an oscilloscope on the RX (MISO) line of the MCU) because as soon as you start sending data on the TX channel (MOSI), the slave device writes garbage data on the RX (typically a 0x0E value I found in my experiments).

After you sent the command, then, you need to send out a dummy byte (it does not matter the value) per each byte you need to read -in this case 1- and finally read the value and bring CSN high.

[You can see in yellow the MOSI line, roughly between the two purple vertical cursors there is the first byte. In red the MISO line is immediately answering with "garbage" data which I suspect is in fact the status of the module.
It is easy to recognize the second dummy byte being 0xF0 and then we get a (correct) response 0x03 on the MISO]

I then found a sequence of "default" values of the registers used to init the module :

void nrfInit()
{
  unsigned long dummy =0;
  _writeReg(CONFIG, 0x00);  // Deep power-down, everything disabled
  _writeReg(EN_AA, 0x03);
  _writeReg(EN_RXADDR, 0x03);
  _writeReg(RF_SETUP, 0x00);
  _writeReg(STATUS, ENRF24_IRQ_MASK);  // Clear all IRQs
  _writeReg(DYNPD, 0x03);
  _writeReg(FEATURE, EN_DPL);  // Dynamic payloads enabled by default
  SysCtlDelay(SysCtlClockGet() / 100 / 3); // grace time, never hurts 
  while(SSIDataGetNonBlocking(SSI1_BASE, &dummy)) {}
}

So, the init overall sequence is :

setSPI();

setCE(0);

setCSN(1);

nrfInit();

I also found that a way to check if the connection with the module is working is to check the value of the SETUP_AW register, which should return 6 MSBs = 0 and the two LSB with 01 (3byte address) ,10 (4 bytes) or 11 (5 bytes) while 00 means illegal number.

int _isAlive()

{

  unsigned long aw;

  aw = _readReg(SETUP_AW);

  return ((aw & 0xFC) == 0x00 && (aw & 0x03) != 0x00);

}

At this point, we can check if the basic communication via SPI works :

#include <inc/hw_memmap.h>
#include <inc/hw_types.h>
#include <driverlib/gpio.h>
#include <driverlib/sysctl.h>
#include <driverlib/uart.h>
#include <inc/hw_timer.h>
#include <driverlib/timer.h>
#include <driverlib/pin_map.h>
#include <utils/uartstdio.c>
#include "driverlib/ssi.h"
#include "nRF24L01.h"

void setClock()
{
   SysCtlClockSet(  SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL |
        SYSCTL_XTAL_16MHZ  | SYSCTL_OSC_MAIN);
}

....

int main(void) {
 setClock();
 // we  use the led to provide feedback
  SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
  GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2 | GPIO_PIN_1 | GPIO_PIN_3);
  GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2 | GPIO_PIN_1 | GPIO_PIN_3, 0); // LED OFF

 setSPI();
 enableNRF();
 SysCtlDelay(SysCtlClockGet() / 10 / 3);
 nrfInit();
 if (_isAlive()!=0)
  GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_3, GPIO_PIN_3); // GREEN
 else
  GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_3, 0); // OFF
} // main

Ok, so far we implemented the basic communication with the module, now we need to investigate how the radio data transmission happens.

Reading the Nortel datasheet shows some complexity and also allows us to understand that these devices can be operated in quite a few different ways.

Some basic concepts : 
In a network, at a given time, we identify one PTX and one  PRX, these stand for Primary Transmitter and Primary Receiver.
Obviously we are dealing with a Transceiver, so this module can send and receive data.

Table 12 in the Datasheet shows the different states we can set the module

(@Nordic)

For the actual data transmission, a mechanism called "Enhanced ShockBurst"(TM) is used, Nordic defines it as "a packet based data link layer".

What this layer does is to take care of the delivery of payloads (strings of data with 0 to 32 bytes content) from a TX to an RX station.

Enhanced ShockBurst has an automatic handling which automated a few basic actions for us, as an example, after a PTX finished sending out a packed of data, it cnverts it automatically to PRX to be ready to receive an ACK packet.
ACK packets can be also generated automatically if the module is configured to do so.
In fact in the init procedure we have a  _writeReg(EN_AA, 0x03); instruction which enable this Auto ACK feature.
If an ack is not received, then the PTX will retry to send the packet a number  of times, automatically.
To prevent that a packet is read twice (duplicating the data) a PID (Packet Identification) is associated to each packet, a CRC is also used to verify if data is correct.

The packet itself is composed by different sections (Preamble, Address, packet control field, payload and CRC), but it is properly assembled by the device itself using an automatic packet assembly functionality.

Similarly a packet is decoded (disassembled) automatically on the RX side.

An important feature,m on the RX side, is the Multiceiver.
In fact each receiver can use up to 6 data pipes, each one responding on a different address.
There is no magic here, one single channel is used at a time, so you cannot stream different payloads to different pipes at the same time, this functionality is there mainly to allow you to logically separate data streams, for whatever need you might have.

Addresses can be 3, 4 or 5 bytes (can be configured via the SETUP_AW register), so, assuming we are using 5 byte addresses some rules apply: 

1) the lower by is unique across all the pipes
2)  pipes 1 to 5 have the same 4 high bytes

When using the multiceiver feature, the PRX can receive packets from multiple PTXs (on different pipes), it stores on each pipe the "return address" of the TX and uses it to send automated ACK packets.

Specific registers RX_ADDR_Px are used to specify the RX addresses for the 6 pipes, each of these registers is 5 byte wide.

An example of multiceiver configuration (from the nrf24l01 datasheet) is reported here

(@Nordic)

So, our next step will be to write the functions that set up the channel, the TX and RX Addresses and finally that deliver a payload.
While I work on that, you might as well go through the datasheet.

[to be continued]

FPGA GPIO

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!

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)

{

GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,GPIO_PIN_1); //red

if (step<7) step++; else step=0;

    cntSteps--;

}

else

{

GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,GPIO_PIN_2); //blue

if (step>0) step--; else step=8;

cntSteps++;

}

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)

{

   TimerIntClear(TIMER0_BASE, TIMER_TIMA_TIMEOUT);

    if (cntSteps!=0)

    nextStep();

    else GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,GPIO_PIN_3);

}

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)

{

GPIOPinIntClear(GPIO_PORTF_BASE,GPIO_PIN_0

                                       |GPIO_PIN_4);

if (cntSteps==0)

{

if (GPIOPinRead(GPIO_PORTF_BASE,

                          GPIO_PIN_0|GPIO_PIN_4)

                        &GPIO_PIN_4 > 0)

                 addAngle((double)180.0f);

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

 SysCtlClockSet(  

         SYSCTL_SYSDIV_8 |SYSCTL_USE_PLL | 

         SYSCTL_XTAL_16MHZ  | SYSCTL_OSC_MAIN);

}

// stepper timer setup

void setTimer(int stepsPerSec)

{

    SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);

    TimerConfigure(TIMER0_BASE, TIMER_CFG_PERIODIC);

    TimerLoadSet(TIMER0_BASE, TIMER_A, 

            SysCtlClockGet()/ stepsPerSec);

    IntEnable(INT_TIMER0A);

    TimerIntEnable(TIMER0_BASE, TIMER_TIMA_TIMEOUT);

    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

    HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) =   GPIO_LOCK_KEY_DD;

    HWREG(GPIO_PORTF_BASE + GPIO_O_CR) |= 0x01;

    HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = 0;

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()

{

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); 

  // to read switches

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); 

  // 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

GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);

    // setup LEDs

GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);

GPIOPadConfigSet(GPIO_PORTF_BASE,

GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,

GPIO_STRENGTH_8MA_SC,

GPIO_PIN_TYPE_STD);

    //turn LEDs off

GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3,0);

    IntMasterEnable(); // enable processor interrupts

    //workaround for pin_0 to nmi

    HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD;

    HWREG(GPIO_PORTF_BASE + GPIO_O_CR) |= 0x01;

    HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = 0;

    // set the two switches as inputs

GPIOPinTypeGPIOInput(GPIO_PORTF_BASE,GPIO_PIN_0|GPIO_PIN_4);

GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_0|GPIO_PIN_4,

         GPIO_STRENGTH_4MA,

         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

GPIOIntTypeSet(GPIO_PORTF_BASE,GPIO_PIN_0|GPIO_PIN_4, GPIO_FALLING_EDGE);

GPIOPortIntRegister(GPIO_PORTF_BASE,switchIntHandler);

GPIOPinIntEnable(GPIO_PORTF_BASE,GPIO_PIN_4|GPIO_PIN_0);

}

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) {

 setClock();

 setGPIO();

 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!

Should you be looking for this stepper motors, chances are you can find it cheap here :

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.