L Computer Science & Electrical Engineering

Real-time Systems – Lab 5


A bridge access controller and simulator


This assignment is about implementing a program for controlling car access to a narrow bridge by means of traffic lights. Due to the lack of a real bridge and real cars in our lab environment, part of the assignment will also be concerned with implementing a simulation of these items. In order to keep the two programs clearly separated from each other, the AVR Butterfly boards will be used to run the controller while the environment simulator will be implemented on the PCs normally acting as development hosts. The latter requirement enables not only realistic integration of the controller with its environment, but also easy access to environment simulations written by other lab groups. If this lab assignment is implemented correctly, your controller should be able to control the environment simulated by any other lab group, and vice versa!

The general problem setting is as follows:
See the following figure for schematic layout.



Controller

Your first task is to construct the software of the computer that controls the traffic lights. This controller should be implemented as a reactive object design on the AVR Butterfly using the TinyTimber kernel (source files: TinyTimber.h and TinyTimber.c).

Sensor input to the controller would realistically be made available to the controller as four separate interrupt signals, in the style of the joystick interrupts from lab 4. However, in the interest of simplifying the physical integration of the controller with its environment, we will multiplex all four signals over a single channel: the receiver side of the Butterfly's Universal Synchronous and Asynchronous Serial Receiver and Transmitter (USART). A reception interrupt on the USART may thus mean any combination of 4 sensor signals, and we will use the received data value to identify individual sensors according to the following table:

Bit 0
Northbound car arrival sensor activated
Bit 1
Northbound bridge entry sensor activated
Bit 2
Southbound car arrival sensor activated
Bit 3
Southbound bridge entry sensor activated

Likewise, we will use the transmitter side of the USART for implementing the four output signals that control the status of each lamp of the traffic lights. The four signals will map onto the bits of the transmit data register as follows:

Bit 0
Northbound green light status
Bit 1
Northbound red light status
Bit 2
Southbound green light status
Bit 3
Southbound red light status

In a real life implementation, these signals would most likely correspond to bits of a parallel port instead, that connect to the actual lamps via some suitable amplifier and AC power gate.

See the ATmega169 manual pages 151 and onwards for detailed info about the USART.

The core task of the controller is to control the status of the four lamps on basis of just sensor inputs and the passage of time. The controller logic is subject to the following requirements:
The most important requirement is however this: base your design on how you would like a real bridge controller to function. Make clear assumptions about how cars are supposed to behave, and if these assumptions turn out to be false, just rely on the environment simulation to show what will happen. Use common sense!

Simulated environment

The task of the simulated environment is to maintain a simple animation of the bridge, the traffic lights, and a dynamic set of cars that arrive at the sides of the bridge, wait in queues, and eventually cross the bridge. The following guidelines all relate to the simulation of the bridge and car environment:
To connect to the controller application, the simulated environment should use serial port COM1 (also known as /dev/ttyS0), connected to the AVR Butterfly USART port via a null modem cable. That is, the environment simulator should receive lamp status updates according to the bit layout described above for the controller, while transmitting sensor signals that follow the layout expected by the controller. The following schematic diagram illustrates how the input and output signals of the controller and the simulator fit together.



On important point to notice is that reception of lamp signal data represents a desired state of the lamps, which means that it does not matter if the status of some lamp is set to on several times in a row – the lamp will simply stay on in this case. This should be contrasted to the sensor signals generated as input to the controller; here each active bit in each message stands for a new sensor activation, and thus a series of identical sensor messages means something different than a single messagl e. This distinction is sometimes referred to as gated vs. edge-triggered logic in digital electronics.

Implementation details

The controller will be a reactive objects design that runs on the AVR Butterfly on top of the TinyTimber kernel. Because the controller functionality will essentially be a state machine taking input from a single source, the number of objects can be kept low, perhaps as low as 1. The LCD display and the joystick aren't really required in this assignment, but for debugging purposes it may nevertheless be wise to at least let the controller display some information about its current state on the LCD.

The simulator implementation on the PC host will use POSIX threads as its concurrency mechanism. In order to obtain better POSIX compatibility, and also to make the resulting program portable to non-Windows platforms, the simulator will be built to run under Cygwin – a Windows extension that provides a typical Unix programming environment including the gcc compiler, C libraries and includes files, and an assortment of Unix utility tools and command shells.

Manual pages for system calls and other library information are generally available via the man command on a Unix system, but under Cygwin the man information isn't always complete. For better Unix manual page coverage, see the online documentation resource UnixWare 7.

The design of the simulated environment can be done in numerous ways, using any number of threads. One particularly interesting design – no the least because of its sharp contrast to the reactive objects model – will use a dedicated thread for each simulated car, and literally use semaphore operations to stop and restart the car whenever the simulation so requires. Likewise, car speed can be controlled by means of delay statements. Anyway, whatever design you choose, make sure it is clear and comprehensible. It is especially important that the design is robust in the sense that it is able to handle all forms of input in any state.

For communication with the AVR Butterfly, the serial port COM1 should be used. Under Cygwin, the COM1 port is accessed as an ordinary file named /dev/ttyS0. Manual page termios describes various system calls for controlling the characteristics of a serial port (referenced as a file descriptor obtained from previous open). The keyboard and the terminal screen will automatically connect to your program as the stdin and stdout streams, respectively. See the manual page stdio for more information. To generate a crude but perfectly adequate "graphical" output from your application, generate plain text whose placement and appearance is governed by inserted ANSI terminal control sequences.

Consult the Asyncronous serial communication page for better understanding of how especially start/stop bits work over serial line.