Installation

This section is about setting up your Freerunner GTA02 for running the Aphasia distro. If your phone is a neo1973 GTA01 you can not use OpenWrt, install Debian and start from there.

OpenWrt

Aphasia sits on the OpenWrt platform. A very configurable Linux distribution, and light on system resources. There's a great forum at [1]

Go to OpenWrt, section Build custom image and follow the instructions. When you are at the point Configure target and packages you have to do some choises. Here is the minimum installation for Aphasia:

For some reason the file libmp3lame.so.0 is missing after installation. You can copy ./build_dir/target-arm_uClibc-0.9.30.1/lame-398-2/ipkg-install/usr/lib/libmp3lame.so.0.0.0 to your neo and then make a softlink to /usr/lib/libmp3lame.so.0

Configure gpsd and ser2net

To autostart ser2net and gpsd insert a line in /etc/init.d/httpd, last line in desktop section:

Architecture

Finally its starting to be interesting, how is the Aphasia system built? It's not very common to build systems in Erlang, and definitely rare to build GUI code in it.

Graphics

I'm using vector graphics to produce new widgets. Vector graphics is lightweight and programmable, easy to scale and rotate, and the bytesize is small. Use any vector-capable drawing application. I happen to use AutoCAD LT on Wine, but please suggest an open source alternative and I will be happy to create another small conversion program to translate the new drawing file to erlang source. If you have access to AutoCAD, take dxf2erl.erl from here

Drawing a widget in AutoCAD LT

Convert drawing to erlang source

Where are all the menus?

Aphasia is built for people with different communicative disabilities. Menus where ruled out from the Aphasia GUI from the very beginning due to the fact that you don't even have to have a disability to get lost in a miniature menu system.

Instead I'm using a positioning system where services (I'll talk about those later) are laid out on a large surface (surface of the earth actually) and you can reach a service by swiping the screen in different directions. Another much cooler way to reach a service is when you physically go to a certain place in "real life" (like Jane did in this narrative).

The thing I call a service

A service is often described as a contract between a consumer and a producer. When you go to the barber you know you will get a shave (if you are a man). The service is the implicit contract between you and the barber that he will shave not rub. There are many barber shops down the street offering essentially the same service, so there can be many service producers for one service consumer.

And in the Aphasia system, each service producer is a separate Erlang process. All services are running in parallell, just like in real life. The Erlang VM is quite different from other platforms in that respect, thousands or tens of thousands of processes running at the same time is not uncommon in a well designed Erlang system.

The GSM Service producer

Where should we start if not with the GSM service producer (I will use the name GSM process from now on). What kind of service can we expect from the GSM process, can we expect it to offer a bearer between our phone and some other. The kind of payload we are sending on that bearer is not stated in the service.

The GSM process is always on, it's also invisible. Most processes can display themselves on the screen but the GSM process does never show up, it's running in the background listening and reacting to the different signals coming from the Calypso GSM chip via the ser2net deamon. It is also checking it's own mailbox for messages. Every Erlang process have a private mailbox. It can also send messages to other processes.

If the Calypso GSM chip gets an incomming call, the GSM process sends a message to the Userland process to "go to and start" the Dialer process (remember every process have a GPS position). It also sends a message to the Sound process to act on an incoming call. All this takes no time at all, Erlang is soft-realtime, and at the same moment the caller hears the first ring-tone the neo starts to play (my neo plays Gasoline "This is my life").

The Userland process is the mother of all other processes, and can, if something nasty should happen in the Dialer process, kill it off and start a new Dialer process. That's how Erlang can have 5 nines.

Aphasia Userland Process

The mother of all Aphasia processes. This process can display itself on the screen. It's an empty fullscreen window. And that is the first thing it does, displays itself. Then it creates the backend processes, the Sound process, the GSM process that you already know about, and the GPS process I only mentioned before.

Then it goes into it's main loop. All Erlang processes have a main loop where they receive messages and send messages (if they are built to stay alive).

The GPS process

Just like GSM, this process is invisible and always on. It can on enquiry reply current Lat/Long. It can also periodically send current position to another process. It is using GPSD as it's source of information. As you probably notice by now, each Erlang process is very small and is compliant to the UNIX pattern "do one thing and do it well". The GPS process is currently only 50 lines of code.

The Sound process

Started to code the Sound process (Sound Service Provider - remember ;) this weekend. It's using madplay and aplay together to be able to play mp3's: madplay --output=wave:- /root/" ++ Tune ++ " | aplay --buffer-size=20480. The service can control volume with a call to amixer sset "PCM" VolumeValue.

-module(sound). Every piece of erlang code must have a name. An erlang module is nothing but a piece of code. With a name, for your convienience, so you can easily use it.

-vsn("$Id"). This is a tag for my configuration management system, subversion. You don't need versioning but it's nice to know you can back out of a change in code that just didn't work.

-export([make/1]). This one is important. It tells which functions are public. make() can be called from another module just by a call to sound:make(xxx). The /1 indicates it takes only one argument. If you want all your functions to be public you can use -compile(export_all).

make(Parent) -> spawn_link(fun() -> init(Parent) end). make(Parent) is declared as public and all it does is to spawn (create) a new process and call the init function in that process. Creating a process in erlang is cheap and is comparable to creating a new object in eg. Java.

init(Parent) ->io:format("Sound process is started~n",[]),loop(Parent,null). This process is called by make() as the first thing to do after creating the new process. The name is not important, it can be anything, but it does one imprtant thing except from printing a log message. It is starting the loop.

loop(Parent,Port) -> The loop! Every erlang process have it's own private mailbox. This loop is the place where all incoming messages are taken care of.

receive opens the mailbox and acts just like a case statement.

{setsound,cpugsmhandset} -> If the recieved message looks exactly like this. the following lines of code are executed.

os:cmd("amixer -d sset \"PCM\" 255"), This code calls the module os and a function in that module, cmd(). Yes, it's executing an os command, amixer with a few parameters.

The mimic process

Views

Personal tools

Installation

This section is about setting up your Freerunner GTA02 for running the Aphasia distro. If your phone is a neo1973 GTA01 you can not use OpenWrt, install Debian and start from there.

OpenWrt

Aphasia sits on the OpenWrt platform. A very configurable Linux distribution, and light on system resources. There's a great forum at [1]

Go to OpenWrt, section Build custom image and follow the instructions. When you are at the point Configure target and packages you have to do some choises. Here is the minimum installation for Aphasia:

For some reason the file libmp3lame.so.0 is missing after installation. You can copy ./build_dir/target-arm_uClibc-0.9.30.1/lame-398-2/ipkg-install/usr/lib/libmp3lame.so.0.0.0 to your neo and then make a softlink to /usr/lib/libmp3lame.so.0

Configure gpsd and ser2net

To autostart ser2net and gpsd insert a line in /etc/init.d/httpd, last line in desktop section:

Architecture

Finally its starting to be interesting, how is the Aphasia system built? It's not very common to build systems in Erlang, and definitely rare to build GUI code in it.

Graphics

I'm using vector graphics to produce new widgets. Vector graphics is lightweight and programmable, easy to scale and rotate, and the bytesize is small. Use any vector-capable drawing application. I happen to use AutoCAD LT on Wine, but please suggest an open source alternative and I will be happy to create another small conversion program to translate the new drawing file to erlang source. If you have access to AutoCAD, take dxf2erl.erl from here

Drawing a widget in AutoCAD LT

Convert drawing to erlang source

Where are all the menus?

Aphasia is built for people with different communicative disabilities. Menus where ruled out from the Aphasia GUI from the very beginning due to the fact that you don't even have to have a disability to get lost in a miniature menu system.

Instead I'm using a positioning system where services (I'll talk about those later) are laid out on a large surface (surface of the earth actually) and you can reach a service by swiping the screen in different directions. Another much cooler way to reach a service is when you physically go to a certain place in "real life" (like Jane did in this narrative).

The thing I call a service

A service is often described as a contract between a consumer and a producer. When you go to the barber you know you will get a shave (if you are a man). The service is the implicit contract between you and the barber that he will shave not rub. There are many barber shops down the street offering essentially the same service, so there can be many service producers for one service consumer.

And in the Aphasia system, each service producer is a separate Erlang process. All services are running in parallell, just like in real life. The Erlang VM is quite different from other platforms in that respect, thousands or tens of thousands of processes running at the same time is not uncommon in a well designed Erlang system.

The GSM Service producer

Where should we start if not with the GSM service producer (I will use the name GSM process from now on). What kind of service can we expect from the GSM process, can we expect it to offer a bearer between our phone and some other. The kind of payload we are sending on that bearer is not stated in the service.

The GSM process is always on, it's also invisible. Most processes can display themselves on the screen but the GSM process does never show up, it's running in the background listening and reacting to the different signals coming from the Calypso GSM chip via the ser2net deamon. It is also checking it's own mailbox for messages. Every Erlang process have a private mailbox. It can also send messages to other processes.

If the Calypso GSM chip gets an incomming call, the GSM process sends a message to the Userland process to "go to and start" the Dialer process (remember every process have a GPS position). It also sends a message to the Sound process to act on an incoming call. All this takes no time at all, Erlang is soft-realtime, and at the same moment the caller hears the first ring-tone the neo starts to play (my neo plays Gasoline "This is my life").

The Userland process is the mother of all other processes, and can, if something nasty should happen in the Dialer process, kill it off and start a new Dialer process. That's how Erlang can have 5 nines.

Aphasia Userland Process

The mother of all Aphasia processes. This process can display itself on the screen. It's an empty fullscreen window. And that is the first thing it does, displays itself. Then it creates the backend processes, the Sound process, the GSM process that you already know about, and the GPS process I only mentioned before.

Then it goes into it's main loop. All Erlang processes have a main loop where they receive messages and send messages (if they are built to stay alive).

The GPS process

Just like GSM, this process is invisible and always on. It can on enquiry reply current Lat/Long. It can also periodically send current position to another process. It is using GPSD as it's source of information. As you probably notice by now, each Erlang process is very small and is compliant to the UNIX pattern "do one thing and do it well". The GPS process is currently only 50 lines of code.

The Sound process

Started to code the Sound process (Sound Service Provider - remember ;) this weekend. It's using madplay and aplay together to be able to play mp3's: madplay --output=wave:- /root/" ++ Tune ++ " | aplay --buffer-size=20480. The service can control volume with a call to amixer sset "PCM" VolumeValue.

-module(sound). Every piece of erlang code must have a name. An erlang module is nothing but a piece of code. With a name, for your convienience, so you can easily use it.

-vsn("$Id"). This is a tag for my configuration management system, subversion. You don't need versioning but it's nice to know you can back out of a change in code that just didn't work.

-export([make/1]). This one is important. It tells which functions are public. make() can be called from another module just by a call to sound:make(xxx). The /1 indicates it takes only one argument. If you want all your functions to be public you can use -compile(export_all).

make(Parent) -> spawn_link(fun() -> init(Parent) end). make(Parent) is declared as public and all it does is to spawn (create) a new process and call the init function in that process. Creating a process in erlang is cheap and is comparable to creating a new object in eg. Java.

init(Parent) ->io:format("Sound process is started~n",[]),loop(Parent,null). This process is called by make() as the first thing to do after creating the new process. The name is not important, it can be anything, but it does one imprtant thing except from printing a log message. It is starting the loop.

loop(Parent,Port) -> The loop! Every erlang process have it's own private mailbox. This loop is the place where all incoming messages are taken care of.

receive opens the mailbox and acts just like a case statement.

{setsound,cpugsmhandset} -> If the recieved message looks exactly like this. the following lines of code are executed.

os:cmd("amixer -d sset \"PCM\" 255"), This code calls the module os and a function in that module, cmd(). Yes, it's executing an os command, amixer with a few parameters.