> I see, do we have numbers > though? Isn't the spi I/O actually the > slowest part?
Good point :-) I had been thinking about that part of the fat lib with PATA in mind, where data is transferred in parallel and two bytes are read within six or seven processor cycles. When SPI is used, things could be significantly sped up by not using a generic "read and write" procedure, but a read-only-procedure. The read-and-write-procedure is called, transfers the "write" data, and waits until the "read" data is ready. As it is only dummy data that is transfered while reading from the SD card, there would be no need to wait for the data transfer. About eight processor cycles per byte are to be saved like that, and those cycles could make up for the variable indexing. If the read-only-procedure would be inlined, even more cycles would be saved, and that read-only-procedure would be very small, so that should not cost much program data. The real problem IMO is, that the fat lib would have to make a difference on what storage backend it is run then. Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
