eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaObsługa kart SDHC przez uC który pracował z kartami SD 512M
Ilość wypowiedzi w tym wątku: 48

  • 41. Data: 2009-07-05 19:35:57
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: Sebastian Biały <h...@p...onet.pl>

    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.


  • 42. Data: 2009-07-05 20:13:03
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: Adam Dybkowski <a...@4...pl>

    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.


  • 43. Data: 2009-07-05 20:28:54
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: Sebastian Biały <h...@p...onet.pl>

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


  • 44. Data: 2009-07-05 20:48:22
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: "T.M.F." <t...@n...mp.pl>

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


  • 45. Data: 2009-07-05 20:54:13
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: Sebastian Biały <h...@p...onet.pl>

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


  • 46. Data: 2009-07-05 21:43:19
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: "T.M.F." <t...@n...mp.pl>

    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.


  • 47. Data: 2009-07-05 22:06:53
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: Sebastian Biały <h...@p...onet.pl>

    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.


  • 48. Data: 2009-07-06 17:11:29
    Temat: Re: Obsługa kart SDHC przez uC który pracował z kartami SD 512M
    Od: Zbych <a...@o...pl>

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

strony : 1 ... 4 . [ 5 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: