Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software.  For years, arduino has come up with many versions. Although every new version of arduino has improved the capability on the  micro controller, SRAM, flash memory, there still exists a large gap between the requirement of some real world application and  its restricted capability.

  • Arduino UNO/ nanode

Arduino ‘s latest version is arduino UNO. Also a popular arduino – compatible, Ethernet-supported board  ( nanode ) has the same specification as arduino UNO.

Microcontroller
ATmega328

Flash Memory
32 KB (ATmega328) of which 0.5 KB used by bootloader

SRAM
2 KB (ATmega328)

EEPROM
1 KB (ATmega328)

  • 1.1.2 Arduino mega2560 / ADK

Although arduino UNO is very commonly used but due to its poor capability, it can’t meet the requirement in situations when applications requires more memory storage. So that is how
arduino mega 2560 comes into play.
Arduino mega 2560 is also a standard arduino board, but more powerful than arduino UNO. More recently, google has announced a project, that brings the capability of arduino and android together.
The ADK board is able to communicate with android phone through a extra USB port. This board is essentially built upon arduino mega 2560.

Microcontroller
ATmega2560

Flash Memory
256 KB of which 8 KB used by bootloader

SRAM
8 KB

EEPROM
4 KB

 

 

Arduino and webinos

There are normally three types of PZP, from smart device, dumb device to smart dumb device, we need to see what the category the typical arduino device could fit itself into.

1. Smart device

The significant difference of smart device compared with other mini versions,  is it embeds the WRT. And the primary responsibility of WRT is to host webinos applications exposing webinos services and to render the HTML5, CSS, so it is only fit for those 32 bit device with large memory, such as PC, smart phone, mobile device on the vehicle.
The javascript based WRT application could use the API manipulating the  resources on the devcie such as sensors and communicate with PZH in authentication and security session provided by the PZP.

2. Dumb Device No WRT

Dumb Device with No WRT is a mini version which doesn’t need to host the webinos application which is based on javascript. The main job of dumb device is to communicate with PZH through PZP.  That requires the dumb device to set up communicate with JSON and build a TLS secure communication channel.
When we goes back to the typical arduino platform with 2 kb memory, it still restricts us from porting PZP with no WRT to our arduino platform with two primary reason.

Apparently, the first restriction is due to the TLS which is costing overly too much memory for such arduino compatible device. Moreover the second restriction is due to the overhead of HTTP (based on text rather binery) and JSON message between PZP and PZH. In general, building a web server with arduino requires us at least 500 bytes memory for parsing the HTTP packets if the overhead of message is very simplified.   In the case of JSON message standard of webinos, the overhead on the message is really large. For example, sensor API is very commonly used in the dumb device. it we want to know what type the sensor is, we can identify it through a list of URIS that used to declare the feature of this device, http://webinos.org/api/sensors.light which identifies the light sensor costs 37 bytes. In real developer’s viewpoint, this is a real headache that a message from server (PZH) is not complete due to lacking of memory allocation on the Ethernet.   
In sum, for the arduino UNO and nanode board, even we don’t consider about the security part, the JSON message between the PZP and PZH is also a issue, let alone the arduino also has to cope with application logic such as management of devices or data.  Normally, existing arduino environment is not suitable to port with this version PZP.
However for the arduino mega 2560, 8 kb SRAM memory seems more feasible to be ported with this version of webinos PZP.

Suggested improvements:

The advance of new arudino platform (32bit) and binery HTTP lights new hopes that allows mini version of PZP to port on the arduino platform.

1. New 32bit arduino platform
Arduino Due  a major breakthrough for Arduino because this is  an Arduino board with a 32bit Cortex-M3 ARM processor on it. We’re using the SAM3U processor from ATMEL running at 96MHz with 256Kb of Flash, 50Kb of Sram, 5 SPI buses, 2 I2C interfaces, 5 UARTS, 16 Analog Inputs at 12Bit resolution and much more.
read more here:  http://arduino.cc/blog/2011/09/17/arduino-launches-new-products-in-maker-faire/
Obviously, the improvement on the memory solves many problems. This type of advanced arduino device can be served as gateway, at one hand porting with PZP allows it to talk with PZH in secure session and at the same time it can communicate with other less advanced arduino device through sensor networks. That will help to reduce the overall cost.

2. XXTEA might be replaced with TLS
although XXTEA is not that secure for all the situation, at least at the current situation, it is potential a solution to maintain certain high level security while keeping the memory not running out.
3. COAP
If there is no improvements on the memory limits of arduino device. We have to consider ways that minimize the overhead of HTTP protocol and also the webinos JSON message format – a minimized version of JSON format especially for dumb device. (BSON is a binary version of JSON)
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications. It is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialized requirements such as multicast support, very low overhead, and simplicity. Currently, CoAP is an IETF draft (https://datatracker.ietf.org/doc/draft-ietf-core-coap/).

3. Super Dumb Device NO WRT, NO PZP

 

Connecting to a super-dumb device, it hosts neither a PZP nor a WRT, but can expose webinos services – if the client PZP hosts a customised driver.
This type of PZP is what we call as virtual PZP. Since it has no capability of WRT or PZP, it has to communicate with a real PZP, and expose its capability through a set of API understood by real PZP, such as the custom data exchange protocol defined for the energy demo.
Usually, the virtual PZP and real PZP are communicating inside the local area network.  using the xxxtea as the security between real PZP and vitural PZP might be good enough at the current time.

Advertisements