??? 12/15/06 18:00 Modified: 12/15/06 18:02 Read: times |
#129564 - I doubt there\'s a special mode involved Responding to: ???'s previous message |
Yes, I know about the ONCE mode for the ICE, but there's no reason to suspect there's any such "mode" involved. I found that I had a box of these, apparently purchased back in the '80's, with 8 MCU's per rail, and about 20 rails. Since this forum has amply demonstrated the unreliability of the FLASH-based parts, (I don't think there's ever been a day on which there wasn't an active thread dealing with some aspect of programming, flash corruption, etc. in the years I've watched this forum) and the fact that the FLASH-based parts require external reset chips, etc, I'm just thinking it would be beneficial to use these old parts if there's an appropriate application for them, as opposed, simply, to throwing them away. They do apparently allow simpler application than the new flash-based ones. These parts predate the era of "reset chips" and ISP since they use EPROM rather than FLASH. Most applications don't require ISP, and once programmed, it shouldn't matter whether the code space is FLASH or EPROM.
I was just curious how they'd work in this current device I'm working on, and encountered this peculiar behavior. Since both the AMD and the Intel parts exhibit this behavior, I'm curious what the cause might be. The MCU for which the circuit was intended is the DS89C4x0, operating either with internal or external code memory, but with external data memory. Additional I/O will be added later, but the required decoding logic is not yet present, as it will likely be in programmable logic. I was curious how the old HMOS parts would work in the more modern application, so I plugged one in. I was surprised at the result, as it's really a "stock" application circuit, similar in most respects (aside from the external oscillator) to what people have been using for decades, to find that the HMOS parts, some from Intel and some from AMD, behave similarly, in this peculiar way. It's not what I expected. My interest was in the waveforms the generate and not in the heat. Since the code requirement is small, but the data space must be large, I've used a combined memory map, i.e. I've combined nPSEN and nRD into a single output enable to the external memory, and use a BBRAM for half the memory space. The other half is just an SRAM. There are three 'AC573 sites, of which two are populated, one to demux P0, and the other to buffer P2. The third is used to demux P2 in Page Mode 1, but not in this instance. Aside from those two (The third latch is unpopulated) latches and the two memories no other hardware, aside from the oscillator and reset switch, along with its passives, are attached to the MCU. There are socketed pullups available for the P3 pins, but they're not present at the moment. What this all means is that there's no load on the MCU, so the heating is due to some internal circumstance. It would be interesting to know what causes this. I was, of course, thinking it would be worthwhile, just to p*ss Erik off, I'd put a few 8255's together with one of these, perhaps just to drive some LED's or something, maybe in a dot-matrix display of some sort, but that would have to wait. I guess I'm being punished for having such thoughts. RE |