Good presentation and walk-thru. The slides, especially diagrams and use of coloring along with the lecture are much better than reading an article or Comp. Sci. text and help greatly to supplement those.

gaun: yes, since it means more writes to the device it will result in more wear, but with proper wear leveling this shouldn't be a problem (SD cards implement wear leveling).

Diagnostics, if they are run everytime a card is inserted would mean that you'd have to wait several minutes each time, so I wouldn't run them everytime, if at all. With a journaled FAT, you wouldn't have to run diagnostics at all since it wouldn't be possible to corrupt the FAT metadata (which is what diagnostic tools check).

gaun: assuming you don't overwrite existing data and just append to a file, you should be fine if you're using a journaled FAT volume, assuming your backing device cannot replace an existing sector with unrelated garbage.

@gaun, Then I'd use the supercap to buffer the battery. If its critical, then go towards redundancy. If you're writing new data (new file), then I'm thinking you'll have a minimum of three sectors to right out to complete a file closure. All depends (as it so often does! :)

@Gaun I'd be afraid that a super cap wouldn't have enough storage capacity for a complete file update. My guess is you'd be better off using a battery, but a lot would depend on the file hardware you're interfacing to. I'm interfacing with SD card, and that's a lot of current at times.

gaun: I must admit that I'm not an expert with regards to hardware, but I suppose "a super capacitor or something" could help! The key is you need to be able to have a grace period where you're allowed to finish your ongoing FS operations.

gaun: FAT with a journaling module would be relatively safe, but you would have to implement something in your application to provide absolute data safety, if you're using a logical journal. Some other FS exist and provide more reliability than FAT at the cost of compatibility with major OSes, which might or not be a problem, depending on your application. I wouldn't recommend writing your own filesystem unless you have lots of spare time on your hands!

@eric: In your mitigation strategies for preventing corruption you had mentioned that a Brown voltage can be detected and data written to the disk. Should this be done using a backup power like a super capacitor or something?

jcabas: not very much, LFN entries have a checksum against their associated short file name in order to ensure they really belong to following normal directory entry, but there aren't any checksums on the FAT table. Some disk checking utilities will be able to detect some amount of corruption, however.

[QUESTION] Eric: In the case of FS corruption especially in medical devices I need to take care that the vital signs data is written correctly. In this even a detection of a corrupt filesystem is fine. Can this be ensured?

RMR: At the level of the filesystem, essentially all filesystems just act as though each file is a "bag of bytes". If there's any sort of record-oriented structure imposed on the file, it's imposed from a higher level than that of the filesystem.

Eric I am not currently doing file work but if I were, as you say it would depend on the application. Having said that most work I do involves relatively small data rates so efficiency would be a priority.

Kentj: I mentioned this yesterday but one thing to be careful of is that not all USB sticks actually flush everything out to the underlying Flash Drive in a predictable amount of time. We saw some that didn't flush until another write came along and pushed things through, seemingly no matter how long you waited!

@Atlant, Yes I agree. FOr instance, we have a fixed file name that we respond to. Simplified a lot of code. We don't use long file names. Removed a ton more. Don't need to create a directory, just update, Etc Etc.

In my project I want to make as much as possible automatic, but it looks like I will have to have the user push a button and watch an LED change from red to green so they know when to take the flash drive out.

@Atlant I was going for the smallest code size possible. Thus the path I took. I did investigate a whole bunch of different implementations including the linux open source examples. Most were overly complicated for what I needed, or used too much address math instead of simple structures and pointers, for me to wrap my feeble mind around. Chan did a good job on his code.

@Kenj Yes, I've trained assemblers too, and it might be the interest level that helps. Sometimes I'll be talking to an installer. Some of these guys don't realize that you can buy screwdrivers that have blade widths less than a half inch. When it comes to computer literacy to the level of reformating an SD card, it was just an issue. So to make the product as user friendly as possible....

@gaun There's a lot to consider to implement from scratch. That'd be tough IMO. I started with a copy of CHan's system (one of the best written IMO) then stripped out what I didn't need, and added the functions I needed to interface on the level I needed.

gaun: A lot depends on how "high fidelity" you want your implementation to be. Writing (Creating) a valid (readable) FAT32 volume can be a lot easier than being able to read every possible FAT32 volume in the world.

Kentj: There are limits to both aspects (the size of individual files and the size of the overall device). The biggest single factor in both is the "cluster size" for the device. Search the slide deck(s) for that term.

@Kentj Well, it could be that your Joe User is smarter than mine! :) THe people I sometimes deal with don't know how to insert the card right. I think of them as sales men! (which come to think about it, must of the one's I have trouble with are! :)

@Kentj Our application uses an SD card for customers to easily configure the product, and copy configurations between product (product is an HVAC thermostat). SD cards 2Gs and under are Fat16. I initially released with Fat16 only, but the smaller SD cards are getting tough to get in the field, thus the Fat 32.

I was trying to get 1M readings per second off of two 24-bit ADCs, and a 32 bit counter. But even after offloading the host communications from the PIC32 it looks like I'm going to have to settle for 500K

The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.

@erhk: I'm originally from Washington state but have been down here in Richmond, TX for almost a year. I'm still learning where everything is in relation to where I am. I have a grandson living in El Paso though.

Industrial workplaces are governed by OSHA rules, but this isn’t to say that rules are always followed. While injuries happen on production floors for a variety of reasons, of the top 10 OSHA rules that are most often ignored in industrial settings, two directly involve machine design: lockout/tagout procedures (LO/TO) and machine guarding.

Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.