Lesson 009: GPIO Input

In today’s lesson, we will be reading the status of the three push buttons on the DK-S7G2B and setting LED’s with their status.

First, set DIP switch 5 (PBs) on S5 to ON. This enabled hardware interrupt support for the switches. If PBs is in the OFF position, interrupts can be enabled in software (see the development kit’s user manual, section 8.9 Push Buttons.

Create a new Renesas Synergy project with the No RTOS BSP. In the Synergy Configuration view on the Pins tab, set P006, P010, and P011 as inputs, set the IRQ in the drop down box, and set the Chip input/output as GPIO.

Since we will also be controlling LEDs, set the following pins to output: P807, P808, P809, P810 and set the Chip input/output as GPIO (these should be set by default).

Lastly, since we have attached the pins to the External Interrupt Driver, add a External IRQ Driver Driver (Driver->Input->External IRQ Driver on r_icu) for each IRQ channel and set the following properties:

For P006 (IRQ11)

ICU> ICU IRQ11: Priority 15
Module>Name: g_external_irq _11
Module>Channel: 11
Module>Trigger: Both Edges
Module>Callback:g_external_irq11_callback

For P010 (IRQ14)

ICU> ICU IRQ11: Priority 15
Module>Name: g_external_irq _14
Module>Channel: 14
Module>Trigger: Both Edges
Module>Callback:g_external_irq14_callback

For P011 (IRQ15)

ICU> ICU IRQ11: Priority 15
Module>Name: g_external_irq _15
Module>Channel: 15
Module>Trigger: Both Edges
Module>Callback:g_external_irq15_callback

After clicking generate project, the SSP creates a function prototype for the callback function.

The SSP automatically creates a few defines for us that are a little helpful. The first is IOPORT_LEVEL_LOW and IOPORT_LEVEL_HIGH. You would initially think that pressing the button would set the pin HIGH, put each pin has a pull-up resistor and pressing the button grounds the pin. For code clarity, we shall define a BUTTON_RESSED macro and set it to IOPORT_LEVEL_LOW.

The LEDs are the opossite. The pin on the MCU sources the required current for each LED, so to turn an LED on, you have to set the pin value to 1. We shall also define an LED_ON and LED_OFF.

NOTE

The MCU ports are not directly connected to any of the switches or pins. They go though a 74LVC244A buffer chip. This means the above statement is not entirely correct. The MCU does not sink or source the current for the switches and LEDs, the buffer chip does this. The MCU just sets or reads the value from the buffer IC.

#define BUTTON_PRESSED IOPORT_LEVEL_LOW
#define LED_ON 1
#define LED_OFF 0

We will also need to create each IRQ handler using the callback functions defined on the configuration screen.

void g_external_irq11_callback(external_irq_callback_args_t * p_args)
{
 ioport_level_t p_pin_value;
 g_ioport.p_api->pinRead(IOPORT_PORT_00_PIN_06, &p_pin_value);
 g_ioport.p_api->pinWrite(IOPORT_PORT_08_PIN_07, p_pin_value == BUTTON_PRESSED ? LED_ON : LED_OFF);
}

void g_external_irq14_callback(external_irq_callback_args_t * p_args)
{
 ioport_level_t p_pin_value;
 g_ioport.p_api->pinRead(IOPORT_PORT_00_PIN_10, &p_pin_value);
 g_ioport.p_api->pinWrite(IOPORT_PORT_08_PIN_08, p_pin_value == BUTTON_PRESSED ? LED_ON : LED_OFF);
}

void g_external_irq15_callback(external_irq_callback_args_t * p_args)
{
 ioport_level_t p_pin_value;
 g_ioport.p_api->pinRead(IOPORT_PORT_00_PIN_11, &p_pin_value);
 g_ioport.p_api->pinWrite(IOPORT_PORT_08_PIN_09, p_pin_value == BUTTON_PRESSED ? LED_ON : LED_OFF);
}

Finally, in our main function, we need to open the IRQ devices.

 // Open Interrupt Channels
 g_external_irq11.p_api->open(g_external_irq11.p_ctrl, g_external_irq11.p_cfg);
 g_external_irq14.p_api->open(g_external_irq14.p_ctrl, g_external_irq14.p_cfg);
 g_external_irq15.p_api->open(g_external_irq15.p_ctrl, g_external_irq15.p_cfg);

After opening the IRQ channels, we should set the LEDs to a known state, and sit in a loop waiting for an event.

// Set LEDs to their initial state
 g_ioport.p_api->pinWrite(IOPORT_PORT_08_PIN_07, LED_OFF);
 g_ioport.p_api->pinWrite(IOPORT_PORT_08_PIN_08, LED_OFF);
 g_ioport.p_api->pinWrite(IOPORT_PORT_08_PIN_09, LED_OFF);

while(true)
 {

}

Here’s what should happen when you run the program:

The LEDs are initially all off. When you press S1, LED1 goes GREEN. Depressing S1 turns off the GREEN LED.

Pressing S2 turns on the RED LED1, and depressing turns off the RED LED.

Pressing S3 turns on the GREEN LED2, and depressing turns off the GREEN LED2.

If you press both S1 and S2, the GREEN and RED LED1 turns on, and the LED looks amber (RED + GREEN).

For a further exercises, try to accomplish the following:

Implement a state machine that walks the three LEDs forward when pressing S1, backwards for SW2, and resets with SW3.

Here’s how the LEDs walk forward:

 

State LED1 LED2 LED3
0 OFF OFF OFF
1 GREEN OFF OFF
2 RED OFF OFF
3 BOTH OFF OFF
4 OFF GREEN OFF

 

Advertisements

7 thoughts on “Lesson 009: GPIO Input

    1. JJMCU-
      I’ve tried doing a lesson using the QSPI flash and the SD-Card, but am having problems with both 😦

      I am currently working with the Renesas team to find out why things are not working as expected. As soon as I get some working code, I can complete the lessons.

      As a side note, the DAC lesson is almost done and I’ll have that up soon.

      Like

  1. Some weeks ago I saw a QSPI example working on my hardware and with SSP 1.1.0. At least I was able to see content written to QSPI in the memory window. The code was slightly modified for my hardware (it can switch between a standard QSPI flash and a QSPI FRAM, so I had to add the right /OE setting for the flash-chip on startup). It was either derived from here http://renesasrulz.com/synergy/f/206/t/6635.aspx or this one: http://renesasrulz.com/synergy/f/206/p/6543/20560.aspx#20560
    Some QSPI code for the DK may be seen here: http://renesasrulz.com/synergy/f/206/p/6234/19481.aspx#19481
    The SK and DK may have different flash-chips, so it may be necessary to set this somewhere, but I think this should be done with selecting the right BSP.

    For the DK the drive strengh of the QSPI pins must be set to “High”, but it depends on the used processor revision: http://renesasrulz.com/synergy/synergy_tech_notes/f/214/t/5894.aspx

    There are a few threads in the forum related to QSPI and at least one article in the Knowledge Base afair. Hope that helps to find the problem.

    I didn’t manage to get the SDC to work, there is an example around, but it is for SSP 1.0.0 or older.

    Like

    1. Josh,

      The problem with the drive strength was fixed in either v1.1 or v1.1.1, and I did confirm that the drive strength is set to high. The support team at Renesas says they can see the code trying to write to the flash, but it isn’t working correctly; hopefully they find the problem. I have a feeling it has something to do with how the SSP code is calculating the address of the flash chip.

      I also have the example code for the SD-Card, and like you said, it was written for v1.0.0 and does not work with v1.1.x. I have yet to try running it on v1.0.0 (although the Renesas support team says they got it to run on their systems).

      Thanks for the ideas and the links; I hope to have a QPSI and SD-Card lesson up soon!

      Like

    1. JY,
      Lesson 9 covers that scenario exactly. If you press and hold a button, an LED turns on. When you let go of the button, the LED goes off.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s