Can we revisit again why the 50kHz clock is the minimum, im still not seeing why its the case? Now establishing that Counter output= (period of clk)*(counted pulses) , how does the PROM fit into getting us closer to measuring mph? I havent used a PROM before so i dont know how they work.
50KHz was only an example but served to demonstrate that you need a relatively fast count to be able to get enough resolution. Keeping it in perspective, for many applications 50KHz would be considered a snails pace. What you are trying to achieve is a usable number of counts within the 'window' between the start of one spark pulse and the start of the next. If you choose a low frequency, the count will be smaller, fewer of its cycles will pass through the window in a given time. Suppose you used a very low frequency, it would be quite possible that at high engine speeds where the window is short, no cycles pass through and you would get a completely wrong an nonsense measurment. As you increase the frequency, the number of cycles passing through the window for a given speed gets bigger. Your task is to display speed to one decimal place so you must choose a frequency that allows enough cycles to be counted to achieve that. As I said, it doesn't have to be 50KHz, that was just a nice round figure to use in the explanation, you can use a higher frequency than the minimum and get greater accuracy but the minimum is the frequency that allows enough pulses to be counted to get 0.1 resolution in the speed display. If we look at actual figures and assume from the specification that the biggest number you can display is 99.9 MPH the math works out as:
99.9MPH = 34.7 pulses per second = 0.029 Seconds 'window'.
You need to count at least 1 clock pulse in that period or you wont have taken a measurement at all. Given that the count could be +/- 1 anyway, depending on the alignment of the window and your clock pulse edge, it would be far safer to use say 10 times the lowest frequency to make the potential error smaller. Choosing 10 cycles count at 99.9MPH means 10 pulses pass through the window which is 0.029 Seconds wide so the frequency would be 347Hz.
At the other end of the spectrum, the lowest speed you would need to measure is 00.1MPH.
00.1MPH = 0.0347 pulses per second = 29.4 Seconds window.
Counting at the same 347Hz would allow the counter to reach 10,000 which is still a very easy number to work with.
I should point out that in a real life situation, the numbers give to you are somewhat silly because it makes no mention of the gearbox. The spark rate is proportional to engine speed, not road speed and ignoring the gearing means you would be expecting the engine to do less than 10RPM when driving slowly!
Back to the problem - you have a number in the counter which is proportional to the time between sparks. The number in itself is pretty much meaningless because it has no particular units, it's just a value proportional to your chosen clock frequency and inversely proportional to the engine speed. This is where the PROM (or EPROM) comes into play. Your clock frequency should be stable, how exactly you generate it is up to you but it must be assumed to be fairly accurate and consistent. The PROM is just a memory, it has address lines at one side and data lines at the other, when you put an address in, the data at the addressed location comes out on the data lines. In essence, it's a look-up table. So if you know the count value, you can feed it to the PROM address lines and use it to look up the corresponding MPH. From there, it's just a case of displaying it on the LEDs.
The reason I suggested two PROMs is this: You can get PROMS/EPROMs with enough address lines to take all the bits from your counter but the easily available types only have 8-bit data outputs. To simplify the LED display, it would be nice if you had 'easy to decode' 4-bit numbers for each of the three digits, you can then use a TTL driver like the 7447 to interface directly to the segments. That means you can drive two LEDs from one PROM, the third digit from the second PROM and still have four bits left over. That's nice and easy, the bonus is the second part of your task is also made simple. You have to operate an alarm system when the speed exceeds 60MPH and produce different tones as defined limits are exceeded. The PROM is already fed information from the counters about the speed and you have those four bits not being used by the display so why not use one to enable the alarm and the others to control the tone. It removes all the extra checking for the speed completely!
Brian.