The stretch cycle feature on these devices is indeed very useful, at least at a conceptual level. However, should you have a system with a variety of devices that you would like to operate each with different numbers of stretch cycles, the feature becomes cumbersome at best. Stretch cycles are controlled simply by writing the number of desired stretch cycles into a SFR. As a result, I have found that my peripheral drivers are peppered with preprocessor macros that insert the proper stretch cycle manipulation code, and thus, a few extra instructions end up getting added to just about every driver function. Take a look at my DS12887 driver as an example. This is quite unwelcome, both from the standpoint of coding complexity and added execution time.

What would be nicer, however, would be a hardware mechanism for mapping stretch cycle counts onto particular XDATA address ranges. Thus, whenever you make an external memory access to an address associated with a slow peripheral, the appropriate number of stetch cycles would automatically be used.


Yet they aren't. For whatever reason, they are very scarce in distribution, and Dallas itself often has often had large lead times when you try to order the product directly. I don't know what the issue is here, but Maxim/Dallas apparently has some odd production/distribution issues, not the least of which involves their shipments getting hijacked now and then.

The whole situation is really a shame. These devices are among a few examples of great products that Maxim/Dallas makes, yet logistics are getting in the way of making them viable solutions.


As for IAP in the '420, I never knew it supported that. I thought that was introduced in the '430, which was largely touted as an IAP-enabled version of the '420. Is it possible they tried to implement IAP in the '420, failed, and just quietly removed reference to it from the datasheet?

As for 50 MHz operation, what you are saying is not really that surprising. However, until Dallas certifies the device for 50 MHz operation, I am uninterested in it. The last headache I need is an added source of unreliablity because I am operating chips out of spec.

Also, I will note that interesting (by which I mean unpleasant) things happen with these devices when operated at high frequencies. It seems that they have some issues with the on-chip power distribution network, most notably in the form non-trivial resistance and inductance, which can manifest itself in the form of noise on ALE. The issue becomes exceptionally problematic when using a TTL-compatible latch, as I often do. The 74ABT573 is among a few that can meet the timing requirements of the DS89C4x0 operating at high frequencies with no stretch cycles. See the application note Microcontroller Design Guidelines for Reducing ALE Signal Noise for a more thorough treatment of this matter.


You might be running at "12x the 'normal' rate", but in reality, you can never realize a 12x performance increase by switching from a conventional architecture chip to this device. As you can see from the Ultra-High-Speed Flash Microcontroller User's Guide, in the subsection "Comparison To the 8051" beginning at the bottom of p. 52, for any given opcode, the DS89C4x0 offers performance advantage factor of significantly less than 12 for a large number of instructions and opcodes. The document mentions an average performance increase factor of 8.5 and 9.4 across all instructions and opcodes, respectively. However, neither of these numbers may be taken as an expected performance gain, as it is unrealistic to assume that each opcode or each instruction is used with the same frequency in a "real" application. Also, I believe this does not take into account the addition of any stretch cycles that may be needed, which would further reduce the performance benefit.

I will admit that one of the draws of the DS89C4x0 is the fact that it can literally drop into a legacy application by virtue of the fact that it is a pin-compatible replacement available in a variety of form factors, making it a viable choice for a retrofit of an old design. A lot of effort went into the design of this device to make sure that would be the case. That said, software delay loops have to be recoded accordingly, and the likely need for stretch cycles might somewhat limit performance increase.


I was originally scratching my head about why you were so interested in page mode. After all, the DS89C4x0 already has 1K of high speed internal SRAM mapped into the XDATA space, which would be of sufficient size to hold a nice chunk of data that you access most frequently. Tools like Keil's C51/LX51 make this easy. Not only does the facility offered allow confinement of veriables to a certain address range, but it avoids the necessity of absolute variable location declarations (e.g., with the _at_ keyword), but it allows the linker's overlay analysis to save you memory for local variables spread across multiple functions.

The use of these page modes has the further implication that interfacing to devices with internal address latches intended for 8051-interfacing, such as a DS12887 or 8155 (you shouldn't be using the latter anyways though), becomes trickier. In the end, that leaves the page modes really worthwhile only in a few select applcations where fast access to a large amount of memory is required.

However, my understanding now is that what you really want to do is equip your DS89C4x0 with a 12 MHz or so oscillator, start copying code out of your nonvolatile program store (whether onboard flash or otherwise) into fast SRAM mapped into the code space, and then begin executing out of the SRAM, where the first thing you do is throw on the internal clock quadrupler. That would be quite a lot of effort!

Don't get me wrong. I like the DS89C4x0 devices and use them regularly without difficulty. They are simply a bit quirky, admittedly though somewhat out of necessity to achieve what they do.

--Sasha Jevtic