The reason, why ALE should not be used as a standard clock signal, is that ALE can be unsanely noisy. In many datasheets you can read the following hint: "Capacitive loading on ports 0 and 2 may cause the VOH on ALE and !PSEN fall below the 0.9xVcc specification when the address bits are stabilizing." This means, that VOH can be superimposed by a negative glitch, which does not matter at all in combination with the 74373 transparent address latch, but very well with edge triggered flip-flops, which might be used when using ALE as an additional clock signal.

Also, using ALE as an additional clock signal mostly means to lead this line away from the micro, much farer away than when only feeding the 74373. This is an as bad idea as moving the clock lines away from the micro. When doing this without a multilayer board, heavy ground bounce and ground noise can be the consequence.

A third reason not to use ALE as a clock signal is the rather unpredictable performance of ALE, when having a micro providing extended internal RAM or internal EEPROM. These memories are mostly accessed by MOVX instructions and you can never know whether the actual mirco let one ALE skip or not. This is not only a problem with Atmel, but with some other manufaturers too.


Tolerance specifications of Vcc do only refer to the DC value, but not to noise! Noise on Vcc must be as little as physically doable. Means, the manufacturer assumes a well regulated 5V supply, the use of local decoupling caps (mostly 100nF), the latest printed circuit board technology, which is multilayer today (!) and, of course, the absence of any additional noise. Only the noise the micro is producing by itself is allowed.

Alien noise spikes of 500mVpp are not at all allowed!

Flash micros (not only Atmel's) are especially susceptible to noise on Vcc, because sophisticated internal routines are running at certain moments, which can easily be interfered by noise on Vcc or which can unintentionally be invoked by Vcc noise at a wrong moment. So, it's reported in literature that noise on Vcc can cause the internal falsh burn or flash erase routines to start at any moment, which will result in a destroyed code memory!

All these issues are not neccessarily mentioned in the datasheet, but you will find them when reading the many application notes Atmel and other manufacturers have published.


Jan, not so fast. Many of the actual bugs are a consequence of the original Intel's 8051 design. The vulnerability of this micro to improper reset, Vcc noise, capacitve loading on port lines and Vcc power-up rise time are direct consequences of the orignal design. There were hundreds of errata in the past which addressed these issues. Most of these errata were published by Intel itself, Philips, Temic, etc., at a time when Atmel didn't even exist.


Really?? I found nearly as many errata for AVRs and PICs as for 8051 micros. Infact, I once intended to use a PIC but kept my fingers off, because the datasheet missed many many important details and the errata read like a horror story. And with an ATMEGA we had severe problems with the internal POR some months ago...

By the way, I wouldn't take this AT89S8253 either. Alone the oscillator is an impertinence. And I cannot understand, why people take an immature micro. Jan, I didn't say that the AT89S8253 is free of bugs. Only that the reported "bugs" by Daniel not neccessarily must be actual bugs. And what he wrote about the noisy switcher makes be believe, that most, if not all, of the reported "bugs" are the consequence of an improper design (circuit, layout, supply).


Kai