EFI332 Project Software Development at SourceForge

Low Level Code : In general there are pairs of .c and .h files for each of the 3 modules of the 68332. The initializations and lower level code to implement most of the higher level functions are contained in these files.
FI Stuff : The meat of the FI algorithm is contained in fuel.c and spark.c with the bulk of the table data in table.h.
Flash Handling : flash.c/.h : all flash handling routines. Note that everything is run out of battery backed ram in the baseline version.
Utilities : utils.c/.h : table lookup routines and other utilities.
efi.h : This routine contains most of the application specific variable initializations specific to this application.
hw.h : Contains many of the hardware specific macros and defines.
Boot Code : Uses rom_start.c by Al Grippo.

OS : None !
Rate Loops : main.c contains the top level executive. With no OS for task scheduling, this is an infinite loop scheme with three rate groups driven from the PIT. The highest rate loop runs at 200 Hz and consists primarily of filtering the A/D inputs. The board has some hardware filtering and there is some done in software as well. The next rate group runs at 100 Hz and contains the majority of the FI calculations. The slowest rate group runs at 10 Hz and handles console input and serial I/O. There is a timer mechanism that measures the spare time remaining at the end of the most time intensive cycle. Current margins are a little more than 1 ms on a 5 ms cycle (1/200Hz).

Files : Most of the FI algorithms are contained within the modules spark.c, fuel.c, and table.h. The algorithm is based on the open loop calculations of GM's 8051 PCM. The starting point for the table lookups come from disassemblies of this unit. Testing the algorithm comes very close to duplicating data logs of cars equipped with the 8051. More details on the FI page.
Stepper : Currently incomplete and needs work.

The same memory map defined in Al Grippo's code is used. VBR is at 0xB0000, with the stack growing down from the top of RAM at 0xC0000. User code at 0x80000 - 0xAFFFF. A little inefficient since there is a fair amount of space between the stack and VBR. In this implementation the table data is located in the user code block so there is some unused RAM above the vector base table. Current code size is near 64k.

Format : The fixed point math implementation used here is about the simplest possible. It is set up for a 24:8 split of a 32 bit integer so the maximum resolution is 1/256 or about .0039.
Overflow Protection : Note that the macros do not have any overflow protection whatsoever so extreme care must be used in coding any equations using fixed point math. Due to the 8 bit shifts on the 24 bit whole number, all intermediate values must be verified to be less than 2^16/2 or 32767. In several cases, values are prescaled to maintain this and multiplies and divides are rearranged at the expense of readability to get the fixed point performance gain. In this application, the algorithms aren't too complicated so hopefully the readability loss is minimal.

Based on the 58XX microcode from the efi332 site, but modified to eliminate the psp35 function to save space. See the TPU page for details and notes.

PC Side Subprojects : There are two subprojects set up to manage the serial comm code that resides on the PC side. One is labview based and the other is Windows based. A graphical front end to the Windows application is badly needed - several bugs have been made obvious by the use of real-time plotting available in the labview application.
Stream Format :The stream has 146 bytes of data with a 4 byte synch header. There is currently no checksum. A routine in main.c packs the telemetry frames directly and there is provision for multiple minor frames. A serial buffering algorithm adopted from a Motorola AN manages the flow from the SCI for both receive and transmit operations.
Transmit Side Handling : Frames are filled by a routine in module main.c. Once filled, they are sent byte by byte to the SCI by an interrupt driven arrangement that manages the transmission of the entire frame over the next few cycles of the highest rate loop.
Receive Side Handling : On the receive side, characters coming in trigger an interrupt which stores them in a circular buffer for later retrieval by a console handler which runs in the slowest rate group.