Purpose

The intent of this project is to read and display automotive fuel injection pulse widths on individual cylinders, up to 8. The expected range of the length of the pulse width's is from 1ms to around 100ms worst case under Wide Open Throttle. Observations will have to be made after the initial part of this project is complete, in order to determine not only the pulse width, but the final resolution of the binary digital counters. These variables are only known to the creator of the original, proprietary board, and whether to increase resolution of the counters to 16 bits, will be determined later. It is desired that this project have greater resolution than the system being observed, for greater control purposes.


Other Inputs

The previous paragraph describes the primary data that will be measured, namely fuel injector pulse width, as it will show the 'flow' of fuel at any given point in time. Other sensors must be observed. First and most importantly, the Throttle Position Sensor, along with the Coolant Temp Sensor, are expected to have the most effect on fuel injector pulse width. Other critical inputs which need consideration are: the Crankshaft Position Sensor, Camshaft Position Sensor, Mass Air Flow Sensor and/or Manifold Air Pressure sensors. Vehicle speed must be measured as well, along with Air Temp. Pre-Catalyst O2 sensor/s will be observed as well as post Catalyst. Post Catalyst sensor info will be observed only for simulation, for reasons to be explained later.

A MUX'd 8-bit A/D Converter is planned for reading the following: TPS, CTS, MAF/MAP, Air Temp, and Pre/Post? O2 sensors. 74HC4050 logic level converters will be used to translate to following sensors from automotive 12-15VDC to LVTTL 3.3VDC: Cam Sensor, Crank Sensor, and Injectors.

Edit: Re-Edited to further clarify

Here's the Address Decode. i think I have it correct.

What do you plan to do with the I/O select lines? With three HCT138's in a row, you could have nearly 100ns propagation delay at room temperature, and more if you run it in a hot engine environment. You're not guaranteed to be able to reach more than about 7MHz with that, and that's if your I/O ICs are simple quick latches. If you use 65c22's for I/O, you can get away with a single 74xx00 and no more than two gates' delay for all your address decoding for as many as ten 65c22's. See http://www.6502.org/users/garth/project ... chematic=2

It's why i am using phase 2 clock to do the adress enable down to the last logic circuit. It has worked for me in the past.

The I/O select lines will enable reading fom the tri state latches,8 bit counters, and 8 bit ADC's. All have tri-state outputs... I dont like using 3 gates in a row for address decoding either, but I think the phase 2 high will keep them in order. I'll have another schematic soon for the data acquisition section.

I missed that. In that case, it will slow you down even more, because you can't start the chain until phase 2 goes up. You could at least leave phase 2 off of the first '138.

A 154 is faster tha two 138's in series, and gives you 16 outputs.

ROM enable does not need to be gated by phase 2, but SRAM enable must be.

As much as I hate to say it, seems like a lot of work for something that could probably be done with a couple of Microchip 18F PICs and some I2C temperature sensors.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I'm gonna take that suggestion and use 2 154's...



You're probably right, I wish I knew more about PIC's, but I like the flexibility of software and I know the language of the 6502.

BTW, I see errors on that schematic, so disregard that

What I like about the PICs is that there's so much I/O and processor support all on one IC, and there are tons of versions in stock at lots of distributors, and they're cheap.

What I hate about the PICs is their processor. The 6502 and '816 are way ahead in that regard.

I was thinking as I was doing the new memory decoding logic, that it would be nice to use an 64Kx8 EEPROM for addressing functions. So you could program your data out for each 16 bit address. A 64Kx16 would be ferfect but at such a misuse of memory, but I would already have the programmer. I know what you're thinking Garth: too much prop delay. Maybe I can find a fast 64Kx16 EEPROM... Maybe a 64Kx4, still thinking how this would work.....

I think bitwise's suggestion to use PIC's for the whole project is not what I am looking for, however, it may be the answer to what I need for address decoding. Something similar to a programmable logic array. I'm looking to learn and progress from what I did 10 years ago, but the bad thing here is that I need to spend more money on another programmer.

Unfortunately using the PIC as programmable logic is way, way too slow. At 14MHz, a phase-2 high time is about 35ns. A PIC running at 20MHz needs 200ns for a single instruction. An SX at 75MHz and true single-cycle instructions can get less than three instructions done in 35ns, which is still not nearly fast enough. Even 500MHz (five instructions in 10ns) would not be enough. For the ROM, since you can get it going before phase 2 goes up, you would almost be able to get away with a 45ns ROM with super-fast address decoding. Otherwise it will have to be faster. RAM definitely has to be faster, but much faster RAM is available, so that part is not a problem.

What kind of A/D converter do you plan to use? The MAX153 half-flash can be read like a memory location at 1MHz, but not 14. I have a MAX153 connected through a 65c22 since my clock rate is 5MHz.

Oh I hear you dude. upload the matrix from OS EEPROM to the memory decode RAM. How sweet, but the chipcount on MUXin the address and data of the RAM, is it worth a try? I am thinking yes, especially if you could have a dynamic memory decode which would change under certain conditions.

One question though since I am planning to run the CPU at full speed 14 MHz. How much of a prop delay is acceptable for memory mapping logic?

Two thoughts here:
One: The Atmel AVR's instruction set is very similar to 6502, and easy to pick up. They are not as widespread as the PIC's, but their costs are also not very high. You can contact me off-list if you would like more info on them.

Two:
My $50 programmer I got on ebay 4 yrs ago can do EPROM, EEPROM, and the basic GAL16V8 and 22V10's. I had trouble with a few subtypes, but was able to do Lattice 16V8D's. The CPLD software is free and I can send you a few source files I created for decoding a simple 65C02 system (we started about a year or more ago to come up with a simple entry level machine for new folks to break into on. I had wanted to use the 16V8's to handle the device decoding.) Anyhow, if you are interested, check the details on the programmers you are researching to see if they support these basic GAL's.

Daryl

I'm planning on using the same ADC I used 10 years ago, an ADC0820. It is half flash, half successive approximation like your Maxim, 'cept it's made by TI, TLC0820. Price is about 1/5 of what it used to be. Only $3 from Mouser...
I've overclocked MOS6502's rated at 1MHz to 4MHz. But I am anticipating problems going for the full speed of the new 65c02's from what you've said so far. Maybe I should reconsider using F series of TTL eh? Or just start out at 5MHz and make necessary adjustments as I increase speed.

Def interested, especially if the programmer is only $50. I will check your sugg's out. Who do you like as a distributor besides ebay?