GARTHWILSON wrote:
Remember also that aluminum electrolytic capacitors typically have a wide tolerance, like -20% to +80%. They're not terribly good for controlling timing.
In timing-critical applications that require integral microfarad values, I tend to gravitate toward tantalums. More cost, but generally better tolerances and less leakage.
Regardless of what you use, that cap on the EPROM's /OE line is not going to work for you. EPROM manufacturers do not guarantee proper operation if the rise and fall times on control inputs are not met. The /OE line will be seeing a very lazy rise in voltage, and it's a certainty that the EPROM will get confused as the voltage (lazily) crosses through the logic threshold.
One possibility if you want to delay the release of the EPROM's /OE line is to use a comparator as a timer. Output transition speed on an LM393 should be sufficiently fast to assure the EPROM knows when the state of /OE changes. That said, I think I'd investigate a different way to map the EPROM out after the code has been downloaded.
Quote:
Get rid of the 74LS and use 74HC or AC.
74AC or 74ABT is best. As Garth pointed out, you get the speed of 74F logic but with much lower input drive requirements and better noise immunity.
Quote:
I also don't think a second reset of the µP is really what you want.
If the MPU starts out by copying the EPROM to RAM, add code at the end to map out the EPROM and expose the RAM, at which point code in the ROM that had already been copied to RAM would redirect the MPU to wherever you want it to go. All that's needed is a little planning.
BTW, all control of your SRAM should be initiated with /CE, and /OE should be separately controlled according to the current MPU operation. /CE should be asserted/de-asserted according to the state of A0-A15, but the state of /OE should be qualified by R/W. Although the truth tables for a lot of SRAMs say /OE is a "don't care" when writing to the SRAM, prudence says do not assert /OE on a write cycle. I used that logic model in my POC and it works like a charm.
Further to controlling your SRAM, you should to qualify the SRAM's /WE with Ø2. Your circuit shows /WE being directly driven by the MPU's R/W line. The problem with doing so is R/W changes state while the address bus is in transition. This could cause a wild write to SRAM, corrupting data. You need to insert logic to assert /WE only when R/W is low and Ø2 is high.