Projects:2015s1-12 An Open-Source Local Area Network (LAN)

Team

Members:
Robert Long
Oscar Evans
Luke Hub-Mayner Warner
Leigh-Anthony Noye

Supervisors:
Andrew Allison
Braden Phillips

Project Information

We will develop an Open-Source Local Area Network (LAN), based on the Arduino platform, and using the C programming language. The purpose of this network is to serve as a simple low-cost platform for teaching principles of real-time and embedded systems. There are three stages of development:
1. Get the Arduino up and working with an LCD display and a number pad, and program it as a glass type-writer, with modes for the alphabetic characters, after the fashion of many mobile telephones. Students will need to use multiple processes (threads) to control the display and the keypad, and to buffer characters.
2. Get Two, or more, Arduino microcontrollers exchanging text on an I2C bus. At this stage there is no collision detection or addressing.
3. Provide an application layer which allocates addresses to clients. If I send a text as: "#57 Mr. Watson - Come here" I want to see your number then the message: "Mr. Watson - Come here" appears only on the display of client #57, and no other client. (There is still no encryption or security, just the convenience of an address.)

Background

As mentioned throughout this wiki article, the overall aim of this project is to develop a platform that can be used to teach basic real-time concepts in a limited embedded system. < br />

For this reason, the C programming language has been chosen as the main language in this project. C provides a low enough level of abstraction for students to be able to appreciate the underlying effects of real-time paradigms, without becoming wrapped up in something like assembly code.

Aim

This project aims to produce an open source local area network (LAN). It is to be based on the Arduino platform and use the C programming language. This must operate over an I2C bus on the Arduino units with each unit to have its own bus connecting to a centralised server. Each client unit must also have its own display and keypad for input/output interaction with users. The purpose of this is to create a simple, low-cost platform for teaching principles of real-time and embedded systems. This system is to include an application layer which allocates addresses to clients however there will not be any security or encryption included.

Motivation

The University of Adelaide course, Real Time and Embedded Systems, utilises the C pro- gramming language to teach real-time and concurrency methodologies. To ensure this is effective as possible it is best to use teaching tools which are grounded in familiar tools. This is why the example of a LAN implemented in Arduino units using C is a compelling choice. Likewise I2C is a well-developed and extensively used bus protocol. Exposing students to these tools and protocols which are actively being used in industry is an invaluable experience. In previous years, the course has utilised desktop computers to teach the C in practicals and the PIC microprocessors as a teaching tool for the embedded systems theory. The outcome of this project will enable the two sets of theory taught by the course to be concatenated thus removing current disjointed approach of practicals.

Significance

With several closed source networking options available, providing a simple open source alternative is an advantage. Physical implementation is left to the user, and such this system might find itself in large scale remote sensing and monitoring situations.
Some examples might include:
1. Vineyard water table level monitoring.
2. Mine environment variable sensing.

Technical Details

Screen

The chosen screen was the LCD12864 and is shown in appendix C. This screen was chosen for its flexibility and low cost as discussed above in the budget. It communicates to the Arduino through SPI however this is mostly abstracted away and is not of concern to this project. The Screen is a 128 x 64 pixel LCD shield. The header bar allows for identification information and incoming message alert. Under this there is room for the received or in progress outgoing message. The size of this is three rows of sixteen characters allowing for a maximum message size of forty five characters long. This is well within the memory requirements of the Arduino Uno and should allow for several messages to be queued.

A library of code was found for the screen. A significant proportion of this is written in C meaning little work is required to utilise this as part of the project. The useful inclusions from this library in the context of the project are the font library, the ability to draw lines and the cursor function. The font library allows us to select from a wide variety of sizes and characters. This will be further discussed below. The line drawing functions allow the screen to be sectioned of into user-editable and non-user-editable sections. This also increases readability and usability. The cursor function allows for easier message editing but does however bring further design choices.

Keypad

As discussed in previous sections the keypad being used as the primary input device for this project is the FIT0129 membrane keypad. Text input will be entered in the style of old mobile phone keypad. The keypad is to be connected to the Arduino Uno through the digital pass through connectors on the screen shield. To investigate the waveform of the button presses, one horizontal line was connected to a five Volt power source and a vertical line was connected to the oscilloscope. This allowed the waveform to be inspected and the shortest press to be estimated. The waveform has very little bounce which implies that including a de-bounce algorithm is not necessary in this project. The minimum button press time was fifty milliseconds. This is an important as it effects the polling time and total utilisation of processing time. When a button is held down, the waveform persists. This means a choice has to be made between the press counting as a single press or as many presses until the button is released. The programming of these two choices is equally challenging and thus it was decided to treat 21 the long press as a single press and to wait for the button to be released before looking for the new press.

Cursor

The cursor functionality has been started as the included library mentioned above includes cursor functions. This has been worked with and functions allowing the cursor to work with the chosen screen layout and specifc message size have been outlined in the code. Functions allowing the cursor to be moved between characters in all situations have also been created for the specifc screen layout that has been chosen. This has lead to a number of design decisions which have been made. The first is whether the text should be inserted or overridden when the cursor has been backtracked through the text. Overriding the text is less intensive computationally and is simpler to program. However from a usability perspective insert is the more natural option as this is the method of many modern devices. For these reasons override has been chosen initially however if time and resources permit insert is an extension goal to the project. Secondly a choice between allowing users to insert text anywhere in the message string, even after blank space, or only where text has already been placed (or a adding to the end). A decision was made to allow the user to insert characters anywhere in the message, regardless of unused space and to fill the unused space with spaces.

Finite State Machine

Due to the restrictive nature of the keypad, a finite state machine in the form of old mobile phones is needed to allow users to access all alphabetic characters.

When a button on the keypad is pressed, the position of this press is passed to a decoder program. This program essentially takes in a key press and returns an array which is two characters long. The first character is the character to be placed on the screen and the second character is a message character that is used to tell the program whether to stay in the same place, move forward or perform some other special function. It would stay in the same place in the situation where it is the first character of a set or where the pressed key is the same as the previous. This would mean that the user is still cycling through the characters associated with that key. It was initially desirable to simply use a two dimensional array to formulate the finite state machine. However this was not feasible due to different keys having different amounts of characters associated with them. To make this work it would require an array as long as the lowest common denominator of the amount. This would turn out to be sixty characters long due to there being keys with two, three, four and five characters. Thus the code structure used to allow users to cycle through characters was an array of arrays, shown in Appendix G. This allowed different lengths to be used whilst still primarily using the same method of accessing the characters. A variable is also held to keep track of how many times a key has been pressed. This corresponds to which element in the array should be returned. This variable is reset when a different key is pressed. The secondary return byte allows for special functionality to be returned as well as nor- mal characters. This includes: 1. Send: This key initialises the process of sending the message to another client. It tells the unit the message is ready and should be sent when the server polls it next. 2. Save Character: When the desired character has been reached and the next character is on the same key (for instance two of the same letters in a row) it is necessary to have a key which does not add a character but saves the current one and moves the cursor forward. The 'A' character was used to implement this functionality. When it is invoked the decoder program returns a space (as that is the default state of each character in the message 20 array) and the signalling character to tell the program that it needs to move forward. It is noted this functionality can also be achieved by using the cursor. 3. State Switch When invoked this key switches between the default writing message state and the reading message state. This will show any queued messages using first in first out methodology.

References and Standards

We are currently implementing the threads using Protothreads, a low-overhead, stackless approach.
The Universal Graphics Library (u8glib), is a general graphics library for communication with various (read many) standard graphical screens. We chose this as a simple and easy to use library, we many options available for extension if required.
Communication will be through the I2C protocol. This protocol is simple to follow, and a good introduction for students with limited exposure to embedded communication.