ARM based EFI: - developer info!

To avoid confusion, I propose that in the future

Significant part of the development effort is shared.

This is the primary fuel injection system. Smaller than v3.x and able to communicate with the other VEMSFrontier boards

uC) to comm with big ARM based boards, like
  • another armefi
  • external ignition module: basically similar to armefi, with some input and output changes
  • case and clamping compatible with armefi
  • preferrably same (atmel arm or LPC2292) uc
  • CAN similar to armefi
  • trigger inputs similar to armefi
  • the DPAK clamping IGBTs (with input pads so the board can be used as dummy ignition amplifier if all else fails)
  • we need a DCDC for CDI anyway.

The easiest way to map pins is print page 23 .. 24 of the A3 manual and take pencil-notes (I know it has been partially done, but others must verify too: this way it only takes 1..2 hours). It seems that there are not much compromises needed

DROP: VemsFrontier/ArmUfo. ArmEfi? will be nice and manufacturable in every aspect, we don't need a downscaled board.

Strategy TPIC8101 or amplified acoustic signal into ARM

TPIC8101 was the perfect choice in the past. However, with the significant processing power available, I doubt it's usefulness. We can easily filter in the ARM (with slightly more lines of code than it takes to just communicate with TPIC8101), with a few percent of processing power. Note that TPIC8101 also sets gain in the digital domain, after it's internal ADC.

Power related

PNP dissipation: assume 1A current and 50% duty:

The 200 and 100ns are estimated switchoff and switchon times for Ugs=5V (the datasheet says 240 and 120 for Ugs=4.5V).

Will be cool with the slamping.

The number of switches for inj/ign (within some limits) can be decided at assembly time (minor firmware issue).

Every output must have at least an SMB for flyback protection.

6..8 has and max 4 has controlled flyback (PNP on bottom for cooling, FET on top).'''

No reason for using the PowerDip? version of L293D and not the SOIC L293D. In fact we need SMD.

[link to ST electronics pdf file]

On v3.2 we use the [SN754410] which has nice current range but thrughole sux

LPC2294 (144pin, 4 CAN) or LPC2129 (64pin, 2 CAN)

Quick info:

User manual May 3rd 2004:


April 1st 2005:

The 2294 is more expensive, but you can only buy 1 hamburger for the difference. Footprint is also a few mm bigger. But:

Mapping isn't much easier, big LPCs have the same collisions as the 64 pin chip, all the extras is only generic IO. But generic IO also helps, so featured IO need not be sacrificed.

2292 and 2294 would be identical in our application, it seems like the two addtional CAN busses collides with more useful special functions.

The atmel arm seems to win anyway.

2 CAN or more

I have a feeling that we will like 4 CANs in the future. With the new modular approach, it's good to have a board that is extendable to be the central brain. No need to stuff all 4 CAN transceivers onboard during the manufacturing, and no space on EC36 for all.

when to use MCP3208 channel and when to use internal AD

Even though MCP3208 is relatively cheap, we like the internal ADC more: because reading data from MCP3208 still requires 3 (!!!) interrupts for a sample since the SPI ain't have a queue.

So MCP3208 is ideal for temperature and alike, while knock should go into CPU (after AMPlified). This also suggests LPC2294 that has more nice ADC channels.

Reading through LPC user manual again, I was horrified to find that there is an interrupt for each internal ADC sample (or every received SPI byte). Still better than 3 interrupts for an MCP3208 sample, but sucks a bit.

Can someone confirm this? Maybe I'm wrong, search for FIFO from page 239 (definitely after UART).

TODO: check the time of a minimalistic interrupt handler, that just passes up received data to userspace'''. I'm sure it is below 2 usec (maybe 1), we'll need it to sample 30ksps of sound (and the max interrupt processing should be lower than 33 usec, including a dispatcher action and an event insert).

Trigger ( with minimal interrupt overhead )

First, trigger is clamped in HW. Than

An ADC (of 2) is appr. 364ksps but sweeping over 8 channels means only 45 ksps per channel. Perfect for knock and IonSense but trigger needs double samplerate. IIRC it is not possible to automatically (using PDC for transferring samples to memory and minimizing interrupt overhead) sample in arbitrary order (eg, 0,1,2,3,4,0,1,5,6,7 ), because the "conversion sequencer" can only go in sequence of the ADC_CHSR enabled channels (someone please confirm):

I don't think we need both channels. You're right about the ordering, but it seems to me that the "conversion sequencer" is only used when using the ADC while the processor is asleep. We can still use the PDC and change the sampled channels when we get the transfer complete interrupt (e.g. 0, 1, 2, 3 4, interrupt, 0, 1, 5, 6, 7 , interrupt ). This means 75k interrupt / sec that was ruled out earlier. However, it might work (with a fast, highly optimized assembly handler). Also, the trigger and knock/IonSense can be sampled with high freq, and the other channels just enabled for a run once in a while when necessary. The added code complexity due to non-even sampling should not be prohibitive.

The interrupt processing time is exactly what we are trying to minimize. 10..20k interrupt/sec is perfect, but 100k is rather tough (even if we write in assembly).

I picked this up from the datasheet:


Only one start command is necessary to initiate a conversion sequence on all the channels. The ADC hardware logic automatically performs the conversions on the active channels, then waits for a new request. The Channel Enable (ADC_CHER) and Channel Disable (ADC_CHDR) Registers enable the analog channels to be enabled or disabled independently. If the ADC is used with a PDC, only the transfers of converted data from enabled channels are performed and the resulting data buffers should be interpreted accordingly. Warning: Enabling hardware triggers does not disable the software trigger functionality. Thus, if a hardware trigger is selected, the start of a conversion can be initiated either by the hardware or the software trigger.


Software configurable VR/HALL (to let the end-user choose between VR and HALL without changing anything on the board).

VR CRANK go through the main connector too, it share pin with the HALL CRANK sensor but they use different internal signal conditioning and is connected to different CAP pins on the MCU to allow the choice to be made in software.

It's a waste of pins to have separate VR and HALL-level inputs. (although it is possible to use HALL-input as a general digital input pin).

For example CAP 0.0 is available on several pins! We can probably find a CAP channel where we can connect HALL and VR CRANK to different pins but same channel.

About trigger pullup options:

Thanx for applying it, looks great. Btw., the whole thing, so far.


Powerful logic chips driving the gates see VemsFrontier/ArmEfi/FetDrive





Layout Notes

ECIII 36 pin mapping: - for armufo

'''Main connector:'''
Trigger: 3
Hall 5V supply (also used for TPS and MAP)

Sensors: 10
CLT, IAT, TPS, MAP, Spare 5
WBo2 5  (4 would be enough) Nope, this board use the Rcal and need 5 wires minimum for WBo2.

Outputs: 20 
INJ (HW-PWM capability) 8
stepper pushpull #4
Ign/Misc (high voltage and current) 4
Idle/misc 1 DPAK
Fuel pump 1 DPAK.
Variable intake 1 DPAK
Boost solenoid 1 DPAK
All outputs feature flyback, including ign (SMB diode population optional at assembly)

Power_gnd 1
GND 1: also ground for sensors and triggers
Switched_Power 1  TODO: elaborate
Vbatt 1 Solves a lot.  TODO: elaborate
Flyback Internal?


'''Not on EC36!'''
RS232:0 (2)
CAN: 0 (2)

VR inputs:

Standard DB-9 CAN connector (two of these) Probably only headers on the board

Autronic compatible plug

Knock sensor: