Różnice w obsłudze kart SD i SDHC przez mikrokontrolery AVR - co zmienić w oprogramowaniu?

Sat Jul 04, 2009 9:18 pm   

Sebastian Biały pisze:


Dynamiczne przydzielanie pamięci tylko po to, żeby obsłużyć kartę SD?


I w czym problem?


Czytam te twoje wymagania i musiałbym być niepoprawnym optymistą, żeby
spodziewać się gotowego rozwiązania z internetu.

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

Sat Jul 04, 2009 9:30 pm   

Zbych wrote:

_Znacznie_ więcej niż tylko głupią karte sd. Karta SD to tylko kawałek
problemu w tym systemie. Więc "nie tylko" po to.


No popatrz, to zupełnie jak ja (co zdążyłem już wcześniej napisać).

Sat Jul 04, 2009 9:32 pm   

Sebastian Biały pisze:


Bardzo skutecznie do synchronizacji dostępu do magistrali SPI nadają się
semafory. W każdym razie w moich firmowych projektach często się
sprawdzają. Ewentualnie mutexy jeżeli masz.

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

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

Sat Jul 04, 2009 9:38 pm   

Sebastian Biały pisze:


Pisałem o tym, że _w_ogóle_ użycie dynamicznego przydziału pamięci do
odczytu karty jest bez sensu.




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

Sat Jul 04, 2009 9:46 pm   

Adam Dybkowski wrote:

Mam. Ale nie w tym problem. Znalezienie LGPL SD+FAT który pasuje do tej
koncepcji dawno już porzuciłem. Ale ciągle czekam az mnie ktoś oświeci
jakims świetnym pomysłem np. na FATa potrafiącego robić asynchroniczne
odczyty + DMA i takie tam. Ale na 99% będe to pisał sam :/

Sun Jul 05, 2009 12:06 am   

Sebastian Biały pisze:


Oglądałeś PHAT?
http://www.ethernut.de/en/documents/phat.html
(uwaga: to jest dość stary opis, lepiej przejrzeć od razu źródła Nut/OSa)

Nie jest na GPLu. Oczywiście będzie nieco dłubaniny z przeniesieniem
tego kodu pod twoją filozofię sterowników czy twój system, ale IMHO nie
będzie to aż tak skomplikowane. A asynchronicznych odczytów i DMA
wymagaj raczej od niższej warstwy (SPI) a nie FATa. Potrzebujesz
korzystać w aplikacji z nieblokującego odczytu plików?

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

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

Sun Jul 05, 2009 8:25 am   

Adam Dybkowski wrote:

Tak.


Widziałem, oglądalem.


To troche skomplikowane, dość powiedzieć że mam maszyne wirtualną z
wątkami i cały system operacyjny powinien miec w miare możliwości
wykonywanie zadań w sposób nieblokujacy, a przynajmniej nieblokujący dla
VM. W każdym razie sama obsluga fs (nie tylko FAT) powinna już byc
dostosowana albo przez dodakowy wrapper albo wprost. W każdym razie FAT
jest na tyle mało skomplikowany że prawdopodobnie zdecyduje się na
wynalezienie koła na nowo.

PS. Czy nazwa PHAT nie ma przypadkiem ominąć jakiś problemów patentowych
na FATa?

Sun Jul 05, 2009 8:25 am   

On Sat, 04 Jul 2009 22:38:55 +0200, Zbych wrote:

Troche tych danych tam jednak trzeba zapamietac. Bufor na odczyt
sektora katalogu, bufor na odczyt sektora FAT .. im wiecej tych
buforow tym lepiej .. dynamiczny cache dyskowy by sie przydal ..

J.

Sun Jul 05, 2009 11:37 am   

J.F. pisze:
[quote:24c00ec29e]On Sat, 04 Jul 2009 22:38:55 +0200, Zbych wrote:
Sebastian Biały pisze:
Dynamiczne przydzielanie pamięci tylko po to, żeby obsłużyć kartę SD?
_Znacznie_ więcej niż tylko głupią karte sd. Karta SD to tylko kawałek
problemu w tym systemie. Więc "nie tylko" po to.
Pisałem o tym, że _w_ogóle_ użycie dynamicznego przydziału pamięci do
odczytu karty jest bez sensu.

Troche tych danych tam jednak trzeba zapamietac. Bufor na odczyt
sektora katalogu, bufor na odczyt sektora FAT .. im wiecej tych
buforow tym lepiej .. dynamiczny cache dyskowy by sie przydal ..

[/quote:24c00ec29e]
To o czym piszesz, to już jest obsługa systemu plików, a nie odczyt
sektorów z karty SD.
--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

Sun Jul 05, 2009 8:17 pm   

Sebastian Biały pisze:


Sama obsługa FATu nie wprowadza żadnych działań blokujących (tzn.
pollingu / aktywnego oczekiwania na cośtam), 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.

A zdecydowanie najlepiej (jeżeli jest taka możliwość) nie używać FAT
tylko przejść na inny system plików.


Możliwe, że tak.

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

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

Sun Jul 05, 2009 8:35 pm   

Adam Dybkowski wrote:

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.


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


Powiedź to marketoidom z Microsoftu. Na razie mam goowniany FAT,
zamknięty NTFS i Readonly ISO. Niestety docelowo karty SD beda
obsługiwać niepelnosprytni.

Sun Jul 05, 2009 9:13 pm   

Sebastian Biały pisze:


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


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.


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.


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.

Sun Jul 05, 2009 9:28 pm   

Adam Dybkowski wrote:

Jestes optymistą.


To fatalnie. Mizerny RTOS wychodzi :D


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


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


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


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

Sun Jul 05, 2009 9:48 pm   

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.

Sun Jul 05, 2009 9:54 pm   

T.M.F. wrote:

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


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