Lua real multithreading using Lanes and Linda

Introduction

In this post I’ll share my first impression and thoughts about developing mulithreaded applications in lua.
When developing in lua you may have realized that there is no such thing as multithreading, but there is a concept that is propposed as an alternative, called coroutines, which is useful for developing single-threaded applications and sharing the processor between several routines.
Coroutines may be the desired approach for several programs, but sometimes real multithreading is required, as in the case of 2 routines that must execute simultaneously and at a different frequency or when you need a thread to block waiting for user input while doing some background processing. There are lots of examples about this, but I think I made my point.
In my case I wanted to implement a keyboard controlled wheeled robot, so I needed 2 threads, one that would block waiting for user input (arrow keys), and another which would use the input values to control my robot.

Lanes

In order to develop the keyboard controlled robot I found a multithreading library for lua called Lua Lanes (you can find more information in the LuaLanes github project), which allows running multiple lua states in parallel.
Installing Lua Lanes is very easy, just run from the terminal:

luarocks install lanes

After installing I tried the lua scripts proposed as examples in the page, but for my surprise, they didn’t work!
I am using lua version 5.1 and Lua Lanes dated december 2010, and in my case, looking at examples and by trial and error I got to a very simple and working example, which runs 2 functions in parallel, here is the script:

–import extension and initialize
lanes = require "lanes".configure()

–thread 1 function
local function loop1( )
while true do
print("loop1")
os.execute("sleep 0.1")
end
end

–thread 2 function
function loop2()
while true do
print("loop2")
os.execute("sleep 0.1")
end
end

–create and start the threads, notice the ‘()’ to start the thread. you can parameters to the function.
thread1= lanes.gen("*",loop1)()
thread2= lanes.gen("*",loop2)()

This script works fine for me, it should work also for you. You could even define each loop in different lua files, decoupling the function from the threads script.

Linda

After successfully running lua lanes, the only thing left is to pass data from one lane (thread) to another. The api to do this is called Linda, which offers two ways of sending data between lanes:

  • Data queue, as a producer/consumer way (send/receive functions)
  • Single Data slot, which is overriden every time it’s written to (set/get functions)

There is some example using send and receive functions in the lanes documentation, and here is a working example using set and get.

lanes = require "lanes".configure()

local linda= lanes.linda()

local function loop( )
for i=1,10 do
print( "sending: "..i )
linda:set( "x", i )
end
print("end sender")
end

function receiver()
while true do
print("receiving")
local val= linda:get( "x" )
if val==nil then
print( "nil received" )
–break
else
print( "received: "..val )
break
end

end
print("end receiver")
end

a= lanes.gen("*",loop)()
b= lanes.gen("*",receiver)()

Conclusions and considerations

Lanes and Lindas are a nice alternative to multithreading in lua, since there are no built in functionality to do this.
It may be seem not trivial to configure it at the beginning, but once you have a working example it works fine.
Last but not least, it’s not trivial to find errors on a specific lane; in case one lane stops running due to a failed assertion or some other error, that lane won’t print an error to the console and will stop running. This can be avoided by not using assert, printing errors and exit the program in case an error is detected to signal other lanes to stop.

Advertisements

Simon says game in BeagleBoard SBC

Introduction

In my last post about GPIO and LEDs in lua I wrote about a nice feature in Linux when working on embedded systems, such as the possibility to access hardware devices using the file system.
In this post I’ll be using this feature to build the game ‘Simon says’ in lua. I’ll be using a BeagleBoard rev C4 with ubuntu 11.04 installed.
We made this project with my colleagues for an embedded robotics course, so the credit is also shared with them ๐Ÿ™‚

GPIOs in the Beagleboard Note

According to the Beagleboard datasheet, the processor can be configured to use all the pins in the expansion port as GPIOs, but this is a more advanced task which requires changing the MUX registers in the processor, which can be achieved by recompiling the kernel changing the kernel headers.
The Ubuntu image for Beagleboard already has several pins configured as GPIO. Thanks to Michael Shiloh, he found the pins that can be used as GPIO by default. This is the list of GPIOs you can use (and the corresponding pin in the expansion port):

  • 157 (pin 22)
  • 159 (pin 18)
  • 161 (pin 16)
  • 162 (pin 14)
  • 136 (pin 9)
  • 137 (pin 7)
  • 138 (pin 5)
  • 139 (pin 3)

For a reference on the pin number for each of these GPIOs read the Beagleboard datasheet.

Development

For this game I only used 3 LEDS, because at that time I didn’t have more of these ๐Ÿ™‚ but it’s very easy to add more.
I used 3 GPIO ports to connect the LEDs and 3 for the buttons. Using the default ubuntu installation I could plug 4 leds and 4 buttons. If I wanted more, I should tune the kernel as said earlier in the post.

Connecting the leds and buttons

The picture below shows how everything is connected. It works as a proof of concept, but I wouldn’t give this to anyone to play ๐Ÿ˜›

Since the picture does not explain this clearly
I used pins 3,5,7 (GPIO 139,138,137 respectively) as input for the buttons and pins 12,14,16 (GPIO 158,162,161 respectively) as output GPIOs for the LEDs.
The diagram below shows how to connect the buttons and leds.

Source code

The source code is available in Github https://github.com/rsisto/simonSaysLuaGpio
The source code is quite simple, The GPIO library explained in the GPIO post was used to interface with the leds and buttons.
The rest of the code is just a main loop implementing the game logic. When the user loses, the leds blink several times and the application quits.

That’s it for now. Let me know if you have any comments or if the code was any use for you! Please share! ๐Ÿ˜€

GPIO and LEDs in Linux and lua

Hi all,

In my previous posts I wrote about my development in Java, but this time I’ll talk about other area I’m working on, robotics. This time I’ll talk about some basics, managing General Purpose Input Output (GPIO) and LEDs in Linux using the terminal, and also using lua, a very lightweight and portable language.

Basics

When working with embedded robotics or electronics interfacing with computers, it is (often) a good idea to work with linux for several reasons, just to mention a few:

  • Open source: It’s easy to customize the distro, so you can leave out parts of the OS you won’t use, making it more lightweight to run in an embedded system.
  • Portability: Linux kernel is portable to a huge amount of architectures, making it very attractive for use in embedded robotics.
  • Community: There is a big community out there using linux to develop embedded systems, developing new features to linux, testing, discussing and so on.

GPIO and LED filesystem in Linux

When working in linux there other great advantage is that you can control de LEDs and GPIO just by accessing the file system, without the need of any drivers. For example, if you want to control the built in LEDs you would use the /sys/class/leds/ portion of the file system. For GPIOs you’ll use /sys/class/gpio/
Using the file system it’s possible to control these hardware components from any linux terminal and easily create a program that uses them.
In the next sections I’ll explain how to use them from both alternatives.

managing built-in LEDs with the terminal

It’s very easy to control the built-in LEDs, I’ll show you how in this section.
Open a terminal and go to superuser (superuser permissions are needed in order to work with GPIOs and LEDs by default, although it is possible to change this with some OS rules):

sudo su

when listing the directory /sys/class/leds on my laptop I see these items:

root@rafael-vaio:/sys/class/leds# ls
ath9k-phy0  mmc0::  mmc1::

I’ll show you how to control the LED mmc1:: (on my laptop it’s the one near the memory card slot). First, when listing the contents of the mmc1:: folder I see these items:

root@rafael-vaio:/sys/class/leds# ls /sys/class/leds/mmc1\:\:/
brightness  device  max_brightness  power  subsystem  trigger  uevent

The important files here are brightness and trigger. brightness, as you’ll guess, it’s the file that stores the status of the led. trigger is which trigger will change the status of the led, you can see this using:

root@rafael-vaio:/sys/class/leds# cat /sys/class/leds/mmc1\:\:/trigger 
none ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid mmc0 [mmc1] rfkill0 rfkill1 rfkill2 rfkill3 phy0rx phy0tx phy0assoc phy0radio phy0tpt 

The value between the square brackets is the current trigger for this led (in this case, mmc1). To change this (remember the previous value since you should change it back when you finish), just run

root@rafael-vaio:/sys/class/leds# echo none > /sys/class/leds/mmc1\:\:/trigger 

From now on, there is no system trigger that’ll change this led, so it’s going to be only you changing the value.
To change the value and read it:

root@rafael-vaio:/sys/class/leds# echo 1 > /sys/class/leds/mmc1\:\:/brightness 
root@rafael-vaio:/sys/class/leds# cat /sys/class/leds/mmc1\:\:/brightness 
1
root@rafael-vaio:/sys/class/leds# echo 0 > /sys/class/leds/mmc1\:\:/brightness 
root@rafael-vaio:/sys/class/leds# cat /sys/class/leds/mmc1\:\:/brightness 
0

And voila, as simple as that you can start playing with the leds ๐Ÿ™‚

managing GPIO using the terminal

The GPIOs are pins that are input/output pins that are connected to the processor, and in Linux it is very straightforward to configure and use them.
This is a bit more complex to test from your pc, since you need to physically access the GPIOs of the processor. In my case, I’ll be using these from a Single Board Computer with linux to read the value of sensors and send commands to actuators on my robotics projects. If you already own one of these, you probably already know how to control them, but if not, there are several options to start with. You can look at the List of single-board computers in wikipedia. In my experiments I used a BeagleBoard rev C4 which has several accessible GPIOs in the expansion bus.

So, shall we?
The steps to control a GPIO in linux are these:

  1. export the GPIO
  2. configure the GPIO as input or output
  3. set the value / read the value

The first step is to export the GPIO, this will tell linux that we’ll be handling the GPIO from the file system. We’ll work in the /sys/class/gpio portion of the fs.
When listing the contents of /sys/class/gpio/ we’ll see only two files: export and unexport. In order to initialize the GPIO with id 56 run:

echo 56 > /sys/class/gpio/export

This will create a folder gpio56 with the following content:

ls /sys/class/gpio/gpio56
direction  edge  power  subsystem  uevent  value

To set the direction (in/out), echo the value ‘in’ or ‘out’ to the direction file:

echo out /sys/class/gpio/gpio56/direction

To set the value, just change the value file, similar as we did with the leds (values 1 or 0):

echo 1 /sys/class/gpio/gpio56/value

That’s it. If you want to use the pin as an input, you should echo ‘in’ to the direction file and read the value file with ‘cat’

LEDs and GPIO using lua

lua is a high level language which has a very small footprint, and runs as fast as a C program. This is desirable when working with embedded systems, since we need to save every last bit of memory.

It is very simple to write a program that uses the led or the gpio filesystem, you just need to execute the commands seen previously and that’s it.
You can check out the code of the simple GPIO lua library I uploaded to Github.

That’s it for now, I’ll be posting more on embedded robotics next week. Let’s talk in the comments!