VemsFrontier/ArmEfi (2005-05-21 17:38:24)

ARM based EFI: - developer info!

This is the primary fuel injection system, not as fully featured as the V3 but smaller and able to communicate with the other VEMSFrontier boards

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:

http://www.semiconductors.philips.com/acrobat/literature/9397/75013968.pdf

User manual May 3rd 2004:

http://www.semiconductors.philips.com/acrobat/usermanuals/UM_LPC21XX_LPC22XX_2.pdf

Errata:

April 1st 2005:

http://www.semiconductors.philips.com/acrobat/erratasheets/2292_2.pdf

http://www.semiconductors.philips.com/acrobat/erratasheets/2294_2.pdf

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

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.

Amplifiers


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


Locking:

Locked: armefi_r042_bm.zip

Connecting A3 chip

TODO:

Done:

Layout Notes


ECIII 36 pin mapping:\n

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

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:4
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?

-----
37pins!!!

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

VR inputs:
1 X BNC for CRANK

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

RS232:
Autronic compatible plug

Knock sensor:
BNC