Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Student 01. 10. 2017, 22:37:12
-
Zdravím, uvažoval jsem, že bych se pokusil přečíst souborový systém FAT (12, 16, 32, - exfat jsem zatím vzdal). Našel jsem si k němu nějakou dokumentaci a právě to louskám, ale obecně je souborový systém uložený v diskovém oddílu. Pokoušel jsem se najít nějaké podrobnější informace o tom, jak diskový oddíl vypadá, ale moc se mi toho najít nepodařilo. Nějakým způsobem jsem vyčetl, že je tam nějaké jeho ID, informace o tom, že je ten oddíl dosový (0x08), ale to je asi tak všechno. Nevíte někdo, kde bych k tomu, jak je vlastně diskový oddíl uspořádaný, našel nějaké podrobnější info? (Ideálně hoooooooodně podrobnější a hooooooooodně polopatické?) Díky za rady.
-
https://www.youtube.com/watch?v=V2Gxqv3bJCk (https://www.youtube.com/watch?v=V2Gxqv3bJCk) a navazující.
-
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system (druhý odkaz z Googlu na "fat fs format", a to ještě "format" je mnohoznačné protože to znamená i sloveso vytvoření filesystému) vypadá dostatečně podrobně na to, aby podle toho šel napsat alespoň read-only driver.
Pokud chceš rovnou kopírovat kousky kódu, tak bych se koukl na FAT knihovnu pro Arduino - tam je zaručeno, že to bude minimalistické a snad jednoduché.
-
Na začátku disku jsou (kromě jiného) informace o rozdělení disku. Prostě kde jednotlivé oddíly začínají a končí. Říká se tomu partition table, je několik formátů a jsou podrobně zdokumentované. V tom oddílu je pak souborový systém, nebo cokoliv tam chceš mít. Začít můžeš tady:
https://en.wikipedia.org/wiki/Partition_table (https://en.wikipedia.org/wiki/Partition_table)
http://wiki.osdev.org/Partition_Table (http://wiki.osdev.org/Partition_Table)
-
Díky všem za info. Jak k tomu FATu, tak především k Partition Table. Ty odkazy na OSDev jsou fakt užitečné. Ten FAT sice najít tak nějak dokážu, zatím mě docela mate to "binární smetí" před FAT tabulkou, takže jsem chtěl zjistit, k čemu vlastně je a jakým způsobem je určený jeho rozsah (abych věděl, jestli FAT nemůže mít počátek jinde). Podle dokumentace, kterou jsem zatím přečetl, to vypadá, že tam je ještě něco, co neznám. Pravděpodobně to není hlavička dosovského ani GPT oddílu. K tomu FATu sice už nějakou dokumentaci mám (vypadá, že od Microsoftu - http://read.pudn.com/downloads77/ebook/294884/FAT32%20Spec%20(SDA%20Contribution).pdf ), ale většina z těch odkazů, co jste sem dali, je o dost přehlednějších než to, co jsem si našel.
Takže ještě jednou díky za užitečné odkazy.
-
Na taketo pokusy by som asi odporucal si spravit file system do suboru a pre naplnenie mountnut cez
mount -o loop
-
Pokud se nepoužívá GPT, je na začátku disku Master boot record (MBR). Jeho součástí je i tabulka rozdělení disku, ale před ní je ještě kód zavaděče (kód, který je načten BIOSem při startu počítače a následně mu předá řízení – např. LILO nebo GRUB).
-
Čtení fat je dost triviální záležitostí.
Dokonce tak triviální, že se kód dá napsat v Assembleru bez ztráty příčetnosti.
FAT12 - obvykle použitý na disketách - jsem prasil sám kdysi dávno v dřevním ASMx86 bez použití cizích maker.
No ale taky jde o to, jak moc nízký přístup k HW máš.
V Linuxu programovat neumím, no nejsem si jistý, co všechno ti OS dovolí provést.
Pro inspiraci: http://www.independent-software.com/writing-your-own-bootloader-for-a-toy-operating-system-4/
(Vygooglováno a jen tak lehce prohlédnuto.)
-
Doplnění: Můžeš si napsat vlastní OS! ;)
Vůbec to není tak složité, jak to na první pohled vypadá.
Tedy do doby, než budeš potřebovat multitasking.
A myslím, že bys jako vývojové prostředí pro vlastní OS, klidně mohl použít Widlo/Linux + GCC, tedy za předpokladu, že bys používal svoje knihovní funkce nebo na svůj OS tyto funkce portoval. Protože OS funguje jako vrstva mezi programem a souborem služeb, které ti poskytuje BIOS a hardware.
Tvoje štěstí je, že pro grafiku bys mohl použít režim VESA, článků o VGA VESA programming je dost.
-
ak sa zaujimas o fat16/32, tak naco ti je diskovy oddiel? ten je nutny le nak chces bootovat z toho disku, hociaky dalsi disk vies zformatovat cely, minimalne v linuxovom svete, neviem ci vo win je nutne mat partition tabulku na kazdom disku.
-
neviem ci vo win je nutne mat partition tabulku na kazdom disku.
Je, ale jsou výjimky stejně jako na Linuxu.
ten je nutny le nak chces bootovat z toho disku
Tabulka rozdělení disků je potřeba, abys věděl, kde ti začíná která partition a nebo - pokud to chceš říct jinak - kde leží jaká tabulka systému souborů. Bez partition table bys nevěděl, kolik na disku těch tabulek je a ani kde bydlí.
Což je řešitelné, nikoliv však pohodlné.
-
Vyexportuj si prvy 1MB a kukni na to hexeditorom
dd if=/dev/sda of=./sda.bin bs=512 count=2048
-
Doplnění: Můžeš si napsat vlastní OS! ;)
twl, ty ses vazne pripad... jestli mu porad, aby pri svem reseni pochopeni diskovych oddilu a fat fs, ze by si mohl postavit vlastni HW, pouzit samozrejme CPU vlastniho navrhu a napajet to vyhradne elektrinou co odchyti ze vzduchu... ;)
-
neviem ci vo win je nutne mat partition tabulku na kazdom disku.
Je, ale jsou výjimky stejně jako na Linuxu.
tak bud to nutne je, nebo neni, v Linuxu to nutne neni, filesystem se da vytvorit primo na celem disku, bez pouziti rozdeleni_disku/partition_table/mbr/gpt...
-
Jak vidím, podařilo se mi vyvolat bouři ve sklenici vody. Takže se tak trošku pokusím vysvětlit, co je vlastně mým cílem. Každopádně díky za všechny podnětné nápady. Mým cílem je přečíst SD kartu arduinem, ideálně s jakýmkoliv FAT systémem. Jelikož jsem ale nesehnal dokumentaci od exfat, tak jsem jej prozatím vyřadil. Navíc využívá nějaké patenty Microsoftu, takže si raději naformátuji kartu na FAT 32, byť bych byl raději, kdyby fungovala jakákoliv vložená karta. Udělal jsem si tedy obraz disku pomocí dd (nejprve s exfat, později s FAT 32, 16 a 12 - jakkoliv pro mě je relevantní pouze FAT 32, případně exfat). Na FAT 16 a 12 jsem se prostě chtěl mrknout pro úplnost. Zjistil jsem ale, že z nějakého důvodu začíná FAT 32 od adresy 0x100000. Prozatím se v tom nevyznám, ale mezi touhle adresou a prvním sektorem disku je nějaká hromada hexa kódu. Mě zajímá hlavně proto, abych věděl, jestli se můžu u všech zařízení spolehnout, že ten FAT bude stále na stejné adrese (a já nemusím nic řešit) nebo jestli se ta počáteční adresa může pohybovat podle nějakého dalšího oddílu nebo kódu, který musím nějak přeskočit. Proto začínám diskovým oddílem. Taky si říkám, jestli bych se neměl zajímat o komplikovanější situace, např. více oddílů s FAT. To je důvod, proč mě zajímá taky diskový oddíl. Co se týče hexa kódu, očesal jsem ho o nulové řádky a pošlu tady jeho začátek. Nejsem si jistý, ale zavaděč by to být neměl. Jednak jsem jej nevytvářel, jednak v prvním sektoru to nevypadá, že by tam nějaký zavaděč byl. Taky mi to přijde docela obsáhlé a pokud tím listuju, tak se některé pasáže opakují. Celá ta změť znaků končí až na začátku FAT oddílu na uvedené adrese.
Jen pro úplnost:
- Ano, čtení FAT samostatně bude asi relativně jednoduché
- Ve finále to budu programovat v Assembleru pro AVR, předtím si udělám model v C/C++ a budu číst obraz uložený u sebe na PC
- Taky si nemyslím, že bych se z toho programování v Assembleru zbláznil
- Přístup k hardware nemůžu mít lepší, čtečku si asi budu muset vyrobit (pokud půjde vše podle plánu).
Určitě bude spousta z Vás zkušenějších než já, takže pokud byste někdo věděli, co je to tam za rozsypaný čaj, postnu tady začátek obrazu očesaný o řádky plné nul. Budu určitě rád, když mě to usnadníte. Na začátku jsem rozluštil identifikaci dosovského oddílu, který jsem vytvořil. Ale netuším, co je ten zbytek...
000001c0: 0300 83b7 cefc 0008 0000 0098 eb00 0000 ................
00000200: 52b3 efa8 61f1 4427 98d1 52e7 ee50 65e1 R...a.D'..R..Pe.
00000210: 5c47 c990 b563 bf49 83b5 09be 3584 bd1b \G...c.I....5...
00000220: 8e59 25d6 dcf6 ca36 bcb7 8bb1 39a6 95d7 .Y%....6....9...
00000230: 7cf3 0a2a 3cfc 8a0b 3c3a 889f 3342 ab8f |..*<...<:..3B..
00000240: f920 16c0 7681 3706 b217 ac71 e924 76d9 . ..v.7....q.$v.
00000250: 36d6 b6f7 b631 b4a5 bbdd 98cd 52af efe0 6....1......R...
00000260: 6041 4187 8511 1e66 4555 9ffd 400f 8021 `AA....fEU..@..!
00000270: 00c6 0294 0f78 2310 ca62 bd4f 8fa1 21c6 .....x#..b.O..!.
00000280: c496 9b77 5b33 daa8 dff2 c02e 80e7 0252 ...w[3.........R
00000290: 0dec 2c68 e972 772d 32ee ae67 e550 5fe1 ..,h.rw-2..g.P_.
000002a0: c044 819b 055a 1fdc 40c9 82b5 0fbe 2184 .D...Z..@.....!.
000002b0: c51a 9e5f 45c3 9c89 4b37 bab1 9fa5 41df ..._E...K7....A.
000002c0: 84c1 1a86 5f15 c27c 8d0b 2e3a e49e 5b45 ...._..|...:..[E
000002d0: db9c d94a d7be f186 2514 de7a c51e 9e47 ...J....%..z...G
000002e0: 4593 9d69 4f77 a331 caa4 bfdb 80d9 02d6 E..iOw.1........
000002f0: 0ef4 2638 d492 fb6e 1b64 5b59 dbd4 d8fa ..&8...n.d[Y....
00000300: d21e ec46 6995 757f 3f02 820f 0c22 28cc ...Fi.u.?...."(.
00000310: f2aa 2ffc e00a 403d 808d 032e 0ae4 3e58 ../...@=......>X
00000320: 85d3 1cea 4a7d bd0d 8e2d 24ee da66 dd56 ....J}...-$..f.V
00000330: cff6 a037 c0b0 83a3 09ca 34bc bb8b 9939 ...7......4....9
00000340: 5697 f770 3320 aac3 fe88 0730 12a0 6fc1 V..p3 .....0..o.
00000350: 6087 4313 8a69 3d76 8f37 22b2 cfae a1e7 `.C..i=v.7".....
00000360: c450 99e3 544b f9b8 1590 7d61 0f46 2394 .P..TK....}a.F#.
00000370: c97a b71f b241 ad85 ed1c 6e49 65b7 5db3 .z...A....nIe.].
00000380: cda8 adf3 ec28 68f1 7227 2cd2 eaee 7e65 .....(h.r',...~e
00000390: 055e 1fc4 4099 8355 0bfe 3804 901b 605b .^..@..U..8...`[
000003a0: 41db 84d9 1ad6 5ef5 c63c 948b 7b3b 1a9a A.....^..<..{;..
000003b0: 5f5d c3cc 88ab 33fa a81f f040 2180 c502 _]....3....@!...
000003c0: 9e0f 4423 98c9 52b7 efb0 61a1 45c7 9c91 ..D#..R...a.E...
000003d0: 4b67 bb51 9be5 585f d1c0 e482 5b0d da2c Kg.Q..X_....[..,
000003e0: dcea ca7e bd07 8e11 2466 d956 d7f6 f036 ...~....$f.V...6
000003f0: 20b4 c3ba 899f 3542 bf8f 8121 06c6 1694 .....5B...!....
00000400: c972 b72f b2e1 ae45 e59c 5d49 cfb4 a1bb .r./...E..]I....
00000410: c598 9d53 4feb a079 c114 867b 151a 7e5d ...SO..y...{..~]
00000420: 05ce 1ca4 4bd9 b8d5 92fd 6e0f 6423 58cb ....K.....n.d#X.
00000430: d2b8 ef92 616d 476f 9361 6b47 7b93 196a ....amGo.akG{..j
00000440: 577d f30c 2a28 fcf2 0a2c 3ce8 8a73 3d2a W}..*(...,<..s=*
00000450: 8eff 2602 d40e f826 10d4 62f9 4e17 a471 ..&....&..b.N..q
00000460: d924 d6da f6de 36c4 b69b b759 b3d5 a8fd .$....6....Y....
00000470: f20c 2c28 e8f2 722d 2cee ea66 7d55 0ffe ..,(..r-,..f}U..
00000480: 2004 c01a 805f 01c2 048c 1b28 5af1 de24 ...._.....(Z..$
00000490: c4da 9adf 5ec3 c688 9733 72ab 2ffa e01e ....^....3r./...
000004a0: 4045 819d 054e 1fa4 41d9 84d5 1afe 5e05 @E...N..A.....^.
000004b0: c41c 984b 51bb e598 5d51 cfe4 a05b c1d8 ...KQ...]Q...[..
000004c0: 84d3 1aea 5e7d c50c 9e2b 44fb 9a19 5c57 ....^}...+D...\W
000004d0: c9f0 b423 b8c9 92b5 6fbf 6183 450b 9e39 ...#....o.a.E..9
000004e0: 4497 9b71 5b27 dad0 dee2 c64e 95a7 7dd3 D..q['.....N..}.
000004f0: 0cea 2a7c fd0a 0e3c 2488 db32 daae dfe6 ..*|...<$..2....
00000500: c056 81f7 0432 18ac 53e9 e874 7139 2696 .V...2..S..tq9&.
00000510: d776 f336 2ab4 ffba 019c 0548 1fb0 41a1 .v.6*......H..A.
00000520: 85c5 1c9e 4b45 bb9d 994d 57af f1e0 2440 ....KE...MW...$@
00000530: d982 d50e fe26 04d4 1af8 5e11 c464 995b .....&....^..d.[
00000540: 57db f0d8 22d0 cee2 a64f d5a0 fdc2 0c8c W..."....O......
00000550: 2b28 faf2 1e2c 44e9 9a75 5d3f ce80 a703 +(...,D..u]?....
00000560: d208 ec32 68ad 73ef 2862 f14e 27a4 d1da ...2h.s.(b.N'...
00000570: e4de 5ac5 de9c c74a 93bf 6983 750b 3e3a ..Z....J..i.u.>:
00000580: 849f 1b42 5b8d d92c d6ea f67e 3504 be1b ...B[..,...~5...
00000590: 8459 19d6 54f5 fa3c 1c88 4b31 baa5 9fdd .Y..T..<..K1....
000005a0: 40cf 82a1 0fc6 2094 c37a 8b1f 3a42 9d8f @..... ..z..:B..
000005b0: 4d23 aec9 e6b4 57b9 f194 2578 df12 c26e M#....W...%x...n
000005c0: 8d67 2f52 e3ee 4865 b15d a7cd d0ac e3ea .g/R..He.]......
000005d0: 487d b10d a62d d4ec fa6a 1d7c 4f09 a235 H}...-...j.|O..5
000005e0: ccbc ab8b f938 1690 7761 3346 ab97 f970 .....8..wa3F...p
000005f0: 1720 72c1 2e86 e716 5275 ed3c 6e89 6737 . r.....Ru.<n.g7
00000600: 52b3 efa8 61f1 4427 98d1 52e7 ee50 65e1 R...a.D'..R..Pe.
00000610: 5c47 c990 b563 bf49 83b5 09be 3584 bd1b \G...c.I....5...
00000620: 8e59 25d6 dcf6 ca36 bcb7 8bb1 39a6 95d7 .Y%....6....9...
00000630: 7cf3 0a2a 3cfc 8a0b 3c3a 889f 3342 ab8f |..*<...<:..3B..
00000640: f920 16c0 7681 3706 b217 ac71 e924 76d9 . ..v.7....q.$v.
00000650: 36d6 b6f7 b631 b4a5 bbdd 98cd 52af efe0 6....1......R...
00000660: 6041 4187 8511 1e66 4555 9ffd 400f 8021 `AA....fEU..@..!
-
Mým cílem je přečíst SD kartu arduinem, ideálně s jakýmkoliv FAT systémem.
Výtečně. Tak ten produkt prosímtě hlavně nikomu neprodávej. Díky a páááá.
;D ::) :o ???
;D ::) :o ???
;D ::) :o ???
-
Mým cílem je přečíst SD kartu arduinem, ideálně s jakýmkoliv FAT systémem.
Výtečně. Tak ten produkt prosímtě hlavně nikomu neprodávej. Díky a páááá.
;D ::) :o ???
;D ::) :o ???
;D ::) :o ???
Neboj, nebudu. Je to pro moji vlastní potřebu. Jinak bych to nedělal s Arduinem (resp. vůbec bych k tomu nepřistupoval takhle). BTW ty víš co je ten hexakód nebo ne? Nějak jsem v tvojem příspěvku přehlídl podrobnější popis...
-
Měl by jsi se soustředit na problém kamaráde.
Je řada projektů, které zpřístupňují CF kartu i pro zápis.
Například:
Atarimax MyIDE-II CompactFlash Cartridge
Běželo poměrně dost seriálů "Arduino a SD karta" a v Angličtině i s lepším popisem.
Pro Arduino by měly existovat i knihovny: https://www.arduino.cc/en/Reference/SD
Většina těch projektů je lépe nebo hůře dokumentovaná a dá se z toho hrozně moc přečíst a naučit.
Obecně se dá říct, že spojení Arduino a SD karta s FAT je mimořádně dobře prošlapaná cestička.
Až tak, že bych si troufal říct "Je to dlážděný chodník".
Tím se vracíme zpátky na začátek, pokud ti jde o Arduino, použil bych existující knihovny.
Já si původně myslel, že chceš dělat nějaký virus, který by se tam mohl schovat :-)
-
Chlape, dyt ten google prislusne odkazy vydava snad i pri dotazu na nesmrtelnost chroustu.
https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS (https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS)
-
Měl by jsi se soustředit na problém kamaráde.
Je řada projektů, které zpřístupňují CF kartu i pro zápis.
Například:
Atarimax MyIDE-II CompactFlash Cartridge
Běželo poměrně dost seriálů "Arduino a SD karta" a v Angličtině i s lepším popisem.
Pro Arduino by měly existovat i knihovny: https://www.arduino.cc/en/Reference/SD
Většina těch projektů je lépe nebo hůře dokumentovaná a dá se z toho hrozně moc přečíst a naučit.
Obecně se dá říct, že spojení Arduino a SD karta s FAT je mimořádně dobře prošlapaná cestička.
Až tak, že bych si troufal říct "Je to dlážděný chodník".
Tím se vracíme zpátky na začátek, pokud ti jde o Arduino, použil bych existující knihovny.
Já si původně myslel, že chceš dělat nějaký virus, který by se tam mohl schovat :-)
Ne, virus jsem opravdu neměl v úmyslu. Na to 1) nemám, 2) i kdybych na to měl, asi bych nepsal na fórum, aby mi s tím poradili :-)
Určitě chápu, že s klasickýma knihovnama by to bylo snazší, ale říkal jsem si, že se o tom zkusím něco dozvědět. Ten assembler z toho vypadl, protože ho zatím pro Arduino používám častěji, než C. Ale jak se tak na to všechno dívám, asi změním názor. Ale když tak teď nad tím přemýšlím, tak to asi bude přece jen smysluplnější, ikdyž se nedozvím, jak to vlastně přesně funguje. Jednak ušetřím čas, jednak získám přehled o knihovnách, což pro mě bude asi z dlouhodobého hlediska lepší. Každopádně díky za nakopnutí :-)
-
Chlape, dyt ten google prislusne odkazy vydava snad i pri dotazu na nesmrtelnost chroustu.
https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS (https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS)
Jop, to je hezký odkaz. Ale když si přečteš kus té dokumentace, co jsem dával hned na začátek + si pozorně přečteš příspěvky, co jsem tu postoval, tak zjistíš, že tohle všechno je na disku uložené s nějakým prefixem. A ten boot sektor, na který odkazuješ, je taky hezký, ale mě zajímá taky to, co je uložené od 0x200. Ano, vše po 0x1FF je bootovací sektor - to vím, používám Linux. Ale pokud se podíváš na výpis, Od 0x200 po 0x100000 je nějaký rozsypaný čaj. Až na 0x100000 začíná ten souborový systém FAT se svým BPB oddílem, začínajícím buď 0xEB nebo 0xE9, FAT tabulkou a případně jejich kopií (kopiemi, podle nastavení). Mě ale zajímá taky to, jestli ten prefix 0x100000 nemůže být proměnlivý. Zatím jsem se o tom moc nedočetl (ještě jsem to ale nepřečetl celé). To je mj. jedna z věcí, nad kterou přemýšlím, kromě toho, co je to vlastně za změť nad 0x200. Jak funguje FAT vyčtu z dokumentace. Mám ji dávno staženou. Co ale nevím je, jak je určená poloha toho oddílu na disku, např. proč vlastně není hned za prvním sektorem a proč je tam ten rozsypaný čaj.
-
Každopádně díky za nakopnutí :-)
Jestli jsem byť i jen trochu pomohl, tak jsem rád!
Víš, když pastneš nějakou část souboru, nějakou tabulku, tak to vyžaduje, aby si to někdo buď pamatoval (LOL?) nebo se v tom právě vrtal, jinak by s tím musel strávit víc času, než je většina lidí ochotná.
Já ti moc rád poradím v rámci "šáhnutí do mé paměti" případně se sestavením dotazu pro google.
Ostatně taky se tu občas ve fóru takhle ptám.
Další, řekněme dobré dotazy jsou, když chceš od někoho pomoci s algoritmem, všiml jsem si, že to tu lidi mají rádi a berou to jako sudoku, ale musíš to popsat dost obecně. Jen to nesmí vyžadovat to, aby si museli nejprve hodinu něco studovat, musíš otázku položit jasně. Kolikrát lze nějaký problém řešit rekurzí, já s tím mám třeba problém, na záležitost se podívám a nenapadne mě rekurzivní řešení. Tady na fóru jsou k dispozici i hodně velké mozky a to zadarmo. Jen před ty lidi musíš postavit hračku nebo hádanku, ale ne práci.
Nedávno jsem tu viděl tenhle post:
https://forum.root.cz/index.php?topic=16424.msg228395;topicseen#new (https://forum.root.cz/index.php?topic=16424.msg228395;topicseen#new)
Zkus tomu člověku napsat, můžete se v tom hrabat oba.
Obecně, pokud máš šťourací období, tak na Zive vychází seriál o bastlení.
Bouchnul bych si nějaký inzerát na forum PCtuningu, Zive, dvě fóra o Arduinu a zkusil sehnat pár lidí, kteří si s tím hrají.
Velká výhoda pro tebe je ta, že to možná budeš táhnout vpřed, ale tím se právě nejvíc naučíš.
Jestli to chápu správně, tak tu kravinku k Arduinu koupíš cca za kilo i s nejlacinějším Čínským Arduinem.
http://www.dx.com/p/sd-card-reading-writing-module-for-arduino-148784 (http://www.dx.com/p/sd-card-reading-writing-module-for-arduino-148784)
No i kdybys to měl třem lidem koupit a pomoct jim s rozběhnutím, aby ti oni na oplátku pomohli s programováním, tak to za to stojí. Později - mnohem později - až to bude komplet, to můžeš překlopit do projektu.
Až z toho budeš mít projekt "Univerzální připojení Arduino SD", použití ve vašich programech ...bla bla bla...
Najednou z toho máš REFERENCI!!!
A může to být i dost zajímavá reference.
Kdybych chtěl, mohl bych napsat v C# aplikačku, která data přetáhne do SQL, nebo ti je vytiskne.
Dalo by se to udělat jako univerzální tool.
Vytvoří si soubor s deskriptory, spustíš program a ono ti to spustí Excel a hodnoty zobrazí v Grafu.
Franta to použije pro snímání teplot.
Soubor s deskriptorem by mohl vypadat (plácám): <TEMP><1>;<TEMP><2>;<TEMP><3>
A já ti podle toho vysypu v jednom grafu tři teploty.
Někdo jiný chce sledovat průchody, tak by jeho soubor s deskriptorem mohl vypadat:
<TIME>DOOR1;<TIME>DOOR2;<TIME>DOOR2
(Jasně že tohle není XML, naznačuji, že by se data měla sypat do souboru oddělená středníkem a popis hodnot.)
Otázka je, jestli se ti chce vrtat jen v tomhle a kolik na to máš času, atd.
-
Určitě chápu, že s klasickýma knihovnama by to bylo snazší, ale říkal jsem si, že se o tom zkusím něco dozvědět.
Nevzdávej to. Pokud tě to baví a máš na to čas, tak si to nastuduj. Získáš zkušenosti (s programováním), které ti nikdo nevezme.
A s tím fórem, to máš těžký. Nejdřív se musí přehnat smršť neužitečných komentářů, ale když chvilku počkáš, někdy se i dozvíš něco užitečného :-)
-
přehnat smršť neužitečných komentářů
Často si za ty komentáře mohou lidé sami ;D
ASM je krásný, není efektivní v něm programovat, kód není snadno přenositelný, dokonce i v rámci různých CPU stejné řady se výsledek může chovat jinak (přijde nová verze a zmizí nějaká instrukce/registr), ale nic to nemění na tom, že se člověk naučí neuvěřitelné věci.
Doplním, že jsem s programováním v ASM přestal z důvodu bláznivých paměťových modelů, které mi prostě nesedly. Chtěl jsem se k tomu vrátit s příchodem Linuxu a 64bitových systémů, ale ta Motorolí syntaxe mi nesedí a nějak mě to přešlo. A především, dělat v ASM OOP ...no to už by chtělo kouzelníka :-D to bych asi nedal.
TIP: Divili byste se, jak neuvěřitelně rychle se dá v ASM napsat Widlo okenní aplikace!
-
Chápu. Já jsem to pro nikoho ani tak nemyslel jako práci. Čekal jsem, že nějaký programátor prostě bude vědět, jak to tam vlastně je. Myslel jsem, že to třeba někde na VŠ detailně probírají nebo něco na ten způsob... Ale pokud je to nějak složité, tak to budu řešit sám (ono stejně musím začít tím, že si přečtu hezkých pár stránek textu). Buď to za nějakou rozumnou dobu dám, nebo to nedám a pak to budu muset prostě napsat v C s využitím nějaké knihovny (a asi to potom bude zbytečně velké, protože knihovna nebude ušitá na míru situaci). Stejně jsem to C pro to Arduino měl někdy v plánu...
-
Chlape, dyt ten google prislusne odkazy vydava snad i pri dotazu na nesmrtelnost chroustu.
https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS (https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS)
Jop, to je hezký odkaz. Ale když si přečteš kus té dokumentace, co jsem dával hned na začátek + si pozorně přečteš příspěvky, co jsem tu postoval, tak zjistíš, že tohle všechno je na disku uložené s nějakým prefixem. A ten boot sektor, na který odkazuješ, je taky hezký, ale mě zajímá taky to, co je uložené od 0x200. Ano, vše po 0x1FF je bootovací sektor - to vím, používám Linux. Ale pokud se podíváš na výpis, Od 0x200 po 0x100000 je nějaký rozsypaný čaj. Až na 0x100000 začíná ten souborový systém FAT se svým BPB oddílem, začínajícím buď 0xEB nebo 0xE9, FAT tabulkou a případně jejich kopií (kopiemi, podle nastavení). Mě ale zajímá taky to, jestli ten prefix 0x100000 nemůže být proměnlivý. Zatím jsem se o tom moc nedočetl (ještě jsem to ale nepřečetl celé). To je mj. jedna z věcí, nad kterou přemýšlím, kromě toho, co je to vlastně za změť nad 0x200. Jak funguje FAT vyčtu z dokumentace. Mám ji dávno staženou. Co ale nevím je, jak je určená poloha toho oddílu na disku, např. proč vlastně není hned za prvním sektorem a proč je tam ten rozsypaný čaj.
Zacatek toho FAT oddilu je mozne vycist z GPT nebo z MBR. Rozsypany caj mezi Od 0x200 po 0x100000 je kvuli zarovnání prvního oddílu. Drive se setrilo mistem, takze prvni oddil zacinal hned za prvnim sektorem, dneska kvuli zarovnani zacina prvni oddil az od 1MB. viz https://cs.wikipedia.org/wiki/GUID_Partition_Table
-
Chlape, dyt ten google prislusne odkazy vydava snad i pri dotazu na nesmrtelnost chroustu.
https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS (https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system#RSVD_SECTORS)
Jop, to je hezký odkaz. Ale když si přečteš kus té dokumentace, co jsem dával hned na začátek + si pozorně přečteš příspěvky, co jsem tu postoval, tak zjistíš, že tohle všechno je na disku uložené s nějakým prefixem. A ten boot sektor, na který odkazuješ, je taky hezký, ale mě zajímá taky to, co je uložené od 0x200. Ano, vše po 0x1FF je bootovací sektor - to vím, používám Linux. Ale pokud se podíváš na výpis, Od 0x200 po 0x100000 je nějaký rozsypaný čaj. Až na 0x100000 začíná ten souborový systém FAT se svým BPB oddílem, začínajícím buď 0xEB nebo 0xE9, FAT tabulkou a případně jejich kopií (kopiemi, podle nastavení). Mě ale zajímá taky to, jestli ten prefix 0x100000 nemůže být proměnlivý. Zatím jsem se o tom moc nedočetl (ještě jsem to ale nepřečetl celé). To je mj. jedna z věcí, nad kterou přemýšlím, kromě toho, co je to vlastně za změť nad 0x200. Jak funguje FAT vyčtu z dokumentace. Mám ji dávno staženou. Co ale nevím je, jak je určená poloha toho oddílu na disku, např. proč vlastně není hned za prvním sektorem a proč je tam ten rozsypaný čaj.
Zacatek toho FAT oddilu je mozne vycist z GPT nebo z MBR. Rozsypany caj mezi Od 0x200 po 0x100000 je kvuli zarovnání prvního oddílu. Drive se setrilo mistem, takze prvni oddil zacinal hned za prvnim sektorem, dneska kvuli zarovnani zacina prvni oddil az od 1MB. viz https://cs.wikipedia.org/wiki/GUID_Partition_Table
Tisíceré díky !!! To mi mezi tím vším nějak uniklo... Teď už do toho začínám pořádně vidět.
-
Od 0x200 po 0x100000 je nějaký rozsypaný čaj. ... Mě ale zajímá taky to, jestli ten prefix 0x100000 nemůže být proměnlivý.
Pokud se pamatuji, tak historicky bylo dáno, že každá partition začíná na začátku fyzického tracku. Už si nepamatuji důvody (že by pro jednodušší zavedení zbytku loaderu u bootovací partition?). A jak se, kvůli zpětné kompatibilitě, stále mnohá zařízení tváží že mají virtuální cylindry, hlavy a sektory, tak tím bývá mezera před první partition.
Toto místo často využívaly viry, někdy i antiviry /či tam (tuším) i některé os/ dávaly kopii MBR (možná ne úmyslně). Možná se i užívalo jako místo pro zavaděč.
Takže, zkrátit by se možná dalo, ale asi bude záležet na zpětné kompatibilitě a jestli nověji lze začít partition i uprostřed (vitruálního) tracku.
-
Ono je asi vhodne nejprve si ustanovit terminologii, pak pripravit prostredi a pak zacit zkoumat data.
Tedy:
- na disketach nebyvala informace o rozdeleni na diskove oddily, na discich, flashkach a dost casto dnes i na sd kartach ta informace je
- sd karty, pokud maji tabulku diskovych oddilu, vyuzivaji pro ulozeni informaci o oddilech tzv. partition table v master boot recordu (v pripade extended oddilu je struktura jeste slozitejsi): https://en.m.wikipedia.org/wiki/Master_boot_record
- pro nalezeni pocatecniho sektoru partition/souboroveho systemu je treba precist partition table a pak se vydat na konkretni diskovy offset (dnes se pro prvni partition pouziva jiz zminovanych 1MiB od zacatku disku)
- data v dokumentaci FAT pouzivaji offsety od zacatku partition (pozor na to)
- pri vytvareni souboroveho disku ani partition tabulky se disk NEINICIALIZUJE nulami; inicializuji se jen vybrane sektory: pokud na disku uz neco driv bylo, a inicializace FAT to neprepsala, tak to tam porad muze byt - binarni balast tak vubec nemusi patrit FAT filesystemu
Tedy: je nejlepsi SDkartu inicializovat nulami (dd=/dev/zero of=/dev/sdX), nasledne vytvorit partition tabulku s jednou partition (cfdisk /dev/sdX) a nakonec vyrobit souborovy system ve vytvorene partition (mkfs.vfat -F 32 /dev/sdX1)
Pak bude na karte jen skutecne nejnutnejsi minimum vhodne pro zkoumani.
Dal muzete zacit psat program, ktery v jedne procedure nacte partition tabulku a najde zacatek partition, a v jine procedure zkousi nacist souborovy system FAT; vyberte si jednu z verzi FAT a s tou zacnete. Nedelejte program rovnou univerzalni, nejde to. Vyvarujte se FAT12, at nemusite resit slozite bitshifty. Na experimenty dobre poslouzi FAT16, ktera ma tusim pevne umisteny root adresar, sestnactibitove entries ve FAT tabulce a pod.
Pak nactete prvni sektor (boot record) diskoveho oddilu (/dev/sdX1) a z nej spocitejte informace, ktere potrebujete - velikost FAT clusteru, pozici prvni a druhe kopie FAT tabulky, pozici korenoveho adresare. Pak zkuste nacist korenovy adresar (filename entry). Pak zkuste nacist obsah souboru v korenovem adresari (pro to je treba: rozparsovat boot record, najit korenovy adresar, najit file entry, najit ve fat tabulce prvni cluster souboru a vsechny dalsi clustery, a pak nacist samotna data clusteru z disku). Nakonec muzete zkusit pracovat s vnorenymi adresari. Vizte tez https://en.m.wikipedia.org/wiki/Design_of_the_FAT_file_system
V dokumentaci bude pravdepodobne zobrazovan offset - tedy posunuti od nejakeho mista. Pouziva se offset od zacatku boot sektoru, offset od zacatku fat rabulky, offset od zacatku fat datove oblasti, atp.)
Pro cteni diskovych struktur doporucuju hexdump -C nazev.souboru, ktery zobrazuje offsety od zacatku souboru. Da se pouzit i na cely disk, ale nedelal bych to. :-)
-
A ten boot sektor, na který odkazuješ, je taky hezký, ale mě zajímá taky to, co je uložené od 0x200. Ano, vše po 0x1FF je bootovací sektor - to vím, používám Linux. Ale pokud se podíváš na výpis, Od 0x200 po 0x100000 je nějaký rozsypaný čaj. Až na 0x100000 začíná ten souborový systém FAT se svým BPB oddílem, začínajícím buď 0xEB nebo 0xE9, FAT tabulkou a případně jejich kopií (kopiemi, podle nastavení). Mě ale zajímá taky to, jestli ten prefix 0x100000 nemůže být proměnlivý. Zatím jsem se o tom moc nedočetl (ještě jsem to ale nepřečetl celé). To je mj. jedna z věcí, nad kterou přemýšlím, kromě toho, co je to vlastně za změť nad 0x200. Jak funguje FAT vyčtu z dokumentace. Mám ji dávno staženou. Co ale nevím je, jak je určená poloha toho oddílu na disku, např. proč vlastně není hned za prvním sektorem a proč je tam ten rozsypaný čaj.
Pozor, "Boot Sector" neni "Master Boot Record". Disk zacina MBR, oddil zacina Boot Sectorem. V MBR je partition table, odkud se da zjistit, kde zacinaji oddily. Ten tvuj rozsypany caj nebude soucasti oddilu, ale bude pred oddilem. To, ze tvuj oddil zacina na 0x10000 (pokud tam opravdu mas BPB, tak je to Boot Sector a tudiz tacatek oddilu) musi jit zjistit z tabulky oddilu v MBR.
-
Díky za velice podrobné informace a další užitečné rady. Konečně do toho začínám vidět a můžu se do toho vesele pustit. Jen ještě budu muset dočíst tu specifikaci FAT(32)...