Voting dAPP- Ethereum - India Opinion Poll

dAPP (decentralized app) is a type of app where there is no centralized server. All the data is stored in decentralized fashion. The data is available public, it cannot be tampered. Once the data is pushed into Blockchain it cannot be removed. One of the most useful application is voting.
All the votes are registered in blockchain and it maintains a history of votes and hence the voting process can be trusted.

Ethereum blockchain can be used to store both code and data. Hence the protocol or logic to implement voting process can also be pushed into blockchain. The code part is called as contract.
Hence by using Ethereum blockchain, both the votes and the code can be made available in public database.

Participate in simple opinion poll - India and reap the benefit of decentralization !

https://voting-dapp.herokuapp.com/ 

Ethereum donation 0xA98C1903CfEfE2cf5E7eD78CF16e17DcF8a566CB

Arduino Yun interfacing with TMP36 sensor using Temboo and ThingSpeak IoT platforms

Arduino Yun is wifi enabled board from Arduino. The binary can be flashed over wifi. The sensor data collected can be pushed to cloud through wifi connection.
The data is pushed into IoT cloud platforms like Temboo, ThingSpeak, Ubidots etc. Most of the platforms are free for basic usage.
Once the data is in the cloud platform, it can be passed on to the upper layer of stack such as Android App or an excel sheet where the data can be processed.
The IoT platform provider provides libraries and API's to send and receive data from their cloud platform.

Block diagram of the data flow 




Arduino YUN
https://www.arduino.cc/en/Main/ArduinoBoardYun
I have Arduino YUN purchased from Arduino org and not Arduino cc. There was a split in the original Arduino company and hence the clarification.
Though there are no major differences but keep in mind that the board detects as Linino* instead of Arduino* when detected over wifi.
Once you connect, the password to be entered in doghunter.
http://forum.arduino.cc/index.php?topic=364731.0

Sensor
TMP36
The sensor used here is TMP36 which is analog based. Change in temperature results in change in voltage which needs to be measured through Arduino board analog pin and then convert the analog data to digital (ADC) in the code. The sensor is not that accurate due to its analog nature but its cheap and readily available.

IoT cloud platforms
https://temboo.com/
https://thingspeak.com/
There are various cloud platforms which can be used to store the data from the IoT boards and then can be processed or passed to upper layer of stack such as webserver, Android App etc.
Include the corresponding platform header file in the Arduino code and link the library, use the platform API's to read/write data to the platforms.

Connection of Arduino YUN with the sensor

Arduino Code for pushing data into Temboo
https://github.com/jaglinux/arduino-yun-sensor-spreadsheet

https://github.com/jaglinux/arduino-yun-sensor-dropbox

Arduino Code for pushing data into ThingSpeak
https://github.com/jaglinux/Arduino-YUN-TMP36_sensor-ThingSpeak

ThingSpeak public channel
https://thingspeak.com/channels/164264

Union Usage - Interpreting different value through the members

Union, like Structure can hold various members and each member can be of any data type.

But the basic difference is that at any given point, only one member of  Union can be accessed.

It means that the value/data of a member will be retained until data is stored in another member.

If the idea is to retain the value of individual member then obviously Structure needs to be used.

Union should be used keeping in mind that the same memory location will be used by all the members of Union.

Size of Union is same as the size of the largest member.

All the members in Union use the same memory location to store the respective values and this fundamental principle can be exploited in cases where the value stored in one member can be interpreted in another way though a different member.

Lets consider a hypothetical 32 bit register X. There are 4 fields of a byte each.

31 - 24	23 - 16	15 - 8	7 - 0
Control_1 bits	Status_1 bits	Control_0 bits	Status_0 bits

A Structure  representing the above diagram can be written as follows

struct regX {

        __u8 control_1;

        __u8 status_1;

        __u8 control_0;

        __u8 status_0;

}

Now we will write a Union which encapsulate the above structure along with the value of the register.

union regX_encaps {

        __u32 value;

        struct regX reg;

};

It should be noted that the "value" member is 32 bit and the "status / control" members are 8 bit each.

Since regX_encaps is a Union, the data present in the member .value can be accessed as struct regX.

        union regX_encaps registerX;

        registerX.value = 0xaabbccdd;

        printf("value of register is %x \n",registerX.value);

        printf("value of control_1 is %x\n",registerX.reg.control_1);

        printf("value of status_1 is %x\n",registerX.reg.status_1);

        printf("value of control_0 is %x\n",registerX.reg.control_0);

        printf("value of status_0 is %x\n",registerX.reg.status_0);

        return 0;

In the above example, data 0xaabbccdd is fed into reg of regX_encaps which can be accessed as individual byte.

Output of the above code

value of register is aabbccdd 

value of control_1 is bb

value of status_1 is aa

value of control_0 is dd

value of status_0 is cc

In a real time scenario, readl() will be used to feed the data into reg of regX_encaps. Perform the desired action on the individual byte (control_0, status_0 etc) and then write into that, effectively reg of regX has the entire data now and which can be written using writel()

SpinLock in Device Drivers

Locking is required in driver code to protect a shared variable or  a piece of code from concurrent access. This protective region is referred as critical section.
Concurrent access to a variable will lead to variable corruption if locking is not used.
Locking restricts the access to the shared variable, converts the concurrent access to a sequential one.
When writing a driver, its important to keep in mind that the driver code can be accessed by many independent processes especially if the driver interacts with the user space through sysfs, device file operations etc.

Spinlock is a type of lock mechanism, used to protect a critical section which can be accessed by interrupt service routine and other part of driver code such as read,write functions.
To access a critical section, hold a lock and then enter the section and release the lock while leaving. If another process tries to enter the section when the lock is held, the process just spins around the lock to check if the lock is released. Its a busy wait loop which checks if the lock is released or not. Hence the name spinlock. Obviously the process which is spinning is 'wasting CPU cycles'.
The reason why spinlock is often used in interrupts because the other locking mechanism such as mutex, semaphore puts the process to sleep if the process wants to acquire the lock which is held by another process. As we know interrupts are not designed to sleep. Hence spinlocks are used when we need to protect a shared variable between interrupts and other part of driver code.

A sample skeleton driver pseudo code to illustrate the importance of locking.

write () {
..
outb(COMMAND_0, COMMAND_REG);
inb(STATUS_REG);
..
}

ioctl () {
..
outb(COMMAND_1, COMMAND_REG);
inb(STATUS_REG);
..
}

The write function sends command to the device and reads the status of the command as executed by the device. Even the ioctl command sends command and reads the status of the command. But the command sent by the ioctl function is different from the write function. (COMMAND_1 and COMMAND_0)
Assume there are 2 user space clients for this driver. One of the user process P0 has issued the write system call and another user process P1 has issued the ioctl system call.
Lets consider P1 is running and the code inside ioctl() is executing and has issued the command 1. By the time it reads the status register of the result, the scheduler kicks in and hands over the control to process P0.  The write function issues command 0 and reads the status of that command. The scheduler hands back the control to process P1. It continues the execution from where it has left before i.e reading status register. But instead of reading status of command 1, it reads the status of command 0  !
This simple example illustrates the necessary of locking to maintain the right state machine.
Results are not predictable even if the processes are running on different CPU i.e P0 is running on CPU0 and P1 is running on CPU1.

Re-writing the code with the usage of spinlock.

write () {
..
spin_lock(&driver_lock);
outb(COMMAND_0, COMMAND_REG);
inb(STATUS_REG);
spin_unlock(&driver_lock);
..
}

ioctl () {
..
spin_lock(&driver_lock);
outb(COMMAND_1, COMMAND_REG);
inb(STATUS_REG);
spin_unlock(&driver_lock);
..
}


If a process acquires the spinlock then the other process or processes doesn't get the lock and only the process which has acquired the lock will be executing the critical section . Hence ioctl and write will always read the status of their respective commands.
We can use mutex instead of spinlock in the above example. But it might be overkill.

However in the above example. if the interrupt also uses the lock then we might need to use other version of spinlocks like spin_lock_bh(), spin_lock_irqsave() which I will discuss in the next section.
Till then Happy SpinLocking !!!

IPC : AP-CP communication

IPC here refers Inter Processor Communication and not Inter Process Communication.
AP refers to Application Processor.
CP refers to Communication Processor. Its also called as Modem, BP (BaseBand Processor).
AP is considered as main processor. It is responsible for most of the mobile processing except the heart of it !
AP deals with everything except Cellular Network related work. This is done by the Modem.
Display unit, Camera, Touch key, Keypad etc are controlled by AP. These peripherals are present in AP.
Modem has hardware's that is responsible for connecting to mobile network. Modem maybe 2G,3G,4G capability. 
Modem handles call, sms, browser processing.
Actual UI features of call/sms are handled in AP.
Now this must be enough to guess the importance of IPC between AP and CP.


IPC consists of physical connection (set of wires) between AP and CP, corresponding controller on AP and CP, drivers to talk with controller.
Other than IPC medium, set of GPIO lines are also connected between AP and CP for modem control operations like modem on,off etc.

Both AP and CP are separate chip packages. Both can be single core or multi core processors.
This means that both are independent computing unit. There should be a connection between these 2 units so
that the data is transferred between them. This connection is referred as IPC (Inter Processor Communication).
Please be noted that all handsets are not designed in this way. There maybe a single chip package which hosts all the hardware. It does the job of both AP and modem.
Its a design issue in selecting the architecture for the same, whether to go for a single chip solution or dual / multi chip solution.
AP --> Texas Instruments OMAP series, Qualcom MSM series, Samsung chip-set, Nvdia Tegra etc.
CP --> Qualcom MDM series, Infineon, Samsung, Broadcom, Marvel chip-set etc.
For an Android handset, Android (Linux OS) runs on AP whereas CP runs on its own proprietary OS platform.

Different kind of IPC's

• MIPI HSI
• HSIC (USB HS)
• DpRam (Shared Memory)
• SPI
• c2c (Chip to Chip)

Functionality of IPC

IPC are used to transfer Voice data, SMS data, Net (browser) data between CP and AP.
Usually CP wont have Flash memory. The modem binary itself is stored in AP side Flash.
Hence AP uses IPC to transfer modem binary to CP.
When CP is powered on, Boot ROM code of CP runs and it waits for modem binary.
After Linux kernel boots up in AP, the kernel IPC driver sends modem binary to CP.
This is referred as Flashless Boot. (CP is flashless)

Since CP is flashless, it should use AP side flash to store NV data (data across boot).
This remote File system feature is also provided with IPC as medium.

Whenever AP asks for CP logs or in case of CP crash CP ram dump can be transferred to AP
through IPC.

IPC drivers (AP side,Linux Kernel)

If we consider MIPI HSI as IPC medium, HSI controller driver is responsible for HSI controller configuration, register settings, data transmission / reception with CP. The actual data transfer happens through IPC physical wires connected between AP and CP 
Usually HSI read / write functions are exported and exposed to another set of drivers called IPC utility driver which actually calls these exported functions.
These utility drivers are character drivers which interacts with user space, in case of android its RIL.
Based on RIL directives, utility driver writes and reads data from CP with the help of exported functions as mentioned above. 
Set of GPIO lines are also connected between AP and CP. These GPIO lines can be used for Modem on/off, interrupt from CP to AP, AP status to CP etc.
We can handle all these GPIO lines under a driver.
Other than this, for net data, kernel TCP/IP stack and net drivers are utilized.

KDB porting on Android device

KDB stands for Kernel DeBugger.
Its used for on target debugging. You don't need another device to debug the kernel on target.
From linux 2.6.35 onwards, mainline kernel includes KDB front end (Backend is GDB). So gone are the days when we used to port kernel patches.
In fact, there used to be 2 patches , one for kernel and another for architecture specific patch.
With 2.6.35 and above, we only need to enable the following configs.
1.CONFIG_KGDB=y
2.CONFIG_KGDB_KDB=y
3.CONFIG_KGDB_SERIAL_CONSOLE=y

 However we need to port a UART patch for console polling on UART. Check out for your UART driver patch for KDB. It should be mostly available 'Open'ly.
With the following changes, build kernel and its ready for debugging.

After booting with modified kernel,we have 2 options to start KDB service.
1.Before boot
Add kgdboc=tty,115200 param in the kernel cmdline.
2.After boot
echo kbd > /sys/module/kgdboc/parameters/kgdboc

To enter KDB mode for debugging,
In tera term (or any other serial port application over PC)
echo g > /proc/sysrq-trigger
KDB command prompt is entered.
Now , we can use various KDB commands for debugging kernel such as backtrace, breakpoint, list registers etc.
Happy Debugging !

FACETool milestone

My mobile application FACETool has crossed a milestone set by me.
25000 downloads overall.
The most number of downloads were from India (5000) followed by France and Turkey.
Though I have got a modest rating, I never expected 25k downloads !
Hope to port it to Android.