Flash operations can specify how long to wait before the next operation
is issued.
Prior to this the amount of time waited, and when, was wrong.
e.g.
m25p16_eraseCompletely - possibly waits ages TO START, starts, exit.
m25p16_pageProgramContinue - waits DEFAULT_TIMEOUT_MILLIS to START,
starts, exits.
m25p16_pageProgramContinue would fail to write to the flash as the
device was still busy erasing and didn't wait long enough.
what happens now is:
m25p16_eraseCompletely - waits using the current timeout, starts, sets
timeout to be `now + BULK_ERASE_TIMEOUT_MILLIS`, exits.
m25p16_pageProgramContinue - waits using the current
`BULK_ERASE_TIMEOUT_MILLIS`, starts, exists, sets timeout to be `now +
DEFAULT_TIMEOUT_MILLIS`.
Since the timeout is stored in the flashDevice_t the solution also works
for multi-die devices which use an instance of flashDevice_t for each
die.
- Update flash w25n01g driver to support QuadSPI.
- flash_m25p16 update for QuadSPI support
- w25m driver update for QuadSPI support
- Use 100Mhz (ULTRAFAST) clock for QuadSPI w25n01
- Conditionalize QUADSPI code in w25n01g driver
- Use handle instead of handle_u