Smart Chef Demo With Cloud Driven GPIO – Completed with Modifications



I have been meaning to go through this tutorial for awhile now, but due to my inexperience with e2 Studio, I had not been able to get it to work. In this post, I’ll try to fill in a few of the blanks so that it is a little more accessible. I made a few modifications which I’ll introduce along the way.

Here’s the original:

Note 1: Before starting the GPIO tutorial, I strongly recommend completing Craig’s excellent tutorial on building the smart chef demo from source located here:

In the GPIO tutorial, you will be building a slightly modified Smart Chef Demo from source, so if you’ve never done that before, the tutorial will show you how. There is another critical piece of missing information regarding the .pack file that comes with the source distribution from Renesas. Here are the contents of the downloaded file with the .pack file highlighted.

This file must be manually placed in the correct Renesas file in order for e2 Studio to have necessary information about the S3A7 demo board. The details are specified in Craig’s tutorial.

Note 2: I found that my pushbutton switch had so much bounce that the software debounce suggested in the demo didn’t work all the time. Rather than fiddle with that, I thought it would be educational to use an extra GPIO pin to generate the falling edge needed to trigger the irq. I modified the workflows so that every time you tap the LCD screen, this GPIO pin outputs a ~10msec pulse. The LCD now acts as a switch replacement. Of course you could just drive the LED directly, but this is an educational exercise! The goal was to test one of the other GPIO pins and also replace the switch with something cleaner.

While you are configuring Port 3, Pin 4 in step 5 of the GPIO tutorial, also go ahead and configure Port 3, Pin 15 as an output as shown below. This GPIO output is connected to pin 10 of PMOD D according to the schematic shown in the tutorial.

Note 3: After completing steps 6-9 where you generate, modify and build the project, e2 Studio showed two bugs in the sensor_thread_entry.c file as shown below. The field “event_b” could not be resolved. I don’t understand this whole project well enough to know what the problem is. Fortunately, you can ignore it! I just kept going, and it worked anyway. I’d love to have someone at Medium One/Renesas clarify what the bugs are all about.

Note 4: For step 10 in the tutorial, the revised schematic and a couple of photos are shown below. My red wire corresponds to the orange wire in the GPIO tutorial. My yellow corresponds to yellow, and my black wire corresponds to the brown wire in the tutorial. Their positions are the same. I added the white wire to PMOD D pin 10, and connected it to the red wire on the bread board.

Note 5: The modified workflow is shown below. Just as in the original tutorial, the LED toggles every minute in response to the scheduled trigger. It toggles in response to a tap on the LCD screen rather than the the pushbutton. I also added a mobile trigger using the mobile app. I just configured a push button in the mobile app to transmit a raw:mobile_led_toggle trigger, so you can toggle the LED three ways. The behavior is much more reliable without the bounce associated with the switch.

Of course, it is not necessary to modify the original tutorial, but I thought it would be fun to play around with it a bit. I also had a very noisy switch. Here’s the new code:

April 25, 2017

Modified from original LED Toggling by DK.  It still behaves the same, however, the interrupt behavior is more
reliable since there is no longer switch bounce to worry about.  My switch sometimes bounced more than the software
debounce could handle resulting in unexpected behavior.

Every minute the LED changes state because of the scheduled trigger.  At any time, touching the LCD screen also causes
the LED to change state.  Just for fun, I also added a mobile trigger so that every time you press a button on the
mobile app, the LED toggles.

import MQTT
import Store

def read_pin(pin, tag):
    send_mqtt_msg(u'0;4;{};{};'.format(pin, tag));

def write_pin(pin, val):
    send_mqtt_msg(u'0;3;{};{};'.format(pin, val));

def send_mqtt_msg(msg):
    mqtt_msg = msg
    if not isinstance(msg, basestring):
        mqtt_msg = ''.join(map(unichr, msg))
    MQTT.publish_event_to_client('s3a7', mqtt_msg, 'latin1')
NOTE: The debounce routine is no longer needed because rather than using a switch, we're using another GPIO to
generate a clean falling edge every time the LCD screen is tapped.

# debounce
in1 = IONode.get_input('in1')
if IONode.is_trigger('in1'):
    last_2_interrupts = Analytics.last_n_values('raw.interrupt', 2)
    if len(last_2_interrupts) > 1:
        if DateConversion.to_py_datetime(in1['observed_at']) - DateConversion.to_py_datetime(last_2_interrupts[1]['observed_at']) < datetime.timedelta(seconds=1):
# end debounce

    prev_state = int(Store.get('prev_state'))
except (ValueError, TypeError):
    prev_state = 0

# toggle LED state

next_state = 0 if prev_state else 1
write_pin(0, next_state)
Store.set_data('prev_state', str(next_state))

Here is the second workflow you need to handle the touchscreen based interrupts.

Here is the touchscreen code:

This workflow generates a ~10msec square pulse on PMOD D pin 10.  This is connected to 
GPIO Port 3, Pin 15 on the S3A7 which must be configured as an output.


import MQTT
import time

def read_pin(pin, tag):
    send_mqtt_msg(u'0;4;{};{};'.format(pin, tag));

def write_pin(pin, val):
    send_mqtt_msg(u'0;3;{};{};'.format(pin, val));

def send_mqtt_msg(msg):
    mqtt_msg = msg
    if not isinstance(msg, basestring):
        mqtt_msg = ''.join(map(unichr, msg))
    MQTT.publish_event_to_client('s3a7', mqtt_msg, 'latin1')

write_pin(7, 1) #Parameter '7' refers to PMOD D pin 10.  Set it high.
time.sleep(0.01) #Sleep for 10msec -- Note that sleeping for too long triggers various system time outs
write_pin(7, 0) #Clean falling edge to trigger an interrupt on PMOD D pin 7 (S3A7 Port 3 Pin 4) - No debounce needed

Final thoughts: I tried to turn on and off some LEDs every few seconds using the time.sleep() function. This always generated time out errors. I tried putting the sleep function in a separate thread but that didn’t seem to work. I’ll have to follow up with Medium One to see if the Python scripts in their system support threading. In any case, my 10msec pulse was generated using time.sleep() and that is apparently short enough that it doesn’t cause any problems.

Thanks to Medium One for this great tutorial. I wrote this up because when I first tried the tutorial I didn’t know enough to get it working. I hope this clarifies things a bit for others. I’m always happy to help if anyone has questions about what I did here.

S5D9 HowTo: Cloud-Driven LEDs with On-Board LEDs
SK-S3A7 Tutorials
Cloud GPIO for S5D9
Quick Tutorial: Building Renesas Synergy Smart Chef Demo from Source
Learn IoT Meetup - September 27, San Jose

This is so cool. I want to build it. I went through my parts bin under my desk and realized that I have a ton of electronic components and breadboards from old projects. Maybe I’ll get the motivation to bust out the breadboard again.




@jcasman do it.


The first thing I did was to figure out which is pin 1 of the PMOD. Can you confirm that pin 1 is in the upper right? Is this the correct orientation?

In the picture below, I’m assuming that the yellow wire is PMOD pin 1 and the red wire is in PMOD pin 7. The black wire is in PMOD pin 5 and the white wire is in PMOD pin 10. Looking at the PCB, I see a little white arrow now next to the pin that I think is pin 1. Hopefully, this is correct. If not let me know.

Looking at the schematic below, it seems like

  • PMOD Pins 1 (yellow wire) is P2_5/SSLB0,
  • PMOD pin 7 (red wire) is 3V (with J12 jumper connecting pins 1 and 2) - fed through 10K resistor
  • Pin 5 (black wire) is ground

If this is correct, I’ll give it a go.


I’m stuck. In step 12, Select Raw Tag Interrupt, I don’t have a raw tag interrupt.


Alright, I take up your challenge! I don’t have the right parts for this specific tutorial from @dan , but I’m digging into a tutorial this weekend, for sure.


Just to confirm that the challenge is to complete any tutorial, not necessarily this one. Sadly, I’m really stuck and can’t figure out how to add the interrupt tag to the raw stream. This might be something where I can an answer from @Dan in the next week and thus probably won’t be able to finish this tutorial today.

I don’t see this.

I need that in order to create the workflow.

I do feel like I made a decent attempt.

I completed the modifications to sensor_thread_entry.c. Build and transfer went smoothly.

I tested the LED and switch functionality to make sure that the LED lights up and isn’t burnt out.

I’m stuck at creating a new tag for interrupt on Medium One.

Reading through the document, it should get the data from the board (I think)

Every time a new tag is sent to Medium One, it is auto-detected and will appear in it’s respective stream. The values that are sent with the Tags can vary in each event. (i.e. battery_level can be 100 in one event and 75 in the next).

Data Types for each new tag are also auto-detected and will be further explained in the Data Types section below.

I’d really like to hear from Dan if he needed to do anything special to access raw:interrupt.


I know Dan’s up in the mountains today, largely out of phone range. He’s one of those rugged individuals who likes the great outdoors. Not sure when’s he’s back, I think a day or two, but I bet he helps out then.


Did he bring a satellite phone to the mountains? I want to ask him about the raw stream.


I was able to enable raw.interrupt

I’m getting closer.


Fully Functional!!

The Glory

Full Action Video

The Data in the Cloud

I need to get the touchscreen working next.

@jcasman You’re up! Rise to the challenge.


The glory! I want some of the glory! I’m on it, I’ll be working on a tutorial this weekend for sure. Those pictures and videos are great. Nice work!


More colorful LEDs, all driven by the Renesas IoT Sandbox cloud-driven GPIO.


Solution to raw:interrupt not appearing

This is the problem I had and what the fix was.


On the Renesas IoT Sandbox, the raw:interrupt event was not appearing.

This element was not listed.

Identifying Source of Problem

I realized that the listing of raw:interrupt came from the S3A7 board. The Renesas IoT Sandbox was taking the tags from the information sent by the S3A7 board. I was getting clean complies with e2 Studio and Synergy. All the code modifications looked accurate.

Since the tutorial only modifies sensor_thread_entry.c, I first suspected that I didn’t add something.

This provided to be a dead-end investigation as the code looked accurate. I then looked at the the m1_synergy_cloud_driver. That led to the solution in my case.


When you unzip smartchef, there is a folder called m1.

That folder is already populated with what appears to be the necessary files.

The tutorial refers to a separate m1_synergy_cloud_driver package that contains these files.

I assumed that the documentation was outdated and that the smartchef package had up to date versions of libcloud-driver.a and m1_cloud_driver.h. Thus, in my first attempt, I didn’t overwrite the m1 files from smartchef with the m1 files from the separate package.

After I overwrote the files in smartchef with the files from the m1 standalone package, I cleaned the old build and did a new build. After that, everything started to work.

This was very satisfying. It’s been a while since I played around with wires and resistors. To be honest, I can’t even read the resistor values without a chart now days. Also, I can’t find a lot of my equipment which I vaguely recall owning. I think I had a third hand with a nice base and magnifying glass. Maybe it’s in the garage? Maybe I threw it out? I did find several breadboards, wires, resistors, several hundred LEDs in different colors, two voltmeters (still functional).

Also, when I started to look at the pins of the board, the 3V and 5V looked familiar. I guess those values haven’t changed in a while. It’s a nice way to dip my toe in the water. Honestly, I know nothing about I2C and SPI, but maybe this will be a way to learn a bit.


Another tip. I’m using SSP 1.1.3


Happy to report that I was able to implement Dan’s hack to control the LEDs with the touchscreen and the Medium One workflow.

Bring on the IoT startup and venture funding! We have an LED blinking. :slight_smile:

But seriously, @Dan has really made a breakthrough recently with many inputs to the cloud:

  1. physical button
  2. LCD touchscreen
  3. mobile

With this demo, we’re also getting a lot of sensor data which could trigger events as well. seems like we’re finally starting to get the basics of usable techniques.

Might be interesting to experiment with different inputs using the tutorial below as a base to add additional sensors to the S3A7.

I just followed the tutorial to verify that it worked. I don’t understand it. For example, I don’t understand the Channel, which I’m guessing is pretty easy to understand once I find an explanation. The part that might be more difficult is the slave address. How did they find this?

The other, possibly bigger issue is how the python module for cloud_driver_sensiron was created. I see the import section, but not how the module was created. Is the module auto-generated?

# this import the cloud driver for the sensirion sensor
import cloud_driver_sensirion

I wonder if it’s related to the R_RIIC driver above and Medium One automatically creates a python module from the driver? If so, that would be cool.


Now with mobile control of the LEDs working. Thanks @Dan!


Hi Craig,

Sorry I wasn’t around to help. I was indeed in the mountains out of cell phone range. As you pointed out, you definitely have to update the libcloud-driver.a and m1_cloud_driver.h files. Once that is done, triggering the interrupt does send the tag. My alternate quick and dirty way of getting tags to show up so you can use them is to use the JSON widget on the mobile app. You select a stream which in this case is ‘raw.’ Then, you type in any tag you want which in this case would be, ‘interrupt.’ Then you send it. After that, it appears in the data stream. I’ve used that technique several times to get new tags entered into workflows for the first time.

I’m glad you got it working! I also forgot to mention that for my LEDs, the recommended 100 ohm resisters seemed to allow a needlessly large current flow. I bumped mine up to 270 at least. Dan

Learn IoT Meetup - September 27, San Jose
S5D9 Anomaly Monitoring Tutorial Walkthrough

Dan, thanks for these additional tips. It’s good to know that the libcloud-driver.a and m1_cloud_driver.h files need to be updated. Also, I didn’t know about getting the tag to appear in the data stream with the JSON widget of the mobile app. Right now, I’m using 200 ohm resistors, but I think 270 like you’re using or 320 would be better. I just had the 200 ohm resistors lying around.

I was pretty proud that I managed to figure out the resistance value by using a color code chart, but then I realized that the resistor was sitting next to an ohmmeter.

I’m very interested in playing around with these pins more. I’m assuming that the pins can be used for pulse-width modulation. Do you know how I can control the frequency? Maybe start with something simple like controlling the brightness of the LED through PWM and then moving to a piezo buzzer and then servo,

One simple application is to sample air quality and then when the air quality surpasses a certain threshold, take these actions:

  1. turn on LED as visual alarm
  2. sound audio alarm (with piezo) :trumpet:
  3. open window (toy window controlled by servo)

I used to have a bunch of servos lying around, but I can’t find them right now. If I had a PWM signal, then maybe it might spur me on to search for them. :slight_smile:


Hi Craig

did you found what is channel ? I was looking exact same details