| ??? 02/06/07 19:51 Read: times |
#132158 - There may be some surprises ... Responding to: ???'s previous message |
Mike Stegmaier said:
Richard Erlacher said:
You're taking risks that aren't warranted. ok The "popular" rate for crystals attached to the 805x 12-clockers of that era is 11.0592 Mhz.
Thats ok. But 18.432Mhz works for me. Just how certain are you that it "works" at all? How do you verify that it works correctly? Do you have an 80C51-BH1? If not, as I said, you're investing in something that's likely to be doomed. No, but I have an 80C51-BH ... which isn't specified for operation above 12 MHz. If they produced parts capable of 10.432 MHz, which was, in that was supposed to be 18.432 MHz ... <sigh>... I missed it ... the '70's, a very popular and ubiquitous crystal, don't you think they'd have said so? If they cut off the allowable frequency for that 80C51-BH1 at 16 MHz, don't you think they knew that 18.432MHz would have been advantageous to advertise?
It is worth experimenting. Sometimes you just have to go by your own instincts instead of datasheets. As for lowering the crystal, I might have to do it, just so that I can make WR low long enough when writing to the eeprom. No! You haven't any instincts in this regard, nor has anyone else. I'd suggest you wire this circuit up in some form over which you have more control than with a made-in-the-kitchen PCB. You could wire-wrap it, or, as many people do, point-to-point solder the connections. There aren't that many of them, and that way you can fix mistakes, if there are any. I'm not concerned with issues associated with getting your MCU to run, though you probably should be. If you don't concern yourself with adhering to specified operating conditions, e.g. voltage, clock frequency, circuit configuration, etc, you're running the risk of ending up with a circuit that won't work because it's designed incorrectly. The only thing may be the clock. but I did a design before with the same chip, and it worked. Just what do you mean by "worked?" What you've proposed to do is NOT an easy thing, i.e. synchronizing two asynchronous events in such a way as to produce a glitch-free output suitable for use as the MCU oscillator input. Not quite... You CANNOT use a crystal attached to the MCU to do what you propose.
I don't intend to do that. The crystal oscillator starts and stops at a widely variable rate, not readily predictable, and very dependent on the power supply behavior.
Could you be more specific (post a schematic) about how you intend to interface your SPP to the 80C51, running in 80C31 mode, in such a way that it allows you to jam code into the MCU during its nPSEN cycle. This was common practice in the early days of microcomputers, but those had a "wait" line which made it easy. For an 805x-type, I'd presume you have to register the code byte, set a flipflop that says there's a code byte available, thereby allowing the at that point frozen oscillator to progress and use nPSEN to enable the registered data byte onto the 80C51 data bus. Quite simple. I can explain without a schematic. My circuit consists of a 74HC107 flipflop with two inputs from a nand gate connected to Q' and Clear. J is connected to VCC, K is connected to Ground, and Clock is connected to the LPT port. When this pin rises high, then it indicates that the current data should be processed. PSEN' also connects to the Clear pin, and the 74HC245 buffer enable pin. The output of the nand gate connects to another nand gate input. the other input is tied to the output through a crystal. this nand gate basically controls whether the oscillator is enabled or not. A logic low means it is disabled. Here is how it works. First, the parallel port Data is initialized to all zero's. Then as soon as the power starts, PSEN' will go high, and the clock freezes. In Logic terms, Q' is high, and PSEN' is high. This makes the first nand gate's output low, which is also the second Nand gate's input. Therefore, the clock is disabled. Because the buffers require the enable pin to be low, it is disabled, and data won't enter the system. This will give me time to prepare a byte, so that it will be the same during the entire PSEN low cycle. Then I lower the clock input on the flipflop so that data can be processed. At this point, Q' goes low, (because J is tied high) This enables the clock, because the nand output is high, and the clock functions. So everything that the CPU needs to do is processed until PSEN' goes low. At this point, Clear is activated, and makes Q' high again. The clock is still activated because both inputs to the first gate are not 1. (psen' is low). Now, as soon as PSEN' turns high, the clock freezes again, and will continue to freeze until clock goes high, then goes low (through LPT port control) All in all, that's not a terrible problem, BUT, I'm curious why you'd choose to do things in this way. I'm willing to learn, I like flexibility, and i also like to see what I am doing. In Other Words, It would be nice for me to see an LCD indicating my code uploading progress, and using that same LCD in my code. Why do you need to do thta? What system requirement imposes such restrictions on you? My issue is that I have to have data ready before PSEN' goes low every time. If I have it too late, then I run into problems. I'm better to use my circuit so that any computer system can program it without error. Why do you want to use the parallel port (not that there is any reason why you shouldn't)? Is there some goal/purpose that you've not yet mentioned? The parallel port is the easiest way to transfer a byte from the computer to the outside world. I want an easy way to program my EEPROM in my system, so I will use the parallel port. If I used USB or serial, then I have to deal with timing and data synchronization issues. My schematic is here: or go to: http://rootshell.be/~mik3ca/pgmr.gif The top right wire as explained is connected to PSEN' and 74HC245 latch enable. This latch enable controls whether or not the system accepts the parallel port data. The left-most wire is connected to X1 of the CPU since this is an external clock to it. "Cont" represents "continue" and is connected to a port pin. I'm going to try the "strobe" pin so that I can use ANY application to send data to the printer. I attached a resistor, because sometimes the parallel port will be disconnected from the system, and I don't want the clock to go low at the wrong time. There are some basic elements that you haven't yet worked out. (1) How long, after the "READY" signal goes high, does it take the crystal to start oscillating again, after you've stopped it with the low input to that NAND gate? In what phase do you suppose it will finally be recognized by the MCU? What impact will starting and stopping, which happens very gradually) the oscillator, have on the MCU's operation? Oscillators of this type take multiple milliseconds to start, and vary considerably. How long, to the nearest nanosecond or two, does this one take? How long will it take next time? Once you realize that you've introduced an entirely random variable, namely the start-time of the crystal oscillator, you'll see that this isn't likely to work in a predictable way. I'd suggest you reconsider this part of the circuit, using a more controllable oscillator instead, one that keeps on running. As it stands, I can't help you, as you're hanging your hat, so to speak, on a completely random event. There are ways of doing this without starting/stopping the crystal oscillator. You can simply gate the oscillator, synchronously with the oscillator, so that its output to the MCU is always in a known phase and of a closely controlled minimal pulse width as set forth in the datasheet. You must never, Never, NEVER operate a device outside its specified limits, else you're on your own and will get no sympathy from anyone if your circuit fails, which it most likely will. If you want to operate at a higher frequency than the 12 MHz for which your MCU is designed and specified, you should obtain a faster MCU. OTOH, crystals aren't expensive. Packaged oscillators aren't difficult to use either. I've made my own for prototypes, etc, using a 74xx04 IC with a 1K 0805 resistor soldered between pins 13 and 12, and between 11 and 10, and an0805 cap, on the order of 150 pf, soldered between pins 12 and 11. It doesn't seem to matter whether I use an LS04 or an AC04, or anything in between, they always start and always run. In order to make 'em pin-compatible with "canned" oscillators, I use the inverter at pin 9 to buffer the oscillator, and that puts the output on pin 8, where it is on the canned part. You can safely gate this oscillator to the MCU without worrying about start-stop times, since it goes on running. You have access to both phases, thanks to the buffered output. One word of caution ... You really shouldn't attempt to control the output of your oscillator circuit with asynchronous inputs. The MCU is a synchronous circuit. The oscillator must be controlled synchronously. While you're free to operate the oscillator at any rate within the MCU's specified limits, you should never allow the oscillator input to "see" a pulse shorter than what's specified. Just to help you along ... consider the following. A latch is formed when an OR is fed with its own output. Once true, this can no longer go false. If you AND two signals, one of which is the OR's output, then, so long as the "other" AND input is true, the output will remain true. If one of those is your oscillator, then it will remain true as long as your external and potentially asynchronous control is true. If that latched output is registered through a 'D' flipflop with the oscillator as its clock, then it won't be fed back except in synchronization with the oscillator, hence, it won't change, except in synchronization with the oscillator and in the true phase, as it is clocked on the positive edge of the oscillator. That will enable you to construct a circuit, the output of which will always change on the positive cycle of the oscillator, and which will always stop, and therefore start, in a known phase, never producing an output pulse shorter than the oscillator cycle. RE |
