2011/4/21 mattschinkel <[email protected]> > > But you can actually read byte-by-byte, using sd_data_byte pseudo-var ? > You > > don't necessarily have to deal with a 512-bytes buffer. > > Yes, you can maybe read byte-by-byte, but you can't write byte-by- > byte. You have to write the entire block. >
OK > > > ... this means sd_card is "infected" (no offense :)) with FAT32 concerns. > > Not a big deal in this case (start at 0, assume next is at 512), because > > filesystems blocks are mutiple of 512. But if there's something more > > FAT32-specific, it should be removed to be as generic as possible, so > other > > can build on top of it without finding weird workaround. AFAIK there's > > currently no such case ! > > If you want, we can add some user constants and improve the lib. > As far I can see, and now that I better understand, I don't see such need anymore... > > Maybe this: > address = address * 512 > > can be changed to this: > address = address * SD_BLOCK_SIZE > ... though using SD_BLOCK_SIZE instead of hard-coded 512 is always a good idea :) This leaves room for easy experiments about this parameter. > Is there a need for block size to be variable? Is there a need for > blocks to not start at byte 0? > No, I'd say there's no need not to start at 0, if you're using a "standard" filesystem (I mean FS using mutliple of 512) > > Adding this feature may be desirable (with warning about HC cards). Do > you also wish that fat32 could use smaller blocks? > No, and I'm not sure what would be the benefit ? Cheers, Seb -- 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.
