In my particular case, all I'm asking the MCU to do is to generate the addresses, sequentially, at 33.333 MHz. That's actually 0.1% above what the datasheet says it can do, but, what the hey!. I could use 33.00 MHz just as well. The cycle, actually, is 120 ns long, but the read or write is half that length, The RAM has a 55 ns access time, but I have to reduce a 16-bit word to two bytes, yet still "stuff" them into the RAM with a 5 ns CPLD. It all "just barely" meets the mark under worst-case conditions. I considered using a 60 ns external memory cycle and twice as many, but it's no easier.


That's what I was getting at. Doing these time-critical things is not so easy with low-end ARM's. The last one I used was an ARM9 at 100 MIPS. They aren't any easier just because they're faster. The 8-bitters are easier to use when you have to meet the mark in timing. The point, I guess, is that the 8-bitters are designed around the noiton that everything has to be synchronous, as it was with the old 8-bit microprocessor busses, while the 16-bitters operate with a more asynchronous bus, reminiscent of the '80's generation minicomputers. Once they start using a cache, and interrupts, everything goes to hell in a handcart with respect to event timing.


Yes, that's what I'm doing. Indeed, it could be done, provided its timing is totally synchronous, i.e. every external cycle is timed exactly the same and occurs predictably with respect to previous cycles.


That's why I have to "fiddle" with the system clock, too. The target peripheral has a 120 ns cycle time for reads and writes. The external bus cycle in "non-page-mode (the conventional 805x external bus access cycle) takes four clock ticks, which is already 120 ns. The bus cycle can take any (well, not quite any) multiple of 30 ns in PageMode1. In PageMode1 it muxes both high and low address on P2, while presenting data on P0. The MCU hardware can stretch a cycle. During ALE, it switches from what's in the P0 latch to the DPL content. However, one can register (with a '273-type construct) that P0 content at the rising edge of ALE, before it changes to the data (provided the required pullups are there, else the ones won't appear soon enough). You can then make use of the output port. That can provide high address bits if they're needed. That's part of the overhead I mentioned. Because the MOVX instruction consists of a fetch of the DPH content, which takes an extra clock cycle, the MUX switches back to port latch content during that extra (internal but actually occurring first) cycle. I have to fiddle with the external oscillator period because of the way in which the MCU handles its cycle-stretching so that the entire cycle still takes only 120 ns.

Most of this trickery wouldn't be so easy to implement with an ARM-core device because of variable internal latency. It would have been nearly impossible, had I needed the UART or timers. All the timing is synchronized by the execution time of the code.



The ARM is an excellent computing machine. It's not as easy to use as a hardware substitute, though. Clearly our "world views" differ with respect to the role of the MCU in a system design. However, I had the constraint, additionally, that the original system had a 40-pin DIL-packaged 8052 in it ... AFAIK, they haven't yet built an ARM-core MCU with 8052-compatible pinout. If they did, I'd find that really exciting!

I put the CPLD in this machine in '91. It had "room" to accomodate the additional features I needed, so that was just a design entry task. The original 8052 was replaced with a Dallas part in 2001 in order to take advantage of the extra RAM it had on-chip.

What interested me about this task was that I could add a huge additional capability to the system with very minimal changes to the architecture or, for that matter, the hardware. Adding the extra data channels involved just very little additional hardware, e.g. buffers, connectors and that sort of thing, and, with some imagination, I was able to make that fit on already present features.

RE