Embedded, Kernel, Linux

BPF Internals – I

Recent post by Brendan Gregg inspired me to write my own blog post about my findings of how Berkeley Packet Filter (BPF) evolved, it’s interesting history and the immense powers it holds – the way Brendan calls it ‘brutal’. I came across this while studying interpreters and small process virtual machines like the proposed KTap’s VM. I was looking at some known papers on register vs stack basd VMs, their performances and various code dispatch mechanisms used in these small VMs. The review of state-of-the-art soon moved to native code compilation and a discussion on LWN caught my eye. The benefits of JIT were too good to be overlooked, and BPF’s application in things like filtering, tracing and seccomp (used in Chrome as well) made me interested. I knew that the kernel devs were on to something here. This is when I started digging through the BPF background.


Network packet analysis requires an interesting bunch of tech. Right from the time a packet reaches the embedded controller on the network hardware in your PC (hardware/data link layer) to the point they do someting useful in your system, such as display something in your browser (application layer). For connected systems evolving these days, the amount of data transfer is huge, and the support infrastructure for the network analysis needed a way to filter out things pretty fast. The initial concept of packet filtering developed keeping in mind such needs and there were many stategies discussed with every filter such as CMU/Stanford packet Filter (CSPF), Sun’s NIT filter and so on. For example, some earlier filtering approaches used a tree based model (in CSPF) to represenf filters and filter them out using predicate-tree walking. This earlier approach was also inherited in the Linux kernel’s old filter in the net subsystem.

Consider an engineer’s need to have a probably simple and unrealistic filter on the network packets with the predicates P1, P2, P3 and P4 :


Filtering approach like the one of CSPF would have represented this filter in a expression tree structure as follows:


It is then trivial to walk the tree evaluating each expression and performing operations on each of them. But this would mean there can be extra costs assiciated with evaluating the predicates which may not necessarily have to be evaluated. For example, what if the packet is neither an ARP packet nor an IP packet? Having the knowledge that P1 and P2 predicates are untrue, we may need not have to evaluate other 2 predicates and perform 2 other boolean operation on them to determine the outcome.

In 1992-93, McCanne et al. proposed a BSD Packet Filter with a new CFG-bytecode based filter design. This was an in-kernel approach where a tiny interpreter would evaluate expressions represented as BPF bytecodes. Instead of simple expression trees, they proposed a CFG based filter design. One of the control flow graph representation of the same filter above can be:


The evaluation can start from P1 and the right edge is for FALSE and left is for TRUE with each predicate being evaluated in this fashion until the evaluation reaches the final result of TRUE or FALSE. The inherent property of ‘remembering’ in the CFG, i.e, if P1 and P2 are false, the path reaches a final FALSE is remembered and P3 and P4 need not be evaluated. This was then easy to represent in bytecode form where a minimal BPF VM can be designed to evaluate these predicates with jumps to TRUE or FALSE targets.

The BPF Machine

A pseudo-instruction representation of the same filter described above for earlier versions of BPF in Linux kernel can be shown as,

l0:	ldh [12]
l1:	jeq #0x800, l3, l2
l2:     jeq #0x805, l3, l8
l3:	ld [26]
l4:	jeq #SRC, l4, l8
l5:     ld len
l6:     jlt 0x400, l7, l8
l7:	ret #0xffff
l8:	ret #0

To know how to read these BPF instructions, look at the filter documentation in Kernel source and see what each line does. Each of these instructions are actually just bytecodes which the BPF machine interprets. Like all real machines, this requires a definition of how the VM internals would look like. In the Linux kernel’s version of the BPF based in-kernel filtering technique they adopted, there were initially just 2 important registers, A and X with another 16 register ‘scratch space’ M[0-15]. The Instruction format and some sample instructions for this earlier version of BPF are shown below:

/* Instruction format: { OP, JT, JF, K }
 * OP: opcode, 16 bit
 * JT: Jump target for TRUE
 * JF: Jump target for FALSE
 * K: 32 bit constant

/* Sample instructions*/
{ 0x28,  0,  0, 0x0000000c },     /* 0x28 is opcode for ldh */
{ 0x15,  1,  0, 0x00000800 },     /* jump next to next instr if A = 0x800 */
{ 0x15,  0,  5, 0x00000805 },     /* jump to FALSE (offset 5) if A != 0x805 */

There were some radical changes done to the BPF infrastructure recently – extensions to its instruction set, registers, addition of things like BPF-maps etc. We shall discuss what those changes in detail, probably in the next post in this series. For now we’ll just see the good ol’ way of how BPF worked.


Each of the instructions seen above are represented as arrays of these 4 values and each program is an array of such instructions. The BPF interpreter sees each opcode and performs the operations on the registers or data accordingly after it goes through a verifier for a sanity check to make sure the filter code is secure and would not cause harm. The program which consists of these instructions, then passes through a dispatch routine. As an example, here is a small snippet from the BPF instruction dispatch for the instruction ‘add’ before it was restructured in Linux kernel v3.15 onwards,

127         u32 A = 0;                      /* Accumulator */
128         u32 X = 0;                      /* Index Register */
129         u32 mem[BPF_MEMWORDS];          /* Scratch Memory Store */
130         u32 tmp;
131         int k;
133         /*
134          * Process array of filter instructions.
135          */
136         for (;; fentry++) {
137 #if defined(CONFIG_X86_32)
138 #define K (fentry->k)
139 #else
140                 const u32 K = fentry->k;
141 #endif
143                 switch (fentry->code) {
144                 case BPF_S_ALU_ADD_X:
145                         A += X;
146                         continue;
147                 case BPF_S_ALU_ADD_K:
148                         A += K;
149                         continue;
150 ..

Above snippet is taken from net/core/filter.c in Linux kernel v3.14. Here, fentry is the socket_filter structure and the filter is applied to the sk_buff data element. The dispatch loop (136), runs till all the instructions are exhaused. The dispatch is basically a huge switch-case dispatch with each opcode being tested (143) and necessary action being taken. For example, here an ‘add’ operation on registers would add A+X and store it in A. Yes, this is simple isn’t it? Let us take it a level above.

JIT Compilation

This is nothing new. JIT compilation of bytecodes has been there for a long time. I think it is one of those eventual steps taken once an interpreted language decides to look for optimizing bytecode execution speed. Interpreter dispatches can be a bit costly once the size of the filter/code and the execution time increases. With high frequency packet filtering, we need to save as much time as possible and a good way is to convert the bytecode to native machine code by Just-In-Time compiling it and then executing the native code from the code cache. For BPF, JIT was discussed first in the BPF+ research paper by Begel etc al. in 1999. Along with other optimizations (redundant predicate elimination, peephole optimizations etc,) a JIT assembler for BPF bytecodes was also discussed. They showed improvements from 3.5x to 9x in certain cases. I quickly started seeing if the Linux kernel had done something similar. And behold, here is how the JIT looks like for the ‘add’ instruction we discussed before (Linux kernel v3.14),

288                switch (filter[i].code) {
289                case BPF_S_ALU_ADD_X: /* A += X; */
290                        seen |= SEEN_XREG;
291                        EMIT2(0x01, 0xd8);              /* add %ebx,%eax */
292                        break;
293                case BPF_S_ALU_ADD_K: /* A += K; */
294                        if (!K)
295                                break;
296                        if (is_imm8(K))
297                                EMIT3(0x83, 0xc0, K);   /* add imm8,%eax */
298                        else
299                                EMIT1_off32(0x05, K);   /* add imm32,%eax */
300                        break;

As seen above in arch/x86/net/bpf_jit_comp.c for v3.14, instead of performing operations during the code dispatch directly, the JIT compiler emits the native code to a memory area and keeps it ready for execution.The JITed filter image is built like a function call, so we add some prologue and epilogue to it as well,

/* JIT image prologue */
221                EMIT4(0x55, 0x48, 0x89, 0xe5); /* push %rbp; mov %rsp,%rbp */
222                EMIT4(0x48, 0x83, 0xec, 96);    /* subq  $96,%rsp       */

There are rules to BPF (such as no-loop etc.) which the verifier checks before the image is built as we are now in dangerous waters of executing external machine code inside the linux kernel. In those days, all this would have been done by bpf_jit_compile which upon completion would point the filter function to the filter image,

774                 fp->bpf_func = (void *)image;

Smooooooth… Upon execution of the filter function, instead of interpreting, the filter will now start executing the native code. Even though things have changed a bit recently, this had been indeed a fun way to learn how interpreters and JIT compilers work in general and the kind of optimizations that can be done. In the next part of this post series, I will look into what changes have been done recently, the restructuring and extension efforts to BPF and its evolution to eBPF along with BPF maps and the very recent and ongoing efforts in hist-triggers. I will discuss about my experiemntal userspace eBPF library and it’s use for LTTng’s UST event filtering and its comparison to LTTng’s bytecode interpreter. Brendan’s blog-post is highly recommended and so are the links to ‘More Reading’ in that post.

Thanks to Alexei Starovoitov, Eric Dumazet and all the other kernel contributors to BPF that I may have missed. They are doing awesome work and are the direct source for my learnings as well. It seems, looking at versatility of eBPF, it’s adoption in newer tools like shark, and with Brendan’s views and first experiemnts, this may indeed be the next big thing in tracing.

Embedded, Kernel, Linux

Jumping the Kernel-Userspace Boundary – Procfs and Ioctl

I recently had a need to have a very fast and scalable way to share moderate chunks of data between my experimental kernel module and the userspace application. Of course, there are many ways already available. Some of them are documented very nicely here. I will be writing in a few blog posts sharing what all mechanisms I have used to transfer data and provide such interfaces.


I have used the Procfs before (with the seq_file API) when I needed to read my experimental results back in userspace and perform aggregation and further analysis there only. It usually consisted of a stream of data which I sent to my /proc/foo file. From a userspace perspective, it is essentially a trivial read-only operation in my case,

/* init stuff */
static struct proc_dir_entry *proc_entry;
/* Create procfs entry in module init */
proc_entry = proc_create("foo", 0, NULL, &foo_fops);
/* The operations*/
static const struct file_operations foo_fops = {
    .owner = THIS_MODULE,
    .open = foo_open,
    .read = seq_read,
    .llseek = seq_lseek,
    .release = single_release,
/ *Use seq_printf to provide access to some value from module */
static int foo_print(struct seq_file *m, void *v) {
    seq_printf(m, val);
    return 0;

static int foo_open(struct inode *inode, struct  file *file) {
    return single_open(file, foo_print, NULL);
/* Remove procfs entry in module exit */
remove_proc_entry("foo", NULL);


I also used ioctl before (More importantly, I call them eye-awk-till. *grins*). They are used in situations when the interaction between your userspace applicatoin and the module resembles actual commands on which action from the kernel has to be performed. With each command, the userspace can send a message containing some data which the module can use to take actions. As an example, consider a device driver for a device which measures temperature from 2 sensors in a cold room. The driver can provide certain commands which are executed when the userspace makes ioctls. Each commad is associated with a number called as ioctl number which the device developer chooses. In a smiliar fashion to Procfs interface, file_operations struct can be defined with a new entry and initializations are done in the module,

/* File operations */
static const struct file_operations temp_fops = {  
       .owner = THIS_MODULE,  
       .unlocked_ioctl = temp_ioctl, 
/* The ioctl */
int temp_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) {
	switch(cmd) {
		copy_to_user((char *)arg, temp_buff, 8);
		copy_to_user((char *)arg, temp_buff, 8);

There are other complexities involved as well, such as using _IO(), _IOR() macros to define safe ioctl numbers. To know more about ioctl() call and how it is used, I suggest you read Chapter 7 from LKMPG. Note that newer kernels have some minor changes in code, hence refer to some device drivers using ioctls inlatest kernel releases. Each ioctl in our case means we have to use copy data from user to kernel or from kernel to user using copy_fom_user() or copy_to_user() functions. There is also no way to avoid the context switch. For small readings done ocassionally, this is an OK mechanism I would say. Consider that in a parallel universe, this sensor system aggregates temperature as well as a high quality thermal image in addition to each measurement. Also, there are thousands of such sensors spread across a lego factory and are being read each second from a common terminal. For such huge chunks of data accessed very frequently this each additional copy is a performance penalty. For such scenarios, I used the mmap() functionalty provided to share a part of memory between the kernel and userspace. I shall discuss more about Mmap in my next post.

Android, Embedded, Linux, UX/UI

Some Cool Retro Watchfaces

These holidays, I was refraining from spending huge sums on stocking gadgets I don’t need. But (un)fortunately, I ended up buying a Nexus 5, a Moga Hero controller and a cheap smartwatch. So what do you do when you get an Android device? Exactly! Start hacking on it – root, custom ROMs, custom kernel, cool apps! So, my experimentation started with the SmartQ Z Smartwatch I had bought. For the price (CAD $91, including shipping from China) this was an irresistible piece of tiny Android to start tinkering around with. It packs a 1GHz Ingenic processor (MIPS) – JZ4775, 512MB DDR RAM and 4GB flash. All of this with a tiny 1.54 inch screen with a 240×240 resolution. The latest firmware supplied by the vendor is based on Android 4.4 with a custom launcher. It is a very hacker-friendly device and came with ‘su’ out of the box 🙂 Though its a bit old (2013 launch) and the manufacturer seems to have abandoned the development on this, for the price, its a pretty impressive piece of tech on your hand.

I decided to make my own watchfaces with custom features and more inspiring UI than the watchfaces provided in the watch. Also, the hidden agenda was to check out the new Android Studio. As with everything Chinese, the SDK and docs for the Smartwatch were in Chinese! But fortunately, after surfing through XDA Developers forums, I found a link to the English docs on their website to refer to the weather APIs that I needed to use. With moderate efforts, I was able to make the following watch faces :

They are actually developed as widgets and the launcher apparently sees if the AppWidgetProvicer class you use starts with the string “WatchFace”. If this is the case, it simply puts that widget along with the custom watch faces in the menu.

If you own a similar watch/with similar screen dimensions, you can try installing the apps or use the source code for building your own cool watchfaces. I really wish I had an Android Wear watch rather than this so that I could develop on a more useful and up-to-date platform. Thanks for reading. Happy new year! Here is the source code and specs for these watch faces :

LCD Watch Face

Source : https://github.com/tuxology/LCDWatchFace

Download : lcdwatchface.apk

CRT Watch Face

Source : https://github.com/tuxology/CRTWatchFace

Download : crtwatchface.apk

If you find any bugs, report them on Github. Also, if you want me to port them on Android Wear, let me know. I’ll try to do that in emulator.

Embedded, Linux, Raspberry Pi

Raspberry Pi with HDMI – VGA converter

I have an early 2012 version of Raspberry Pi (generous gift from the Fedora Project) which sometimes tends to give some problem when a lot of current is being sourced from the USB. In addition to current issues with USB as well as HDMI, I faced a basic display problem when I used my HDMI-VGA converter for display which is not powered externally.

First things first, the converter won’t work directly and its almost sure that you will have to make changes to the config.txt (which holds the boot time specifications and is the key file to tell the Pi during boot time about any configurations that it should take care of) Here is what my config.txt looks like


The values will obviously be different for you according to your Pi and display configuration. Have a look at http://elinux.org/RPiconfig for a very detailed explaination. Some things of interest to us here are hdmi_force_hotplug=1 just pretends that a HDMI device is always attached. The hdmi_group specifies the HDMI type whether its a DMT type output (mostly used in computer monitors) or if its CEA (which is used for TV monitors). The value 2 is for DMT.  The next is hdmi_mode which is very monitor specific. For example 47 corresponds to a monitor supporting a resolution of 1440X900 at 60Hz. You can check the wiki and find the mode for your monitor.  The hdmi_drive just chooses between HDMI and DVI output modes. You can save this as config.txt in your boot partition and ho! the converter works.

But hold on! As expected, it  the other devices connected also draw some amount of current from the USB ports which because of the infamous polyfuses between the USB supply line and ports limit the current to around 140mA. This is annoying as I don’t even know the specifications of my converter (its a cheap one from Amazon which did not come with absolutely any documentation.) The only way is to open it and measure the current draw myself. Being too lazy for that, I found a lot of solutions on the web to get my power supply of pi straightened out and amazingly the simplest one worked for me (/me says ‘he he he!’ with an evil grin) Here’s what you can try (in order) –

  • Try a better power supply – Use the ones which have ratings for 1A and above The usually are faithful. Some phone chargers will work and mostly the USB supply from laptops is not sufficient. I use my Samsung phone’s charger which has a rating of 5V, 850mA It works until I use more devices like Wi-Fi/Bluetooth dongle etc.
  • Buy the externally powered USB hub – If the simple thing above doesn’t work (usually when you are connecting more than two heavy devices – like a non-powered HDMI-VGA converter and a HDD) you need to find an externally powered USB hub. This is the safest bet (recommended) and usually not exciting if you are of the hacker kind. There is a list of good ones on http://elinux.org/RPi_VerifiedPeripherals#Powered_USB_Hubs
  • But this is pretty overkill for daily mundane tasks like a Wi-Fi dongle + some other USB peripheral. So the more interesting way is to short the polyfuses. I have heard that they no longer exist on the Model B rev 2.0 which seems good, but the main power still has polyfuses (shorting them is a bad idea I think) So for older models, you can get most of peripherals working when you short the polyfuses.
  • If you are more adventurous kind, you can get your Pi powered from an external ATX power supply which you can scavenge from some old PC (as I did) I am pretty much planning to power everything including the pi and a small fan from a Pentium 2 processor (slot package) from my ATX supply and I hope it will work.

I managed to get mpd running on my Pi and have setup my ownCloud on it so that I can use it as a small storage cloud. The mpd combined with my Droid MPD client on an Android phone has essentially made it my remote music station. I am waiting for my relay board to come so that I can maybe tweet-a-lightbulb at home sometime 🙂 I shall keep posting updated about small hacks and things I learned with the Pi.

Here’s an old post which I found interesting on polyfuses on Pi and from where I learnt some stuff about it – http://theiopage.blogspot.ca/2012/06/increasing-raspberry-pis-usb-host.html

Embedded, Linux, Qt

Qt Apps on Android! Part Two : An App(le) a day

No guys, this post is not related to Apple Inc or Steve Jobs but to my previous post 🙂 We now are in a position to have our development setup ready for Qt app development on Android so lets begin with the actual stuff. I shall take an example of the digital clock app you had seen in the previous post (reproduced here for your sake).

For some Qt newbies, its also going to be a tutorial on using Qt Creator effectively. We shall cover UI design and then do some coloring and stuff like that to make it more beautiful. Then we shall code the app so that your clock works.


For your reference, I have put up this simple app on my git repo or maybe you can get the tarball from here

Step 1

Start the Necessitas Qt Creator and create a new Qt Gui Application from File > New File or Project > Qt Widget Project > Qt GUI Application

Step 2

Choose the project name and location and after that choose the Qt version as  Qt for Android which we created in the last post.

You can also select the Desktop version to for prototyping your app for the desktop x86 host. Once the project is created you can see the auto generated files under Project as shown below. The file tuxologycloxk.cpp is the one in which all the logic goes.

Step 3

Under Forms, click the .ui file and start making the UI. Its a pretty easy job actually, you have to drag and drop the required widgets and arrange them properly in something called as layouts. Just analyse a bit how I have created the UI for the clock.

You can drag and drop the Widgets from the left panel to the form view and the corresponding Objects will be created in the right top panel as shown above. The property for each project can be set directly from here only. For eg. the initial value (initValue) for the lcdNumber object has been set as 1200 above. You can actually set the widgets background as well as the whole application colour palette by changing properties of the respective objects.

Notes on StyleSheets

You can also apply styleSheets to make your app a bit beautiful too. For example the Exit text that you see in the application is actually a button with some styles applied. You can set styles using the UI editor quite easily. Just right click the corresponding widget and click on Change styleSheet. You will get window as shown below in which you can apply your desired style.

The above stylesheet changes a button from the boring button widget to a sleek black button which mixes well with the application’s look and feel.

Step 4

Look closely and you will understand that writing code is no big deal too. Just refer my digital clock source and browse through the code to understand it. Just a small reminder on creating signals and slots – You can click on the widget directly to create slots for the specific signals they will emit. For eg. right click Exit and select Go to slot.. A dialog box will ask you the signal which will be emitted and when you hit Ok a slot in the code will  be automatically generated. Now you can write whatever code you want to implement in that slot.

Step 5

Assuming that you have created the application, you can do some other settings too. Just click on Projects on the left panel and you will see different targets for you application. We had opted for Android as well as Desktop in the beginning so both shall be shown here. Click on Run and then Details under Package Configuration. You will see some configuration tabs as shown below. You can fine tune some stuff from here of course such as Android Permissions, app name, app icon etc.

You also have an option to either deploy local Qt libs for the device or use device’s libs. If you have installed Ministro from Android market to your device, just leave it to use the devices qt libs. However, if you are going to use the emulator, make sure you get the Ministro apk from here and install it on the emulator by selecting the third option below.

Once all is set its time to connect your device, set platform as Android and hit Run (Ctrl+R) You can see the compile output on the compile output window and the debug messages in Application Output window (hit Alt+3 or Alt+4 to switch) Watch out for any build issues too. I hope the same stuff works fine with an AVD too as I haven’t tried that out actually. I do all my testing on my rooted Sony Xperia mini x10 Pro and the first image in this post is what you should get if you try to build the TuxologyClock project for your device.

Thats all Folks! Happy hacking!

Embedded, Linux

Qt Apps on Android! Part One : <3 is in the Air :)

Have you loved two tangentially apart technologies at the same time? Its like holding one girl’s hand while you woo another one 😉 Yeah something like that is the case with me. To my girl – “Its OK sweety, I’m just talking about Qt and Android :)”

There must have been a time when you would have thought, “Oh God, I wish I could just port all these apps I run on my desktop to my new android phone.” Or maybe you are one of hose who say, “I wish I could use my Android cell to prototype my new Qt based embedded device that I am making. It’d be something cool to show to those black shoes, red tie morons in the conference room.”

The Necessitas project comes to your aid guys. I shall be writing a short tutorial series on creating small Qt app like these :

in the speediest of ways and port it to your device. This part will consist of setting up the tools necessary for Qt application development on Android


Also known as Android Lighthouse project, this is the individually developed port of Qt for Android. Necessitas comes with a modified Qt Creator IDE for building, deploying and even debugging your applications directly for your Android device. You will be amazed to see the ease with which you can develop and debug your apps. Say thanks to BogDan Vatra and those unsung heroes who have brought this to you. Now lets begin.

Get Necessitas SDK

Get the Necessitas 0.3 online installer from here. I however downloaded the 0.1.1 version available as an offline install which serves the purpose well. Its available in old versions directory. The installation is pretty straight forward. Just run the installer and make sure that you install the SDK in /opt/necessitas. You may have to make your /opt 777 for sometime and then revert back to 755 once the installation is over.  The SDK mainly consists of the cross compiler for android on ARM and lots of cross compiled ARM libs for Qt. I have mentioned in previous posts how to do all that manually but here, its all ready for you 🙂 Once the installation is over, you will get a Necesitas Qt Creator in your applications. This is almost same as your traditional Qt Creator IDE. We shall move on to configure it now.

Configure Qt Creator

Requirements :

  • Install ant if required by yum install ant
  • Check whether you have JDK with java -version
  • Get Android SDK from here
  • Get Android NDK from here

Step 1

Extract the SDK and NDK at some locations and start Necessitas Qt Creator/Qt Creator for Android and go to Tools>Options. Click Qt4 tab and Add a new qmake path. Give this new qmake path from /opt/necessitas/Android/<qtversion>/bin/qmake This qmake will make the projects and makefiles cross-compile ready. Give some name to it – maybe Qt for Android

Step 2

Now that you have the new Qt setup, Click the Android tab on the left and specify the SDK and NDK target and set proper toolchain as shown below. Also set the ant location and hit Apply

If you are not having any Android device, then create a AVD to test your app. Lastly, some configuration is also required on your device.

Step 3

Now, we have almost everything ready for development on our device, however to run a Qt app we need libraries on the target device. For this, there are two options. Either while developing application, an option to use local Qt libs can be selected or a nifty tool called Ministro can be used. Ministro is an android application that can be downloaded from the Android market. This application performs a one time download of Qt libs from the net on the device as required by the application you have created. In a simple application mostly it will do a mostly 8Mb install of QtCore and QtGui modules.

The next post will describe how to create a small digital clock app (as shown above) using the Qt Creator, something about putting Style Sheets in Qt apps and then get it on your device! Keep experimenting.

Source : http://sourceforge.net/p/necessitas/home/necessitas/

Embedded, Linux

InfoCanvas – A mini440 Based Web-Client

As part of my MTech project here at COEP, I had spent some considerable amount of time developing a ARM SBC based touchscreen web-client which can easily be customized to be used according to the desired application. (I have demonstrated its use as an information-desk and as a terminal which fetched sensor data from another ARM SBC based web-server) Throughout the development I have taken help from many Embedded Linux enthusiasts and used Open Source technologies all the way.  I posted some stuff about the software design on my blog and sometimes helped some guys through mail also but never ever did I think once even to tell the world how I did it until now when I realized that ethically its wrong not to share good stuff with good guys like you. Oh! its not that I have rewritten a better Kernel than Linux, but some bits here and there are always missing when you work on embedded devices. Thats all I have to give back from the project I have done. Its small and humble but still, its for all of you to play with now. Everyone releases software but no-one releases how to build a complete device kind of thing. I guess I did it at last. Now adapt it according to your needs and create new devices. Host a Diaspora pod on the ARM server or just think crazy.

I am going to release the documentation in the form of my M.Tech. Thesis (Its pretty rough but still covers most of the work) in public domain currently and then will put up the related code/scripts etc on git very soon. The thesis contains some images and and data from various sources from the internet, cited wherever possible. Make use of it as it suits you. Only the work done my me in the thesis is under public domain. At any places if you find some data which is copyrighted, don’t use it without proper permissions.

In case you require some incentive to get interested in playing with such a device, some excerpts from the first chapter :

In this report, which supports and explains the work supplied with it, details of development of an ARM9 SBC based network capable LCD touch-screen device is explained. The device is essentially a versatile HMI module which can be customized according to the various need under various conditions with minimum effort. Stress on the human interaction, networking standards and an aesthetic look has also been given during the development of such a device.

System Overview

As a demonstration, the project has been configured and developed as a full fledged product to be used as a student information desk and feedback system. This device thus is aptly named COEP InfoCanvas. In addition to this another small ARM SBC has been configured as a web-server which serves the latest sensor values attached to the it. This sensor is accessed by the COEP InfoCanvas which displays the remote sensor’s value in text as well as a time series graph on the LCD touch-screen. The COEP InfoCanvas is driven by SBC-I which along with another SBC-II and an Info-Server is connected to the LAN/WAN. Refer Figure 1. SBC-I being network capable acts as a web client an can fetch and display on its LCD, information and other data from any server on LAN/WAN in standard web formats such as HTML and Javascript from Info-Server machine and SBC-II. The Info-Server is a Linux server grade machine which runs a web-server and supplies data to SBC-I. The SBC-II present at a remote location, is designed itself as a tiny ARM web-server which gathers sensor data through its ADC and serves it to the SBC-I for display. The system is pretty modular and uses mainly standard TCP/IP protocols to communicate and send data to and fro.

Figure 1

The system has been designed almost completely using FOSS tools and technologies. Right from configuring the OS to developing applications on it, Open Source tools have dominated the development of this device.

Some Images

This slideshow requires JavaScript.