To make the project generic and portable, we are moving the BBIO-Server code out the the PyBBIO repository and have created a new project at zygote

The architecture is as shown in the diagram :

The base block seen in red represents the hardware platform (Raspberry PI, Beaglebone Black, Radaxa board, etc.) on which the application runs on. The platform should have a python based IO library which the zygote server can utilize. There is a generic IO library mapping that happens which maps the board specific python functions to a generic interface which the zygote-server (Flask based RESTful server) uses. This layer also takes a python dictionary which contains the board configurations. The Flask server will use the generic interface to expose a REST api to the external world.

This REST api can be accessed through a mobile or web client, as shown in the diagram.

Currently we have developed the basic RESTful API for the BBIO-Server. The functionality currently supported includes : GPIO, PWM, analog in, Servo and custom modules.

Sample interfaces

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

GPIO handler : 
  GET /gpio/1/16?task=write&state=HIGH    :: sets pin GPIO1_16 high
  GET /gpio/1/16?task=config&mode=INPUT   :: sets pin to input mode
  GET     /gpio/1/16?task=read                :: reads pin, returns status

PWM handler :
  pwm to work with default configuration.
  i.e. freq = 10KHz and resolution = 8 bit

  pin to pwm mapping :-
  P8.13 - PWM2B
  P8.19 - PWM2A
  P9.14 - PWM1A
  P9.16 - PWM1B

  GET /pwm/1A?value=10
  
Analog In : 
  function to handle ADC read requests. 
  Input can be from 0 - 1.8V, o/p of 12 bit resolution

  P9.33 - AIN4
  P9.35 - AIN6
  P9.36 - AIN5
  P9.37 - AIN2
  P9.38 - AIN3
  P9.39 - AIN0

  GET /adc/AIN0 => returns the analog input at channel 0
  
Servo controller :
  each servo is attached to a PWM module

  GET /servo/PWM1A?config=enable  => enables this module
  GET /servo/PWM1A?angle=50   => moves servo to 50 deg
  GET /servo/PWM1A?config=disable => disables this module

Here is the code that has been currently written :

As we work on BBIO-Server, we will keep the community updated through this blog. The series of posts will discuss the various steps and design decisions taken by us while developing this library. In this post we will explain how we setup the environment to get started and start using the PyBBIO API.

Environment Setup

1. Fork Alexander Hiam’s upstream repository to our master. The master is where we will be adding our library, which is to be upstreamed once complete.
2. Install the dependencies for PyBBIO as given here in the official wiki.
3. Clone our master repository from github, create a BBIO-Server-dev branch.
4. Install the code from source, by running setup.py, viz present in the root directory of the project.
5. Install Flask : pip install Flask

This is how we setup the environment to get started.

Using PyBBIO

Deepak has written a nice tutorial on using the PyBBIO API here.

Official development branch

The official development tree is here. This is where we will be commiting our code.

As we had talked about in our last post, We’ll be working on BBIO-Server as our AOST (Architecture of Open Source Technologies) project. This will be an extension to Alexander Hiam’s work, PyBBIO!

Currently the BBIO-Server is implemented as a library in the PyBBIO project. It enables the users to build a web page via a python API. Lambda functions help enable the RPC mechanisim to link user action on the web page to hardware actions on the Beaglebone Black. Here is the overview of how to use the API.

NOTE : These links will change overtime, the current library may soon be depreciated. 

Our proposal is to replace the current implementation as it has a few shortcomings. One of the problem being that there is no clean way to access hardware end points from the client side. The page has to be built using the BBIO-Server API; there is no other generic way to access the IO pins on the board. We plan to tackle this problem by developing a RESTful API to access hardware as follows :

1

GET /bone/gpio/2?pin=3

gets the status of pin 3 of the 2nd GPIO module (the BBB has 4 GPIO modules). To set the pin status,

1

POST /bone/gpio/2 {pin : 3, status : "HIGH"}

to setup a sensor/actuator on a paritcular port, we will be using the PUT request

1

PUT /bone/pwm/1 {pin : 2, type : "SERVO"}

Also the current implementation is a custom built HTTP server using the python HTTP API. It makes more sense to use a existing lite server side framework such as Flask.

Another limitation of the current implementation is that you can’t directly access the hardware from the client side, i.e. you have to build the page using the python API only, which is not very nice for most developers. This calls for a neat javascript based API which will give developers a neat way to control the BBB via a web interface. Such as

1
2

digitalWrite(1, HIGH);
servo.setAngle(120);

Additionally we propose to create an API for data streaming via web-sockets/web-rtc. This will be useful for sensor data graphing and video camera display.

Finally developers would like to have ready to use UI components at their hands, and for this purpose we will be integrating BBIO-Server with Freeboard and also adding our custom UI components!

Note : A similar project is Web-IO-Pi which enables web page based hardware control on the Raspberry PI.

This semester, I have chosen AOST (Architecture of Open Source Technologies) as my group C elective. As a part of the course we are required to contribute to an open source project. I’m pleased to announce that me and my teammate Aishwarya, will be contributing to PyBBIO .

PyBBIO aims to provide a arduino like interface for controlling the IO modules on the BeagleBone Black. Currently there is support for GPIO, UART, SPI, I2C, Camera and host of other sensors. We plan to contribute the BBIO-Server library through the course of the semester. BBIO-Server will be an extremely versatile tool for developing IoT prototypes. It will have all the necessary components ranging from UI to a RESTful backend service that enables interacting with the BeagleBone’s IO (using PyBBIO) across an HTTP connection.

Specifics of the project include :

• Creating a RESTful API to access hardware interfaces via PyBBIO (can be thought of as making RPCs).

  For example to initialize a sensor PUT /bbio/spi/adt7310 "{'bus':'SPI1','cs':'GPIO1_16'}" or to get a value GET /bbio/spi/adt7310/temp "{'units':'C'}"

• A javascript frontend API (ajax based) for making calls to the server (wrapper for the RESTful HTTP service)
• Interface for full duplex data streaming using Socket.io
• Standard set of UI components (integrated with Freeboard) to get the developer started with zero effort.

I managed to get a basic ARM userspace to PRU interaction up and running and even wrote a python API to take care of the interactions. Here is how the API looks like!

1
2
3
4
5
6
7
8
9
10
11

import pru_speak

botspeak_code   = \
'''     SET DIO[0] , 1
        WAIT 1
        SET DIO[0], 0
        WAIT 1
        GOTO 0'''

pru_speak.load(botspeak_code)
pru_speak.execute()

It’s been over two weeks since I started on my GSoC project, and what a journey it’s been! Reading thousands of lines of kernel code, prototyping my own drivers and involved discussions with the community members :D

Here is the update :

• Tried out character drivers
• Developed my own sysfs driver with support for both binary and device files.
• Hacked on my mentors driver.
• Got upcalls and down calls working.
• Developed some C + Assembly based firmware for the PRU
• Shared memory implementation between the kernel and PRU.
• currently working on exporting the shared memory to userspace.

I received some really good news earlier this month! I had been selected for GSoC 2014!

The project I will be working on the PRU Speak project for Beagleboard this summer :D The summary of all the projects that have been selected for GSoC-2014 @ Beagleboard is put up at the official projects page

The key motivation behind my project is to make simple the control of the PRU from an userspace process in Linux running on ARM. This is done by developing a custom firmware for the PRU and an API frontend for the user space application to use. A kernel driver forms the bridge between the user spcae library and the PRU firmware, (i.e.) API <—> Driver <—> firmware on PRU.

Here is a small video I wipped up for the organisation that summarizes my project!

This is my first post on this blog :D As we programers always do, I will start with a Hello World program!

1
2
3
4
5
6
7

#include<stdio.h>

int main (int argc, char ** argv)
{
  printf("Hello World!\n");
  return 0;
}

In some python now

1

print "Hello World"

yes, I just could not leave out python!