From Newsgroup: comp.arch.embedded
On 4/10/2023 11:46 PM, pozz wrote:
Ok, now suppose you would like to work in SQI mode. During startup you send the
Enable SQI command over a single data line (MOSI). From now on, you can send SQI commands using 4 data lines even for command code byte (two clocks).
However you can't be sure at startup the Flash is in normal SPI mode. This happens when you power up the board, but it's not true when the MCU resets itself (for example, for watchdog).
This is the bane of all devices that have "modes"; how do you know that the
I/O pins that you've "programmed" to be outputs are actually outputs, NOW?
Or, that any device requiring a multicycle transaction is in the state
where it is expecting the first of those cycles to be issued, next, in time?
I've found it prudent to have an entry point in the code (called "RESET")
that is treated as an adjective and verb:
- the system is *in* the reset state
- reset the system *to* that state
This ensures that any assumptions one can make for a *device* coming out of (hardware) RESET apply any time the code executes from that point.
The device can reach that point:
- through the normal PoR process
- through a watchdog or other sentinel
- through a random crash
- as a result of panic()
I usually (start) write this as one of the first pieces of production
code as it gives me a chance to think about how the hardware "comes up"
(you have to think about EVERYTHING, not just the CPU/MCU itself) and
whether or not that can pose problems after deployment (e.g., what if
the motors aren't guaranteed to be stopped, at this point in time?)
It also gives you an idea of those parts of your hardware interface
that need to be atomic, accessed via monitors, etc. Esp if two
different active entities (e.g., two threads, a thread and an ISR, etc.)
can compete for the device "in some yet unforeseen scenario".
What could be the initialization process to bring the SPI Flash in SQI mode at
startup, without knowing if it is already in SQI mode or not?
Again, applies to every aspect of a system that has modes (embedded state).
You look at the device and posit the different possible "states" that
the interface may be in; then figure out which assumptions can allow you
to unambiguously drive the interface to a particular state from which
behavior is reliable. E.g., you may opt to put the device in the
"wrong" state (temporarily) if only because getting it *there* may be
easier to guarantee... then, deliberately transitioning from "there"
to wherever you'd ultimately like it to be.
E.g., multicycle interfaces often abort their sequences if a read occurs
when a write is expected (or, might be encountered). So, assuming a
read to be "safe" (for that particular device/situation), you do one or
more reads (discarding the data, if necessary) before you start the
multicycle *write* sequence.
Consider a video LUT. Often, you have to write the address of the
location of interest *within* the LUT to the device before you can
read or write. If you think the device is waiting for this "specify
address" portion of its interface cycle and send "0x44" to it
(because you want to access the 0x44th entry) but, instead, it was
already in the "address specified, waiting for read/write" mode,
then your 0x44 will clobber some "random" (as in, "location that you
can't predict" because you don't know what address had been specified
prior to your barging in on the interaction) location.
And, your subsequent "here's the data that I want to write" will,
instead, be interpreted as the next *address* that you want to access
thereby perpetuating the dyssynchrony.
OTOH, if you had done a *read* operation and knew that this would
reset the little state machine inside the LUT to "waiting for
next address", then that throw-away action can serve to get the
interface back into lock-step with the code (assuming you don't wedge
it later).
The pisser is that you have to come up with a strategy that will
work for any device that might be placed in that role (as the
design evolves).
I think the penalty of the first Quad mode respect the SQI mode is very small.
It all depends on your clock speeds, your mix of reads and writes, your wait
states, the length of your transfers, etc. If you are doing big transfers >> then there will be little difference since most clocks are data anyway. For
lots of small transfers with few wait states, SQI will make a bigger difference.
(And if you are doing big data transfers, you might also want to enable
double data rate on the pins, if your hardware supports it.)
What do you mean with DDR here?
Instead of a cycle being defined by a rising (falling) "clock" edge, it is defined by rising *and* falling edges. So, you get twice the throughput
for a given "cycle" (without having to double the "clock" frequency).
--- Synchronet 3.20a-Linux NewsLink 1.114