| ??? 02/10/07 08:07 Read: times |
#132459 - It looks as though you have some thinking to do. Responding to: ???'s previous message |
Mike Stegmaier said:
Richard Erlacher said: From reading all the replies to comments that you've made, that you have no oscilloscope, no logic analyzer, and no EPROM/EEPROM/PROM programmer. Do you have a multimeter? Do you have a reasonable supply of various logic components (74xxx-types)? What about passives (resistors, capacitors, inductors, etc.) and what about other semiconductors (transistors, diodes, etc.)? This question is important. Why do you ignore it? It appears that what you want is to get your 80C51 running as an 80C31, with your EEPROM as the program store and the SRAM as data memory. Further, you want to program the EEPROM from a PC's parallel port and subsequently run the programmed code on the 80C51. So what's wrong with programming the EEPROM from the parallel port, then subsequently using it from the 80C51? You've stated that you have an 805x assembler at your disposal. You've stated that you have already written code that runs properly on the 80C51BH that you have, despite the fact that you operated the device at 18.432 MHz rather than the 12MHz or less for which the part is specified. Why do you want to operate a system, not yet designed, at a frequency FAR outside the specified limits of the parts you're using? What makes you think you SHOULD do that? Why do you feel compelled to violate basic design rules? So, from where I sit, it looks as though you want to be able to compose and assemble code on your PC, download it to your 80C51BH, and execute it there. Is that right?
Yes So ... what would be wrong with designing a circuit that SHOULD work, i.e. one which is within specifications? Do you need an EEPROM programmer to program other EEPROMs? No, unless the other eeproms have the same chip number. You've already said you have several of the same EEPROM ... You said you have written an executed 805x code on that other system you built. How did you store the program there? I made a special eeprom programmer with a parallel port attachment, and downloaded code to it. Then I removed the eeprom from the socket, and then inserted it into the main system. I want to avoid constantly inserting and removing chips. 64 bytes is not a very big program. Are you sure that you can program an EEPROM with data from the PC's parallel port with only 64 bytes of code? The 64 bytes I am talking about is the maximum size of the code in the "hard-coded rom" that I want to make. The "hard-coded rom" made of logic gates will contain the code necessary for me to send data from the PC, through the parallel port to P1 of the microcontroller, and the INT lines. How do you conclude that 64 bytes is enough ROM space? Why use an external EEPROM? I want to increase flexibility. I have about 5 of the same eeprom, and if later on I decide to change eeproms in the same system, I can do it with ease. Think of the eeprom as an extremely reliable floppy disk, and the system as a floppy disk drive. How does that increase flexibility over programming the EEPROM differently? That seems like a pretty silly way to think of it, too, BTW. If you focus on getting your 80C5x to work, you can use a CF adapter and plug in cheap and ubiquitous Compact Flash modules of well over a GB (I've got one right here that's a GB in capacity). That's a lot better and quicker and more reliable than a floppy disk. Why use the parallel port? It is fast enough for my application, it has flexibility, and it is easy to use. I avoid any port that involves bit-for-bit processing like the serial port and USB port. I just want to send byte-for-byte. I don't want to convert bits to bytes, or I will introduce synchronization problems. Clearly, you've no idea how the serial ports work. Why build a ROM in discrete hardware? I want a system that is guaranteed to perform any useful function, whether it be the system waiting to be programmed, or whatever. If the eeproms were damaged, whether it be software or hardware, and I didn't have this hard-coded "ROM", then the system will be useless and possibly unpredictable. With the hardware rom onboard, I can be certain that my system will start up every single time. There will be also nothing that can corrupt the code, because it is "hardwired". It is valid for me to say that this "hardware rom" can contain bootloader code. Why am I willing to spend time, money, and other resources on this particular solution when, for just a few dollars, I can get a microcontroller that has internal program memory of 64KB, programmable through the serial port and is capable of supporting external SRAM if I want it?
Because I am willing to learn! Learn what? What are you going to learn from spending a few months constructing a ROM to do what a 50-cent PROM would do in 5 minutes? From this experience, I have already learned 1/2 of the quine mcclusky algorithm. ... but have you learned why one would use it? Have you learned what SOP and POS formats are? Have you learned why it matters? Why object to writing the assembled binary program to the SRAM, mapped, partially, into code space, and use that as program store in order to program the EEPROM? Because there isn't a direct way to do it synchronously? Synchonously with what? There's no synchronization issue when only the parallel port is writing to the SRAM, and, subsequently, there's no synchronizatin issue when only the MCU is reading from it. sure, I can steal the WR' pin for the port, but then I also must hog the address lines as well. and just how would that help? How would it even be involved? I have a RAM and an EEPROM. My current setup in the system is that the EEPROM is enabled and RAM is disabled when A15 is low. When A15 is high, the reverse is true. If you understood the 805x architecture sufficiently, you'd know you don't have to do that. The code-space, in EEPROM, is enabled by the nPSEN strobe, while nRD or nWR select the SRAM. That way, if you evere decide to put in a 64 kB SRAM, you can do it. It's necessary to modify the standar hardware configuration in order to map a memory into both code and data space. If your EEPROM exists in code space, then it can't be written to at all unless it's also mapped into data space. The 805x series uses different instructions for accessing the two spaces. Once you've downloaded the code, you can reconfigure the circuit automatically to provide the desired memory map. An EEPROM can be programmed piecewise, so you can download 2K or so at a time and program it, then use the same 2KB space to download the next 2KB segment. I don't know if I will do that. Why don't you address ALL the questions I've asked? To build a ROM of 64 bytes, assuming you make no mistakes, and will never have to change the 64 bytes, will take a minimum of one resistor and one Schottky diode per bit, and a considerable amount of SSI/MSI logic to decode and buffer it. The resistor is a pullup and the diode determines the sense of the bit. Each bit has to be made part of a byte, and that's the role of a tristate buffer. The diodes are driven by a decoder which supplies a pulldown path to GND. I think, on average, it will occupy 1/2 square inch per byte if you're really meticulous about placing your diodes and resistors. You can, of course, use diode arrays and resistor packs, which will help conserve space. An equal area will be required for traces, however, so your ROM (512 bits) will probably occupy an area about 8 inches square or larger. I just can't believe that you consider this more efficient and more effective than simply programming the EEPROM from the PC parallel port. The logic required to program an EEPROM from the parallel port is relatively cheap, perhaps as much as $5 US and probably considerably less, perhaps more like $2 US, given that an oscillator of some sort is already required for the MCU (You can buffer X2 and use it to drive something else). Do you know the voltage and timing requirements for programming the EEPROM you intend to use? Is it fast enough to work with your MCU at the rate at which you intend to operate it? What about the SRAM? RE |
