Adam Dybkowski wrote:
> 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.

>, dopiero niższa warstwa
> 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.

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ć.

> 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.

do góry

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.

do góry

Adam Dybkowski wrote:
> Eee tam, wystarczy założyć semafor na dostęp do całego systemu plików i
> już po kłopocie.

:D Jestes optymistą.

> Czyli tylko jeden wątek w danej chwili będzie mógł
> siedzieć w środku funkcji czytającej/piszącej/kasującej plik.

To fatalnie. Mizerny RTOS wychodzi :D

> 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.

Ano właśnie, nieudolnośc OS zrzucamy na wątek :D

> LCD masz na SPI? W takim wypadku oczywiście przydałoby się zrobić
> chociaż asynchroniczne zapisy.

No właśnie chodzi coś takiego:

while(1) {
startLCDDump();
doCalculations();
waitForDumpToComplete();
draw();
}

A inny wątek sobie coś tam dłubie asynchronicznie I/O (i liczy się z tym
ze czasem go z lekka przytka na czas dump LCD).

> Albo wyodrębnić demona wysyłającego ekran
> po kawałku "w tle"

O ile LCD supportuje takie ficzery jak przesyłanie po kawałku.

> możesz rozważyć exFAT:
> http://pl.wikipedia.org/wiki/ExFAT

Obawiam się, ze stoi za tym banda ujadających wygłodzonych prawników
tylko czekajacych na odpięcie lańcucha w celu pogryzienia mnie
patentami. A zombie CP/M dalej straszy ...

do góry

>> LCD masz na SPI? W takim wypadku oczywiście przydałoby się zrobić
>> chociaż asynchroniczne zapisy.
>
> No właśnie chodzi coś takiego:
>
> while(1) {
> startLCDDump();
> doCalculations();
> waitForDumpToComplete();
> draw();
> }
>
> A inny wątek sobie coś tam dłubie asynchronicznie I/O (i liczy się z tym
> ze czasem go z lekka przytka na czas dump LCD).

To moze prosciej pomiedzy SPI a funkcje, ktore sie do niego odwoluja
wprowadzic kolejna warstwe logiczna. Twoje moduly wysylaja wtedy
polecenia do tej warstwy, ktore sa kolejkowane w RAM i kolejno
obslugiwane, dodatkowo mozesz wprowadzic priorytety. Obsluga takiej
kolejki jest juz prosta i jednowatkowa. Oczywiscie jesli w miedzyczasie
szlag trafi zasilanie/posypie sie system to dane nie zostana zapisane,
ale przy odpowiednio pomyslanym module przynajmniej nie wszystko sie
wykrzaczy. Dla poprawnej wielowatkowej obslugi FAT musisz zapewnic tylko
dwie krotkie funkcje - allokujaca wolny blok i od razu zaznaczajaca go
jako uzyty oraz rezerwujaca miejsce w katalogu. Poniewaz to sa krotkie,
banalne operacje to nie wplynie to na reszte programu.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

T.M.F. wrote:
> To moze prosciej pomiedzy SPI a funkcje, ktore sie do niego odwoluja
> wprowadzic kolejna warstwe logiczna. Twoje moduly wysylaja wtedy
> polecenia do tej warstwy, ktore sa kolejkowane w RAM i kolejno
> obslugiwane, dodatkowo mozesz wprowadzic priorytety.

No i masz jedną z możliwych implementacji AsyncIO. W kazdym razie
dostepne implementacje SPI do tego się nie nadają, FATy z reszta też.

> Dla poprawnej wielowatkowej obslugi FAT musisz zapewnic tylko
> dwie krotkie funkcje - allokujaca wolny blok i od razu zaznaczajaca go
> jako uzyty oraz rezerwujaca miejsce w katalogu. Poniewaz to sa krotkie,
> banalne operacje to nie wplynie to na reszte programu.

Może i banalne, ale dośc częste. Muteksy/semafory nie są za friko. W
każdym razie to czy aby na pewno jest to rozwiązanie najlepsze 100%
pewności nie mam i jeszcze to przemyslę.

do góry

W dniu 05.07.2009 22:54, Sebastian Biały pisze:
> T.M.F. wrote:
>> To moze prosciej pomiedzy SPI a funkcje, ktore sie do niego odwoluja
>> wprowadzic kolejna warstwe logiczna. Twoje moduly wysylaja wtedy
>> polecenia do tej warstwy, ktore sa kolejkowane w RAM i kolejno
>> obslugiwane, dodatkowo mozesz wprowadzic priorytety.
>
> No i masz jedną z możliwych implementacji AsyncIO. W kazdym razie
> dostepne implementacje SPI do tego się nie nadają, FATy z reszta też.

Tak sobie pomyslalem, ze skora takie cuda potrzebujesz to nie prosciej
tam wpakowac ciut wiekszy procesor i linuxa? Zestarzejesz sie piszac ten
dedykowany OS, a i pozytku z tego zadnego, bo nie bedzie OS :)

>> Dla poprawnej wielowatkowej obslugi FAT musisz zapewnic tylko
>> dwie krotkie funkcje - allokujaca wolny blok i od razu zaznaczajaca go
>> jako uzyty oraz rezerwujaca miejsce w katalogu. Poniewaz to sa
>> krotkie, banalne operacje to nie wplynie to na reszte programu.
>
> Może i banalne, ale dośc częste. Muteksy/semafory nie są za friko. W
> każdym razie to czy aby na pewno jest to rozwiązanie najlepsze 100%
> pewności nie mam i jeszcze to przemyslę.

Eee, ja myslalem calkiem banalnie - na czas alokacji blokowac wszystko,
to bedzie operacja typu read-modify-write, jak cos bedzie potrzebowalo
procek to w miedzyczasie sie dopcha. Raptem blokujesz go na pare taktow
zegara.


--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

T.M.F. wrote:
> Tak sobie pomyslalem, ze skora takie cuda potrzebujesz to nie prosciej
> tam wpakowac ciut wiekszy procesor i linuxa? Zestarzejesz sie piszac ten
> dedykowany OS, a i pozytku z tego zadnego, bo nie bedzie OS :)

W chwilach słabości też tak myślę :P Niestety wsadzenie tam czegoś z MMU
jest deczko za drogie. Chyba ze trafi się jakas para CPU+RAM(8MB) w
cenie <50zl i nie wymagająca 4 warstw na ktorej bangla Linux to z
chęcią. Że też nikt nie produkuje SoC typu CPU z MMU i RAM >4MB :/ (a
może się mylę?)

> Eee, ja myslalem calkiem banalnie - na czas alokacji blokowac wszystko,
> to bedzie operacja typu read-modify-write, jak cos bedzie potrzebowalo
> procek to w miedzyczasie sie dopcha. Raptem blokujesz go na pare taktow
> zegara.

Jeszcze nie przemyślałem całości pod kątem SD/FAT wiec nic nie jest
ustalone. Docelowo się zobaczy.

do góry

Sebastian Biały pisze:
> T.M.F. wrote:
>> Tak sobie pomyslalem, ze skora takie cuda potrzebujesz to nie prosciej
>> tam wpakowac ciut wiekszy procesor i linuxa? Zestarzejesz sie piszac
>> ten dedykowany OS, a i pozytku z tego zadnego, bo nie bedzie OS :)
>
> W chwilach słabości też tak myślę :P Niestety wsadzenie tam czegoś z MMU
> jest deczko za drogie. Chyba ze trafi się jakas para CPU+RAM(8MB) w
> cenie <50zl i nie wymagająca 4 warstw na ktorej bangla Linux to z
> chęcią. Że też nikt nie produkuje SoC typu CPU z MMU i RAM >4MB :/ (a
> może się mylę?)

Ale procek, który ma więcej niż 1xSPI to chyba nie jest majątek a odpadł
by ci co najmniej problem multipleksowania SD i LCD. Jeśli do tego
wygospodarujesz trochę pamięci na video ram w procku, to wszystkie wątki
mogą po nim pisać i nie czekać na wysłanie obrazu na fizyczny wyświetlacz.
Nie bardzo rozumiem też czemu unikasz płytek 4-warstwowych. Przy małych
ilościach możesz wsadzić gotowy moduł z prockiem, a przy większych koszt
wykonania płytki 4-warstwowej nie jest aż tak duży.

--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

do góry