Sebastian Biały pisze:

>> Sama obsługa FATu nie wprowadza żadnych działań blokujących (tzn.
>> pollingu / aktywnego oczekiwania na cośtam)
>
> Przy dwoch watkach piszących do różnych plików wymaga przynajmniej
> muteksowania na poziomie allokacji sektorów/blokow/clusterów. Moj
> multitasking jest preemptive więc takie problemy sa niestety do obejścia.

Eee tam, wystarczy założyć semafor na dostęp do całego systemu plików i
już po kłopocie. Czyli tylko jeden wątek w danej chwili będzie mógł
siedzieć w środku funkcji czytającej/piszącej/kasującej plik. To
upraszcza znacząco zarządzanie kontekstem systemu plików. Bo nawet przy
całkowicie równolegle działających funkcjach operacji na plikach i tak
musiałbyś poczekać na dostęp przez SPI (czyli udostępnienie innego
semafora).

>> czyli SPI realizuje operacje długotrwałe, wymagające poczekania na
>> odczyt danych czy skasowanie bloku. Jeżeli podczepisz swoją obsługę SPI
>> i wywłaszczanie (przy długotrwałych operacjach pamięciowych jak
>> poszukiwanie czegośtam w indeksach) to nie widzę problemu.
>
> Prawie wszystkie widziane przeze mnie FATy (i komunikacje po SPI) na uC
> były pisane kompletnie bez możliwości wzbogacenia ich o warstwe
> synchronizacji bo z definicji były jednowątkowe albo pracowały w jakimś
> cooperative multitaskingu. Dlatego bede zmuszony wynaleźć koło na nowo.

Po opakowaniu takiego najprostszego "jednowątkowego" systemu plików w
semafor otrzymujesz bardzo skuteczną synchronizację równoczesnych
dostępów do plików przez różne wątki. Jedynie trzeba uważać (we własnych
aplikacjach) aby nie robić zbyt dużych operacji naraz, np. zapisywać
wielomegowy plik kawałkami a nie jednym wywołaniem funkcji write.

> PS. O ile FAT jeszcze da się muteksowac, to np. SPI byc może wymagać
> będzie asynchronicznego I/O bo np. trudno muteksowac jakiś watek na czas
> wrzucania framebuffera do LCD, lepiej żeby w tym czasie _mógł_ coś zrobić.

LCD masz na SPI? W takim wypadku oczywiście przydałoby się zrobić
chociaż asynchroniczne zapisy. Albo wyodrębnić demona wysyłającego ekran
po kawałku "w tle", bo nie będzie blokować głównego zadania
zainteresowanego rysowaniem. A "po kawałku" ze względu na współdzielenie
magistrali SPI i nieblokowanie na zbyt długi czas np. dostępów do karty SD.

>> A zdecydowanie najlepiej (jeżeli jest taka możliwość) nie używać FAT
>> tylko przejść na inny system plików.
>
> Powiedź to marketoidom z Microsoftu. Na razie mam goowniany FAT,
> zamknięty NTFS i Readonly ISO. Niestety docelowo karty SD beda
> obsługiwać niepelnosprytni.

Myślałem wcześniej, że karta SD to tylko lokalny nośnik danych, nie
przekładany z urządzenia do komputera. No ale jeżeli masz takie
potrzeby, to rzeczywiście FAT nie ominiesz. Chociaż, w zależności od
wersji Windows, w której to ma być czytane, możesz rozważyć exFAT:
http://pl.wikipedia.org/wiki/ExFAT

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.