Atmega FAT karta SD

Oglądałeś już to?

No wlasnie o niej mowilem. Troche duzo zajmuje. Jak nie znajde nic "chudszego" to sprobuje z ta podzialac.

Wersja "p" nie ma potrzebnej mi funkcjonalnosci.

Poki co biore sie za testowanie pelnej wersji.

Mozesz sprobowac recznie stworzyc plik o okreslonym rozmiarze (byle ciagly) i zapisac sobie gdzie sie zaczyna, gdzie konczy (numery sektorow) i gdzie aktualnie piszesz. Troche to sztywne ale na pewno duzo mniej pochlonie pamieci.

U¿ytkownik "Zbych" snipped-for-privacy@onet.pl napisa³ w wiadomo¶ci news:ipsalt$1ms5$ snipped-for-privacy@news.mm.pl...

Ile mial pierwszy ms-dos ? Chyba ponad 10kB, a przeciez byl odchudzony i nie obslugiwal katalogow :-)

J.

No właśnie. Po chusteczkę obsługa FATa, jak się tylko jeden plik obsługuje. Zapisywać sektory i już. A "zawczasu" zrobić swój sztywny system na SD.

Waldek

W dniu 2011-05-05 12:26, J.F. pisze:

Ale on chyba nie obsługiwał FAT12, FAT16, FAT32, długich nazw, co? Zresztą wystarczy spojrzeć na wielkość kodu na ARM - jest mniejszy, więc pewnie obliczenia na długich liczbach dokładają swoje.

W dniu 2011-05-05 17:00, Zbych pisze:

No chyba właśnie FAT12.

W dniu 2011-05-07 00:18, Mario pisze:

To zdanie było całością, a ty je pofragmentowałeś.

Za to usilnie starał się udawać CP/M i jednocześnie udawać że nie udaje. Zapewne to pochłoneło troche przestrzeni więc ciężko porównać w prost.

W dniu 2011-05-07 10:00, Zbych pisze:

Bo z resztą zadania zgadzam się.

Nie, skleroze mam juz za duza ... BDOS zajmowal 3.5kB, ale na dysku czy w pamieci z buforami dyskowymi ? Bufory duze nie byly, bo sektor mial 128 bajtow.

Udawanie trudne nie bylo .. moze i MSdos 1.0 byl krotszy ?

Tak czy inaczej - widac potrzebuje to pare kB programu. W nowoczesnej wersji wiecej.

J.

W dniu 2011-05-07 11:03, Mario pisze:

aha.

A może inaczej: napisać własny FS inny niż fat i olać kompatybilność (i problemy prawne) z fat. W końcu napisanie sterownika do fuse pod linuxem jest nieporównywalnie łatwiejsze niż walka z tępym windowsem.

Sam będę za chwile stawał przed problemem zrobiena fs w ... pamięci eeprom. Wymagany jest *bardzo* mały system plików w którym można olać daty, atrybuty i inne śmieci. Może jednak coś naskrobać na LGPL ;)?

No tak, tylko potem klient chce windows :-) I latwiej napisac obsluge fat w uP, niz driver do windows 7 :-)

A moze jednak wsadzic zlacze i dopisac "obsuguje karty SD juz od 8 MB" :-)

J.

No tak, jesli się pisze dla tumanisty to owszem, to warunek nie do przeskoczenia. Normalni sobie poradzą.

Ale fat to same problemy: co można żądać od systemu plików który ma coś koło 30 lat i jest napisany jako klon fs z CP/M a potem wykupiony przez firmę piszącą głównie BASICe na 8-bitów i obarczony jakimiś kretyńskimi problemami prawnymi z patentami? Niestety historia informatyki to głównie wybieranie debilnych rozwiązań i zabetonowaniaa ich potem jako "standardy przemysłowe"... a MS całkiem nieźle żyje z faktu że nikt nie implementuje nic innego w urządzeniach.

Dobra, wracam do obmyślania SeboFS for EEPROM :P

Trudno wymagac od klienta zeby sobie zainstalowal malego linuxa do transferu plikow :-)

Czesc "FAT" jest w miare przyzwoita, kretynskie jest tylko doklejenie dlugich nazw plikow.

Ale jak chcesz .. czemu nie ext3 albo NTFS :-)

Duzy ruch w danych ? Moze CD ?

J.

Za to bardzo łatwo żeby zainstalował dużego windowsa do transferu plików ... ;) Świat jest przedziwny ...

A np przezabawna rozdzielczość 2 sekund? W czasie kiedy MS wciskał swój prymitywny klon CP/M do IBMów świat wiedział już coś o np. koncepcji security choćby z Unixa. To nie było przyzwoite tylko pojechanie po bandzie najmniejszej lini oporu. Prawa dostepu? Multithreading? E Panie, to tylko nastepny klon CP/M przepisywany przez specjalistów od BASICa.

ISO jest read-only. Ruch w danych symboliczny. Na razie mimo mnogości fs w projekcie fuse jakoś nic nie pasuje mi do 64kB eeprom.