An engine management system for gasoline spark ignition engines.

The firmware is flexible to most engine configurations, and with 16 outputs it is suitable for up to an 8 cylinder engine with sequential fueling and ignition.

Features:

• 16 high precision outputs with 250 nS scheduling accuracy usable for fuel or ignition
• 24x24 floating point table lookups
• Speed-density fueling with VE and lambda lookups
• Supports 8 12-bit ADC inputs when using AD7888
• Supports 16 GPIOs
• Configurable acceleration enrichment
• Configurable warm-up enrichment
• Boost control by RPM
• Frequency sensor inputs
• PWM outputs
• Fuelpump safety cutoff
• Mostly runtime-configurable over USB interface
• Check Engine / Malfunction Indicator control

1. Decoding
   1. Even Teeth
   2. Missing Teeth
2. Static Configuration
   1. Frequency and Trigger Inputs
   2. Events
   3. Sensors
   4. Tables
3. Runtime Configuration
4. Compiling
5. Programming
6. Simulation
7. Hardware
   1. STM32F4
   2. GD32F470.

Currently the only two decoders styles implemented are even-tooth and missing-tooth wheels. Wheels of each type are supported on both cam and crankshaft, and both support an optional cam sync input. Each wheel configuration has a tooth count and an angle per tooth. For a cam wheel it is expected that this totals up to 720 degrees -- for example a 24 tooth wheel on the cam is 24 total teeth with 30 degrees per tooth. A crank wheel totals 360 degrees. Without a cam sync, the current wheel angle has a random phase at the granularity of the wheel.

This decoder is configured with a tooth count and angle per tooth. Two decoder-specific options:

• rpm-window-size - RPM for table lookups is derived from an average this many teeth
• min-triggers-rpm - Number of teeth to have passed since sync-loss to re-establish an rpm, before (optionally) waiting for a cam sync pulse.

This wheel can be used without a cam sync, but will have random phase to the granularity of the wheel, and is only useful on low resolution wheels. For example, a Ford TFI distributor has a rising edge per cylinder: It would be configured with 8 teeth, 90 degrees per tooth. An ignition event could be configured for each cylinder, and the random angle is not an issue due to the use of a distributor.

An example of a even tooth wheel with a cam sync is the Toyota 24+1 cam angle sensor - 24 cam teeth, 30 degrees per tooth, and an additional 1-tooth wheel. The first tooth past the cam sync is at 0 degrees.

This decoder is configured with a tooth count and angle per tooth. The tooth count includes the missing tooth, so a 36-1 wheel is 36 teeth. If the wheel is crank-mounted without a cam sync, cam phase will be unknown and events should be symmetric around 360 degrees (batch injection and wasted spark). The first tooth after the gap is at 0 degrees.

See the runtime configuration section for details on the runtime control interface. Almost everything is configuable through that interface, but to use a different engine configuration (read: not my Supra), it is probably best to start with modifying the source code.

Static configuration is in config.c. The main configuration structure is config, along with any custom table declarations, such as the provided example timing_vs_rpm_and_map. Pin configurations are platform specific and are documented in the platform source.

Certain inputs are used as frequency inputs which may also act as the decoder wheel trigger inputs. Each one has a selectable edge and type.

Event configuration is done with an array of schedulable events. This entire array is rescheduled at each trigger decode, allowing any angles (0-719) to be used for events, as long as a trigger event occurs between any two fires of a given event (e.g. for FORD_TFI, for 8 events, as long as the decoder fires twice in 720 degrees, which of course it does). Currently there are two types of event:

The event structure has these fields:

Sensor inputs are controlled by the sensors config structure member, and is an array of configured inputs. The indexes into the array for various sensors are hardcoded, use the provided enums to reference the sensors. Each sensor entry is a structure describing what pin to use, and how to translate the raw sensor value into a usable number:

For method SENSOR_LINEAR, the processed value is linear interpolated based on the raw value between min and max (with the raw value being between raw_min and raw_max)

The onboard ADC is not used. Instead an external ADC is connected to SPI2 (PB12-PB15). Currently a TLV2553 or AD7888 ADC is supported.

Tables can be up to 24x24 float values that are bilinearly interpolated. Use struct table to define a table, with the following relevent fields:

For a new table to be configurable over the console, it must be declared externally such that it can be directly referenced in console.c.

The EMS is uses a cbor-based (https://cbor.io/) binary RPC protocol for its console. For hosted mode, standard out and in are used to exchange messages, and on the stm32f4 target, the console is exposed via a USB virtual console. Details of the binary protocol are described in INTERFACE.md.

Requires:

• Complete arm toolchain with hardware fpu support.
• GNU make
• check (for unit tests)

Before trying to compile, make sure to bring in the libopencm3 submodule:

git submodule update --init

To run the unit tests:

make PLATFORM=test check

To build an ELF binary for the stm32f4:

make

obj/stm32f4/viaems is the resultant executable that can be loaded.

You can use gdb to load, especially for development, but dfu is supported. Connect the stm32f4 via USB and set it to dfu mode: For a factory chip, the factory bootloader can be brought up by holding BOOT1 high, or for any already-programmed ViaEMS chip, the get bootloader command will reboot it into DFU mode. Either way, there is a make target:

make program

that will load the binary.

The platform interface is also implemented for a Linux host machine.

make PLATFORM=hosted run

This will build viaems as a Linux executable that will use stdin/stdout as the console, and event/trigger updates will be sent to stderr . The test trigger that is enabled by default will provide enough inputs to verify some basic functionality. Full integration testing using this simulation mode is planned.

The hosted implementation uses threads to simulate interrupt handling and the timers/DMA. It attempts to schedule these two threads with realtime priority. If you experience difficulty keeping sync due to expired triggers (due to scheduling latency), make sure the threads have permissions to be realtime, or otherwise constrain it to a single cpu.

The current primary hardware platform is an ST Micro STM32F407VGT microcontroller. There are a few non-production-ready hardware designs available under https://github.com/via/viaems-boards, though I would recommend anyone attempting to use those designs contact me. The STM32F4-DISCOVERY board can be used with this firmware, with appropriate extra hardware for vehicle interfacing.

Note: These are subject to change with the next hardware design, which will be moving to better support a 64 pin chip and more flexible PWM outputs.