VemsFrontier/ArmEfi (2005-05-06 16:49:19)

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.


Size does matter

The 100mm wide U profile will probably let us use the same box for ION/CDI.


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

Let's 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).

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 (about 70 DIPs in stock, will go out with v3 easily; shouldn't be problem to get the SDS L293D in a reasonable time.). On v3 stepper is optional, so DIP was OK choice. This will be automated, so SMD is needed.


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, it has 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.


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. This suggests LPC2294 later, even though no need to stuff all 4 CAN transceivers onboard if it's hard.

I'm not sure there's a compelling reason for needing more lines. The only need for addition channels is to support different speed networks (eg 10Kbsp, 20Kbps, and 1Mbps), or maybe for an extreme level of redundancy (2x 1Mbps). If the cost diffrence (part + routing) is low then there's no obvious downside, but the benefits aren't that great either.

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


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_r039_kh.zip

some clean up

TODO:

Done:

Layout Notes


ECIII 36 pin mapping:\nÿ1ÿ