CCS fat.c does it work or not?

[Douglas Kennedy]

They often say a project is a journey not a destination
The issue with the CCS fat.c is the failure to type cast.
There are a number of smaller errors I'll post them soon after I fully test the features.
Below is patched working code that still could use more mathematical consistency

[Douglas Kennedy]

As a retired mathematician I once oversaw hundreds of coders so I have some awareness of coders
Many know coders love to use pointers but pointers often have issues and often don't form what mathematicians would call an algebra. Fat32 is a labeling of the storage space it doesn't impose a metric. Labels are mbr, partition record, fat table, cluster number, file name tile etc. There is no metric just labels and relationships. Something like mbr is (a) partition record is (b). a<b is true in this algebra without having to apply any metric ( bits bytes words blocks etc.) It is true distance relative to storage memory may be quantized into bytes, words, double words or 512 byte blocks but the algebra shouldn't care. Labels have relations to each other in the algebra (the mbr is before the partition record ) but the physical distance is imposed by the card geometry; the algebra is independent.
The algebra t is like drawing points on a line but not placing a grid. The points are just labels that have relations with each other. When a label needs a metric a transform table should be used based on the cards physical geometry. This places the math notationally above the card geometry. Like as if SD cards are a rubber strip with labels (mbr etc)...they differ by the way the strip is stretched between the labels and the maximum stretch possible ( capacity). The relationship between the labels is conserved no matter how the strip is stretched.

Pointers impose a specific metric 8 bit jump for a byte 16 bit jump 2 etc. In places the pointer is even cast down ....I'm living with them for now in this CCS code.


The weakness of pointers is that they can point to unlabeled points that are meaningless in the algebra (Ex. like some meaningless location within in the mbr... the CCS code doesn't do this but it is a good example of the risk pointers impose) and it is the source of the bugs.
CCS did a good job of isolating (abstracting) the low level SPI card driver. Coders often do well with hardware abstraction.
Now luckily object programming is imposing an algebra on coders. Objects have relations with each other and the compiler decides the physical location of the object in the metric of the memory space.

Anyway with several patches I can read the contents of my files from my SD card which is all I need and keeps me on firm ground w.r.t. Microsoft patents ( my file creation ,writing etc. is done only with Microsoft licensed products). I know non lawyers have offered broader opinions on this issue. This CCS code maybe useable for others but it is non only for me partially useable. I would advise not to use this CCS code if an alternative is available.