On 06.01.2008 05:52, ron minnich wrote:
On Jan 5, 2008 5:11 PM, Peter Stuge peter@stuge.se wrote:
On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote:
NOT finding a file should be efficient.
Yes.
Where do the delay come from? Can anyone measure the LPC?
I will try to measure for you but remember it is running uncached. Each and every access is a full LPC cycle, which is not really fast.
IIRC the PCEngines alix.1c has parallel flash, so the following does not apply to our current problem.
However, for all boards with LPC-to-SPI translation through a IT8716F Super I/O chip, the following applies: My calculations suggest that for optimal reads (4 bytes at a 4 byte boundary) with the IT8716F SPI translation function, we need (1 byte opcode + 3 bytes addr + 4 bytes data)* 8 = 64 clock cycles on the SPI bus alone. With a maximum of 33 MHz for the SPI clock on that particular chip (MUST verify that the chip is set to 33 MHz and not 16 MHz!), this optimal read takes 2 usec. Smaller reads take at least 1.25 usec. On top of the pure SPI bus time we have to add the time to transmit and receive that data over LPC. In case we don't use the automatic LPC-to-SPI translation and use the embedded SPI controller directly, the LPC overhead is replaced by 6+ ISA port byte reads and 5 ISA port byte writes, which is probably even slower.
Regards, Carl-Daniel