Here you will find documents describing the various open format structures and files used for Enigma.
Also on this page you will find APIs and sample code if you would like to port your software to the Enigma platform or extend Enigma with your own software.
This page is "under construction". Only the waypoint and route file format specifications has been released.
Further documents will become available once I have had the chance to write these documents which is a task that I will start once Enigma is reasonably mature, resulting in stability of the data formats (nothing is worse than a format that keeps changing due to new ideas...)
Expect further documents to appear on this page during the course of the next few months.
Waypoint and route file format (Waypoint.EWD and route.EWD)
Available: Download using this link
Airport data file format (Airports.EWD)
Available: Download unsing this link
Raster map file format (fileformat MGLM)
Available: Download using this link
Terrain data file format
Uses standard GTOPO30 DEM files, no further information required.
Note: it is possible that higher resolution augmentation data will be supported for areas of high terrain dynamics but no format has been decided on at this point.
Vector map data file format (Airspace data,
ground features, obstacles)
Airspace data file format (Airspace.EVD)
Available: Download using this link
Documentation for APIs not yet available:
Enigma runtime module (extending Enigma with a software module)
Enigma application programming (replacing Enigma application with your application, using FlightOps operating system)
Enigma load file creator (Create a file from your executable that can be automatically installed)
Enigma checksum (Append checksum information to your executable for Enigma verify-before-execute functionality)
Enigma instrument third party developer support common questions
1) Why are we opening Enigma to third party developers ?
The reason for this can be found when looking at various fine pieces of aviation related programming by individuals, available typically on PDA platforms as these items are relatively easily available. Also, some attempt to use embedded PC systems with varying levels of success. Clearly, an affordable solution designed for the rigors of the cockpit is required to accomodate this.
2) What's in Enigma ?
Enigma is based on an Atmel AT91SAM9261 processor (brand new release at time of writing, quantities still limited). The prototype Enigma used engineering samples of this chip (resulting in some grey hairs !). This processor provides a 16K instruction and 16K data cache. We provided Enigma with 32 bit wide memories, 4 Mbytes of Flash and 4 Mbytes of battery backed fast static RAM. A second processor, an ATMega 128 AVR is responsible for much of the sensor data. It is also used for a variety of other tasks, such as voice/audio synthesis.
A further ARM7 processor forms part of the built in GPS system.
3) What do I need to know in order to program Enigma ?
We would assume that most programmers will be happy using the built in FlightOps operating system, which we wrote for Enigma. This is quite a powerful system providing dynamic memory management, pre-emptive tasking with mutexes and of course a lot of drawing and file system support. FlightOps also takes care of communicating with the second processor and obtaining sensor data. In order to use FlightOps, you need to know the API which we will provide. In addition to that, you need to know a lot about the system architecture and you certainly have to be familiar programming real embedded systems (i.e. not something running Linux or Windows). Despite the operating system taking care of many of the more tricky issues, a lot is left. For example, if you want to use a serial port, you need to know how to initialize it and write interrupt routines etc. A good, sound knowledge of ARM assembler and architechture is required. You'll also have to study Atmels AT91SAM9261 documents in detail.
4) Enigma architecture in brief.
As Enigma is a dedictated system, both operating system as well as application run with full processor priviliges (supervisor mode). While the MMU is used in order to run the data cache, all addresses are used in real mode (i.e.: virtual address = real address). As only a single application runs, this provides a performance benifit. No virtual memory is used as there is nothing to swap memory to, in any case that is something you probably would not want on a crtitical real time system.
Everything in Enigma is tuned towards maximising performance from the core processor which is clocked at 196Mhz. It is vital that your application program is written such that optimimum use is made of caches and a very fast 160K RAM workspace. This requires good planning and knowledge as to how your compiler produces code. If you don't know what a compiler does, I'd recommend that you do not attempt to write a program for Enigma unless it is a simple one.
5) Development environment
Most will probably opt for the GNU C/C++ compiler tool chain hosted on either Windows or Linux. The FlightOps operating system is written in Embedded Pascal for the ARM as is our application. Much of the time critical code is written in ARM assembler as is all of the screen drawing. There is no problem using C or other languages as a simple, SWI API calling interface is used. All you need is a system that can compile code to run at a certain address and place data at various memory locations related to the performance of the connected memory.
We will make a simple "hello world" program in C available that can be used as a starting out program.
You will most likely want to use a ICE hardware debugger system, if not, one of the serial ports provides a preconfigured debug interface to a terminal (supported by FlightOps).
6) Open source
We have no plans currently to release either FlightOps or our application as open source - partly this is due to these items having been developed with a system that is not available for purchase and incompatible with anything else out there. Also, due to the application being used in an aircraft we cannot allow anybody to change our code without our supervision. The responsibility for our application lies with us. For the same reasons, the responsibility for your application lies with you.
You are welcome to use FlightOps (by means of the published API) but you will have to write or port your own application.
7) When will the system be opened ?
We will allow third party developement as soon as we are comfortable that FlightOps has reached a level where changes or updates have reached a level where the application itself will be unaffected unless a good reason exists. We expect this to be reached 4-6 months from date of release of Enigma. This stage has to be reached as obviously the API needs to be documented so you can use it. This document will be released once it's not going to change (at least not by much).
8) What are typical applications ?
Almost anything that can fit into the hardware of Enigma (which should be quite a lot). Obviously, with a built in GPS, a good color screen and nice user interface, the sky is the limit. With all the supported hardware from engine monitors to attitude sensors and a host of communication interfaces a lot can be done.
Back to Enigma page