Projects - User contributions [en]

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

2015-10-23T04:03:12Z

A1628314: /* Potential Issues */

== '''Introduction''' ==

== '''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. 

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.

=== '''Approach/Architecture Design''' ===
The LAN has a star architecture with token ring methodology. The network will consist of a server and at least two clients terminals. The clients will each be given a chance to send a message in turn and thus holding a token granting access to the server.

== '''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.

==='''Inter Integrated Circuit'''===
Inter Integrated Circuit known better as I2C (''pronounced I-squared-C'') was our chosen communications protocol. I2C is a pull down high protocol utilizing 2 lines, data and clock. An I2C communication bus uses a Master/Slave approach. Where there is one Master device which controls all traffic on the bus from any slave devices. For our project our I2C buses will have only a single slave device to prevent complications.
==='''Messaging'''===
Messages will be stored in each client until the server poll the client to see if they have a message. the server poll each client in a loop. The messages are 31 characters long 30 byte character message and 1 byte integer address stored as a character. When the client is polled it will either respond with a null message or an actual message. the server will read the message and process it if need or move on to polling the next client.

== '''References and Standards''' ==
We are currently implementing the threads using [http://dunkels.com/adam/pt/ Protothreads], a low-overhead, stackless approach. 
The [https://code.google.com/p/u8glib/ 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 [https://en.wikipedia.org/wiki/I%C2%B2C I2C] protocol. This protocol is simple to follow, and a good introduction for students with limited exposure to
embedded communication.

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

2015-10-23T04:02:52Z

A1628314: /* Approach/Architecture Design */

== '''Introduction''' ==

== '''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. 

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.

=== '''Approach/Architecture Design''' ===
The LAN has a star architecture with token ring methodology. The network will consist of a server and at least two clients terminals. The clients will each be given a chance to send a message in turn and thus holding a token granting access to the server.

=== '''Potential Issues''' ===

== '''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.

==='''Inter Integrated Circuit'''===
Inter Integrated Circuit known better as I2C (''pronounced I-squared-C'') was our chosen communications protocol. I2C is a pull down high protocol utilizing 2 lines, data and clock. An I2C communication bus uses a Master/Slave approach. Where there is one Master device which controls all traffic on the bus from any slave devices. For our project our I2C buses will have only a single slave device to prevent complications.
==='''Messaging'''===
Messages will be stored in each client until the server poll the client to see if they have a message. the server poll each client in a loop. The messages are 31 characters long 30 byte character message and 1 byte integer address stored as a character. When the client is polled it will either respond with a null message or an actual message. the server will read the message and process it if need or move on to polling the next client.

== '''References and Standards''' ==
We are currently implementing the threads using [http://dunkels.com/adam/pt/ Protothreads], a low-overhead, stackless approach. 
The [https://code.google.com/p/u8glib/ 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 [https://en.wikipedia.org/wiki/I%C2%B2C I2C] protocol. This protocol is simple to follow, and a good introduction for students with limited exposure to
embedded communication.

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

2015-10-23T03:59:47Z

A1628314: /* Messaging */

== '''Introduction''' ==

== '''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. 

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.

=== '''Approach/Architecture Design''' ===
=== '''Potential Issues''' ===

== '''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.

==='''Inter Integrated Circuit'''===
Inter Integrated Circuit known better as I2C (''pronounced I-squared-C'') was our chosen communications protocol. I2C is a pull down high protocol utilizing 2 lines, data and clock. An I2C communication bus uses a Master/Slave approach. Where there is one Master device which controls all traffic on the bus from any slave devices. For our project our I2C buses will have only a single slave device to prevent complications.
==='''Messaging'''===
Messages will be stored in each client until the server poll the client to see if they have a message. the server poll each client in a loop. The messages are 31 characters long 30 byte character message and 1 byte integer address stored as a character. When the client is polled it will either respond with a null message or an actual message. the server will read the message and process it if need or move on to polling the next client.

== '''References and Standards''' ==
We are currently implementing the threads using [http://dunkels.com/adam/pt/ Protothreads], a low-overhead, stackless approach. 
The [https://code.google.com/p/u8glib/ 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 [https://en.wikipedia.org/wiki/I%C2%B2C I2C] protocol. This protocol is simple to follow, and a good introduction for students with limited exposure to
embedded communication.

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

2015-10-23T03:54:48Z

A1628314:

== '''Introduction''' ==

== '''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. 

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.

=== '''Approach/Architecture Design''' ===
=== '''Potential Issues''' ===

== '''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.

==='''Inter Integrated Circuit'''===
Inter Integrated Circuit known better as I2C (''pronounced I-squared-C'') was our chosen communications protocol. I2C is a pull down high protocol utilizing 2 lines, data and clock. An I2C communication bus uses a Master/Slave approach. Where there is one Master device which controls all traffic on the bus from any slave devices. For our project our I2C buses will have only a single slave device to prevent complications.
==='''Messaging'''===

== '''References and Standards''' ==
We are currently implementing the threads using [http://dunkels.com/adam/pt/ Protothreads], a low-overhead, stackless approach. 
The [https://code.google.com/p/u8glib/ 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 [https://en.wikipedia.org/wiki/I%C2%B2C I2C] protocol. This protocol is simple to follow, and a good introduction for students with limited exposure to
embedded communication.