6 Architecture

Last updated:

$Date: 2002/12/04 19:42:10 $

Some ``glue'' that will help understand the rest of this document:

4. Global hardware architecture

Figure 4.1: Global hardware
\begin{figure}\centering\epsfig{file=graphics/global_hardware_architecture_01.eps, height=14cm}\end{figure}

In figure 4.1 is presented the system as a whole (well, except the mechanical parts, OK).

We use two CPUs board at the time, possibly more in the future.

Rationale for this:

First and main CPU is a Motorola 68000 based board, the NF300 and its application board. This CPU is responsible for high level strategy and decision making based on information fed up by other CPUs and/or peripherals.

Rationale for this:

The second CPU we use is a Microchip PIC 16F877. Right now it's dedicated to PID control of robot's moving.

Rationale for this:

Booth CPUs are connected via an I2C bus.

Rationale for this:

Main points, this modular design design allow us:

5. Global software development

Figure 5.1: Global software development architecture
\begin{figure}\centering\epsfig{file=graphics/global_software_devel_architecture_01.eps, height=15cm}\end{figure}

Figure 5.1 outline the development system. Software tools and re-used code are parts of the robots as well as gear and electric wires.

The NF300 board run the RTEMS real-time executive.

Rationale for this:

For a more in-depth presentation of RTEMS, see part VIII.

On the host side, RTEMS relies on GCC and newlib as well as other GNU tools. Newlib is an open source implementation of the C library specially targeted towards embedded applications (small footprint and fast, for a reasonable functionality loss cost). Programming and debugging is made trough BDM (Background Debugger Mode) built in CPU32 Motorola architecture, by the way of an host driver and a parallel interface - these two last elements being quite delicate - resulting on 80% of the power of an ICE (In Circuit Emulator) for 20% of the price. The serial port built-in the 68332 provides logging capabilities.

The PIC board, right now performing mainly date acquisitions and actuators, runs an interrupt driven applications. The development chain is an assembly of various tools, ranging from a free but close source compiler to a user space driver: the GPASM assembler is fed through the C2C compiler. Picprog is then used to program the device. The I2C bus, by the way of a serial/I2C interface (19), then give us logging capabilities as a substitute for debugging. Up to now, the PIC application is both:

... so that a purely interrupt driven code, that's to say without an OS is well suited.

For a more in depth presentation of the PIC tool chain, see part IX.

Synthesis till now:
The key point is the assets: this combination of hardware and software chain is flexible enough to be re-used on many kinds of embedded projects, being robotic or not, and allow experimentation on many techniques and tools.

6. Global software system

Figure 6.1: Global software system architecture
\begin{figure}\centering\epsfig{file=graphics/global_software_sys_architecture_01.eps, height=15cm}\end{figure}

Finally, figure 6.1 show, err, the application software as we know it to this date. The NF300 will hold the knowledge about the match rules, and thus will be responsible for strategy and decisions. It will provide event logging for post-match (or post-mortem) analysis. On a smaller scale it will be responsible for: ,