• No results found

Hardware Library

5.2 Context Acquisition Libraries

5.2.2 Hardware Library

The requirements on the design of devices that provide context are manifold. In many cases only an individual design, that is targeted to the artefact which should become context-aware, offers a usable solution.

Sensing Device Sensing Device Sensing Device Sensing Device Network ((( ((( ((( ((( ( ((( ((( ((( ((( ((( (( Context Consumer Sensing Device Sensing Device Sensing Device Sensing Device ((( ((( ((( ((( ( ((( ((( ((( ((( ((( (( Base Station Context Consumer Sensing Device Context Consumer Context ConsumerContext Consumer Base Station

Hardware libraries are a possible solution. In conventional electronic CAD systems libraries with a wide range of components are included. These components can then be added to schematics and PCB designs. Mostly these components are single devices, such as resistors, capacitors, connectors, and processors. In most cases a schematic (and also the PCB) consists of a number of components connected together. The connections are made according to the datasheets of theses components and using general knowledge about hardware design. This is a time consuming process.

The approach with the hardware library is to provide larger building blocks to speed up the design process. The library developed is implemented as EAGLE schematic and PCB layout [CadSoft,02]. The building blocks provided are designed and documented in a way that the developer can ‘copy&paste’ them into his designs.

5.2.2.1 Processing Cores and Memory Units

For all units in the system, either sensing units or communication units, a processing core is required. The processing core includes a microcontroller with a number of I/O pins. The building block is designed in a way that all I/O lines can be used when power is connected without further components. In some cases the core is a single component (e.g. using a PIC16F628) but typically this includes the MCU together with an oscillation circuit and a reset mechanism. Also one unit with high resolution A/D conversion is included in the library.

For an overview of the processing core library see Appendix D.1: Hardware Building Blocks HWcore.

The storage in the microcontrollers used is very limited, therefore additional memory may be required. Therefore a 64Kbit FRAM chip is included in the library, too. The memory unit (containing the FRAM chip and pull-up resistors) is connected via I2C and offers a non-volatile storage at minimum energy consumption.

5.2.2.2 Sensor Blocks

In chapter 3 different types of sensors and their use for context acquisition is discussed. This library contains building blocks for various sensors. As many sensors can not directly be attached to a microcontroller the building blocks also include the signal conditioning circuits.

Each building block in the library is created so that it can be connected directly to power (typically 3 or 5V) and the output of the sensor can directly be connected to the MCU. Dependent on the sensors this may be one or more analog pins, one or more digital input pin, or a more complex communication interface such as SPI or I2C. The library deploys a naming schema, where AOUT* is a analog output of the sensor which should be connected to an analog input of the processing unit, DOUT* is a digital output of the sensor and should be connected to an digital I/O pin, DIN* is a digital input pin to manipulate the sensor and should also be connected to a digital I/O pin. Names ending with *OP indicate that these pins are optional – so they can be connected but it also will work if they are left open.

On overview of the library is given in Appendix D.2: Sensor Building Blocks HWsensor.

5.2.2.3 Communication

In all cases where context acquisition systems are created communication is required. By choosing a particular architectural framework the basic communication architecture is specified.

In the simplest case this is a wired connection between the processing core and a device that accommodates the context consumer. For these links the library offers designs for serial line communication (RS232) and I2C connectivity.

The library also includes different types of wireless units. As AM and FM transmitter and receiver have different parameters, especially regarding communication speed and energy consumption various building blocks are provided. Additionally to transmitters and receivers also transceivers are included. Building blocks also contain an antenna (e.g a PCB track) which size is depending on the frequency of the module. A further option is a wireless link based on infrared transmitters and receivers.

All communication building blocks in this library are designed so that they can be directly interfaced to a MCU and accept serial data that is appropriately coded and not exceeding the speed specified, see also the software library description later.

The library is presented in Appendix D.3: Communication Building Blocks HWcomm.

There are further collections of hardware building blocks, such as the power supply library, which are useful to rapidly build systems.

5.2.3 Software library

The software libraries are designed to ease the development of sensing and context acquisition systems. In particular the functions support programming of systems which are running hardware that is constructed using the building blocks from the above hardware libraries.

The library includes program templates that relate to the building blocks, functions that provide hardware drivers for sensing and communication, and functions implementing basic perception. These software parts are all implemented in C, written for the CCS-PCM compiler [CCS,02]. Additionally, the library also contains backend functions to access the context acquisition system; those are available in various languages and for different PC platforms (e.g. C, Visual BASIC, and Java).

5.2.3.1 Program Templates

For each of the cores specified in the HWcore-library a program template is provided. The template is divided in two parts. A general c-file that will be used as starting point by the developer and will be extended with further functionality is one part. And a C- file that implements a driver for a particular core is the second4.

Similarly for the additional memory also a C-driver file to include is provided. It offers basic read and write access to particular memory addresses. It can be extended with functionality to store typed values in the memory.

An overview of core-drivers and memory drivers is listed in Appendix D.4: Core Libraries SWcore.

4 The CCS compiler used does not support precompiled modules as usually known from standard C development. Before each compiler-run the main file is extended with all includes to one single file which is then compiled. This makes it necessary to include the c-code of functions.

5.2.3.2 Sensor Drivers

For each sensor building block a driver, realised as a C-file, is provided. The driver file provides access functions to the sensor values. This is implemented in different ways depending on the sensor and how the sensor is connected to the core. Before including a sensor driver in the code it must be defined to what pins the pins of the sensor is connected. This is realised using a set of ‘define’-commands. The ‘define’- commands required are specified in the header of the driver file and if appropriate default values are set. See Appendix D.5: Sensor Drivers SWsensor.

5.2.3.3 Communication Drivers

Different communication drivers and functions are provided for the building blocks specified. This makes the implementation of communication, in particular wireless communication, easier. Similarly to the sensor drivers the connections between the communication units and the core have to be described using ‘define’-commands. Also the speed for a connection has to be specified using a ‘define’-statement.

As the complier offers already functionality for wired serial communication and wired I2C communication, the library is mainly concerned with wireless communication. The library offers a ‘printf’-function, which is similar to the RS232-‘printf’-function provided by the compiler, for sending data. On the receiver side two types of functions are implemented, one actively polling and another one using carrier detect (CD) to trigger an interrupt. In particular these functions realise error detection using a CRC-based mechanism.

As wireless communication is a main energy consumer in many designs also functions to power down these components are implemented if supported by the hardware.

An overview of functions offered in the communication library is given in Appendix D.6: Communication Drivers SWcomm.

5.2.3.4 Perception Library

In the perception library (SWperception) algorithms for cue and feature calculation are collected. The implementation reflects some of the perceptions methods discussed

earlier. In particular functions that are light weight, such as basic statistics and time domain analysis are included.

The functions which operate on a vector of data are implemented in two versions; one where the data is held in a global array and the other were data is passed through parameters. Using a global array seems like poor software engineering practice, however, given the minimal storage and the speed of the MCUs it can save memory and copy operation. Given the constraints of the MCU the functions working on a global buffer are included in the library.

5.2.3.5 Backend Software Libraries

Recalling the three basic architectures presented above it can be seen that the context consumer has to communicate in one of the following ways:

• accesses directly the sensing device, • accesses directly the base station, or

• accessing the context acquisition system indirectly via the network

In the first two cases a standard way to do it is to use the serial line (or USB which emulates a serial line). In the third option the access is done using UDP or HTTP over an IP network (which can be encapsulated in a high level library such as a distribution platform).

The backend library caters for those cases. The implementation for Visual BASIC uses the Microsoft Comm-control. The C implementation for a Win32 and Linux uses native API calls to provide the functionality. The java version uses the javax.comm package that is available for different platforms.