| ??? 02/06/07 14:16 Read: times |
#132129 - answer. Responding to: ???'s previous message |
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. 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 If they produced parts capable of 10.432 MHz, which was, in 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. 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. 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 discoonnected from the system, and I don't want the clock to go low at the wrong time. |
