Version1:Development
From Albatross
Albatross runs a number of pieces of software, each developed with their respective toolchains and development environments. The layout of our development environment is illustrated below:
Contents |
System Operation
The general system operation of the system is slightly different in 'development mode' than it is in flight mode. The following two sections outline the differences.
Development Mode
The following sequence of events occur when snapper boots:
- The bootloader (U-Boot) is loaded from snappers onboard NOR-flash.
- Initialises basic hardware like SDRAM and clocks.
- The U-Boot boot script is run, performing the following:
- Initialises the ethernet (MAC address)
- The FPGA is programmed from code also stored in the boot NOR-flash.
- Fetches the kernel image from TFTP
- Sets the kernel command arguments
- Decompresses the kernel, CRC checks it, and runs the kernel
- One of the command arguments to the kernel instructs it that its root filesystem is to be mounted using NFSRoot. The Root filesystem is located on the development machine.
- Once the kernel has booted it runs init and thus the init scripts.
Flight Mode
Snapper boot up: Steps 1 and 2 same as above.
- The U-Boot boot script is run, performing the following:
- Slightly higher level hardware initialization.
- The FPGA is programmed from code also stored in the boot NOR-flash.
- The PXA255 MMC controller or the Snapper xD controller is initialized.
- Linux Kernel image is loaded from NAND-flash (either MMC or xD).
- Sets the kernel boot command arguments.
- Decompresses, CRC checks and runs the kernel.
- One of the boot arguments to the kernel causes the root file system to be on the NAND-flash media.
- Once the kernel has booted, it runs init and thus the startup scripts.
- The startup scripts start all the various daemons related to our flight control system.
Development Environment
PCB Design
TThe PCB was designed using Protel DXP 2004. This version proved considerably more stable than the previous offering from Altium, which was a welcome addition. Although the size of the library in DXP was substancially increased it did not stop us from having to draw most of the exotic components ourselves.
Through the PCB design phase we made a number of models of the PCB, to check that it would correctly fit inside the case we had selected and to check the orientation of the IMU sensors; that is to check we were measuring acceleration in every direction, and positive rotation in the same direction as is standard for planes (see here). Images of these models are shown below;
FIXME
Subversion (SVN)
Confiuration
Subversion was a bit hard to get going, or at least to get working with apache.
Note remember to install
apt-get install libapache2-svn subversion subversion-tools
The repository is configured as suggested here and here. The contents of our sites-enabled/default apache2 configuration are;
NameVirtualHost *
<VirtualHost *>
DocumentRoot /var/www/
<Location /svn/albatross>
DAV svn
SVNPath /home/svn/albatross
AuthType Basic
AuthName "Albatross SVN Repository"
AuthUserFile /home/svn/htpasswd
Require valid-user
</Location>
....
</VirtualHost>
Add some users
sudo htpasswd2 -c -m /home/svn/htpasswd john
Using Subversion
To Checkout
svn co http://johnstowers.no-ip.com/svn/albatross
To Commit
svn commit -m "Message" Directory
Commits the specified directory,( . = current directiry), or the whole project (if called from svn root directory) to the repository.
Information
svn info
Displays the revision# of the repository, who last committed, and when, etc
svn status
Displays the diferences (if any) between local copy and repository
Updating
svn revert -R Directory
Blows away local changes and makes local copy identical to the repository. R for recursive.
svn update
FIXME Hugo
Supervisor Software Development
The development environment for the Supervisor software is as follows
- System running Ubuntu Linux.
- avr-gcc and uisp, installed with
apt-get install avr-gcc avr-libc uisp
Snapper FPGA Development Environment
Code for the FPGA is developed using Quartus II software. At this stage the free web edition is being used (which unfortunately is not available for Linux). Most development is done using the simulator because it is easier to debug and verify correct operation in the simulator, and because the process of programming the FPGA on Snapper is somewhat complex. Once new code is compiled for the FPGA the following sequence of events occurs:
- The code is transfered onto the server (which hosts the TFTP and NFS-root services) via FTP from the Windows system running Quartus.
- Snapper is power-cycled.
- During boot, U-Boot fetches the new FPGA image with TFTP from the server, and uses it to program the FPGA, then boots the kernel as usual.
Alternatively, there is a kernel driver for programming the FPGA that can be used without power cycling the FPGA:
- The FPGA code is compiled in Quartus and the resulting binary is transfered to the NFS-root server.
- On a shell on Snapper, the FPGA is programmed with:
dd bs=128k if=fpga-code.rbf of=/dev/snapper_fpga
The dd command does a raw copy of the FPGA code file to the device representing the kernel programming driver in blocks of 128kB (the block size argument needs to be used so the entire file - about 70 kB - is transfered in one operation, rather than in smaller blocks).
The .rbf (Raw Binary Format) FPGA code image format is used, as it contains the exact bit stream used to configure the device without any header or meta-data.
Simulator Development Environment
The flight simulator is based on CRRCsim, see Simulator, which is a fairly standard C/C++ program, and developed with standard programming tools, including:
- gcc, g++, make, etc
- text editor (vim)
PXA255 Development Environment
The PXA255 is an low-power microcontroller with an XScale-based ARM CPU core. The GNU compiler tools (gcc et al.) support generating binaries for the XScale CPU, with the compiler running on a normal Linux computer; this technique is known as cross-compilation. Unfortunately, putting together a working GNU gcc cross-compilation environment is tricky and prone to error. Dan Kegel has written a set of scripts to automate the process, which, together are known as Crosstool. We used Crosstool 0.32 to build a gcc-3.4.3, glibc-2.3.5, binutils-2.15 toolchain which appears to work correctly.
Because the PXA255 is running the Linux operating system, programming for it is essentially identical to programming any other Linux system, and can use all the standard APIs (e.g. for network access). The build environment therefore consists of:
- arm-linux-gcc, arm-linux-g++, etc.
- make, bash scripts etc.
- all running on Ubuntu Linux.
See Xscale Toolchain.
Coding Conventions
C Code
File Headers
Use the following where appropriate
/*------- Albatross UAV - Hardware Interface Daemon -------------------------* * * File: hwd.c * Authors: John Stowers, Hugo Vincent * Description: Handles acces to the hardware such as * reading the IMU sensors (over the FPGA<->CPU memory interface, the * serial port, or both. * * Copyright (C) 2005 John Stowers, Hugo Vincent * The code was from Albatross (http://johnstowers.no-ip.com). * Distributed under GPL. */ /*-------Includes------------------------------------------------------------*/ /*-------Constants-----------------------------------------------------------*/ /*-------Macros--------------------------------------------------------------*/ /*-------Globals-------------------------------------------------------------*/ /*-------Types---------------------------------------------------------------*/ /*-------Function Prototypes-------------------------------------------------*/ /*-------Main Function-------------------------------------------------------*/ /*-------Implementation: Functions-------------------------------------------*/
Functions
void function_name(int argOne, char *argTwo);
Variables
longVariableName VariableWhichIsAStruct ENUM_NAME
Definitions
struct someStruct_t #define SOME_CONSTANT 6
VHDL Code
I suggest we stick to the http://www.OpenCores.org coding conventions as specified here
