Sebastian Biały pisze:
A ja myślę, że po prostu marudzisz. W firmie, w której pracowałem jeden gość napisał kod potrzebny do obsługi SD/HC w ciągu tygodnia (włączając w to czytanie dokumentacji i testowanie kart różnych producentów). Na stronie SD Association jest dokumentacja, są opisane różnice w inicjalizacji kart sd i sdhc. Na tej stronie też jest całkiem fajny opis:
To nie tak do konca, ze ludzie pisza badziewny kod. Pisanie na male procki ma swoja specyfike, m.in. brak zasobow. Napisanie uniwersalnej biblioteki jest fajne, ale niekoniecznie optymalne. W efekcie musisz korzystac np. z wiekszego procka, niz gdybys napisal kod "badziewny" ale za to krotszy/szybszy i lepiej dostosowany do konkretnej sytuacji. Inna sprawa, ze ludzie czesto udostepniaja po prostu to co im dziala, w ich konkretnym zastosowaniu.
Masz do tego prawo.
Pozostaje mi pogratulować. Tylko czego to dowodzi? Napisanie tego jest _trywialne_. Mniej trywialne jest takie zaprojektowanie calości aby zredukować malloc/free a jednocześnie np. zapewnić synchronizację międzywatkową SPI i pare innych duperelek ważnych w danym projekcie. Więc może i bym był w stanie napisać SDHC w 3 dni tylko może niekoniecznie działające zgodnie z koncepcjami innych elelementów systemu? Najpierw z chęcią obejrze inne projekty aby nie popelniać błędów które już ktoś popełnił.
Robie coś większego niż grajek mp3. SPI jest współdzielone z innymi elementami systemu. Napisanie calosci jest troche bardziej skomplikowane niż wynika z "opini jakiegoś gościa".
Nie tłumaczy to nijak wewnętrznej potrzeby generowania zmiennych globalnych i ustawionych na sztywno niby-interfejsów.
Czekaj, bo zaczyna się nastepna bez sensu dyskusja. Ja jestem zwolennikiem C++ na uC (włacznie z 8-bitowcami) wiec obawiam się ze za chwile zacznie się jakiś flame. Tak więc EOT.
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.
_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ć).
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.
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.
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 :/
Sebastian Biały pisze:
Oglądałeś PHAT?
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?
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?
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.
To o czym piszesz, to już jest obsługa systemu plików, a nie odczyt sektorów z karty SD.
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.
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.
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:
:D 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 ...
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.
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ę.
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 :)
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.