It's *SO MUCH EASIER* using CKE!

Before: In order to read-back more than one port (8-bits) of data from a certain address, I had to perform a separate read-burst for each byte, even when all those bytes were presented to different ports on the AVR.

An alternative, used for reading back several addresses sequentially, was to perform a read-burst at the first address, then count exactly how many cycles occur between reading one port-value and the reading of the next...

So, e.g.

Say you wanted to read two bytes (attached to two ports on the AVR), and want to read those parallel bytes back from addresses 1-3

1. Start a read-burst at address 0 (zero for the first loop)
   
   1. (minus the known cycle-count between the read-strobe and the time it takes to switch the pins to inputs, etc. and read the first byte)
2. Switch those pins to inputs, etc.
3. Read the value on the port attached to the first byte
   1. (first loop: the first byte read from address 0 will be discarded in step 5)
   2. (later loops: the first byte read from addresses 1-3 will be kept in step 5)
4. Read the value on the port attached to the second byte
   
   1. ASSUMING your Port-Read -> Register instruction is a single clock-width, the second byte will be read-back from the *next* address-location.
   2. (early loops: The second byte will be kept in step 5. For the first loop, this will be from address 1)
   3. (last loop: The second byte will be discarded in step 5. This will be read from address 4)
5. Move those two read-bytes into your uC's internal memory-array
   1. Don't forget to discard those out-of-bounds reads!
   2. Don't do this between step 3 and 4! Otherwise, step-4's address will be offset!
6. Repeat 1-5, beginning the read-burst with addresses 1-3

The above *can't* be performed on a system where the *exact* number of CPU cycles between each step can't be controlled or otherwise determined. (e.g. if you're running an operating-system, or if there may be unexpected delays from caching, etc.)

With CKE it's as simple as:

1. Initiate a read-burst at address 1
   1. Leave that command/address on the port until after step 2
2. Pause the clock by disabling CKE
   1. The read-burst will be restarted one last time, at address 1, as CKE is registered low, and paused before the burst begins.
3. Switch the pins to inputs, etc.
4. Strobe the CKE pin a couple times for the CAS-Latency
5. Read back the first byte from the first port
6. Read back the second byte from the second port
7. Strobe CKE
8. repeat 5-7 for addresses 2 and 3.

Yes, regardless, both *are* a lot of software to do a simple read from an SDRAM..

The reason, again, is because of the intention to use Free-Running, wherein the SDRAM will eventually send commands to itself in realtime. In other words: it'll send its own read-burst commands *from* read-bursts. And, thus, the DQ (data) pins are *directly* wired to the command/address pins. Thus, executing a (burst) READ command and reading back a command stored in the SDRAM are two entirely different processes that require swapping the directions of the ports, and a few other things.

If the SDRAM were wired-up *without* intention to use Free-Running, it would be as simple as executing the read-burst on the command-pins, waiting for the CAS-Latency, then reading-back the value on the separate data-pins.