Well, for one thing, we aren't sure (or at least I'm not sure) that the Op's application uses files in increments of 16 bits. Maybe this is download to an 8-bit uP? I was not very well spoken. I was looking at some solutions that generated a 16 bit checksum but were processing the data 16 bits at a time. I think here, sum should be 16 bit value, but each addition to that sum should be only 8 bits. Code should allow an odd number of bytes, 51 or whatever.

I agree that there appear to be plenty of workable solutions presented in this thread. Even this byte by byte stuff will work if you don't have to do it very often and how long it takes doesn't really matter.

Update: A few comments about buffer size... Bigger is not always "better". In my experience, increasing the buf size will have an effect up until a certain point. After that point, no gain is apparent. I recommend increments of 4K bytes (4096) because that is likely to be a "unit" that the file system deals with most naturally (as explained above). I suspect that the "sweet spot" in terms of buff size is likely to be 16 or 32 Kbytes. Typically going way bigger than that won't hurt, but it won't help either. When I really care, I make buffSize a variable and do some benchmarking. My advice is the result of my benchmarking experience on the O/S'es and systems that I commonly use - mileage certainly does vary. My point is: Bigger is not always "better". Note that with a truly huge buffer size, it is possible to have a dramatic slowdown if using such a large buffer causes swapping back and forth to the disk.