Sistemi FAT16 e FAT32: Quando si lavora nel mondo integrato ci sono alcune possibilità che si possa andare incontro ad un’applicazione che richiede maggiore spazio di memoria di quanto sia disponibile nella maggior parte dei microcontrollori e anche degli EEPROM esterni. Ecco perché vanno molto bene le schede SD o MMC. Sono a basso costo e facile da lavorare.
Per la maggior parte delle applicazioni tutto ciò che serve è una porta SPI, e anche se non disponiamo di essa è possibile emularne facilmente una sulla maggior parte dei microcontrollori. Con la porta SPI si può comunicare e memorizzare i dati per la scheda SD, ma è un po’ più complicato. La maggior parte delle applicazioni richiede di memorizzare o recuperare i dati da un personal computer. Allora si ha bisogno di un modo per collegare l’applicazione al computer e soprattutto un metodo per organizzare i dati in un modo che sarà riconosciuto dal sistema operativo del computer. Per questo è necessario disporre di una sorta di sistema di gestione dei file. E’ possibile fare uso di un sistema FAT 16 o FAT 32. Il sistema File Allocation Table (FAT) è semplice e supportato da quasi tutti i sistemi operativi. E’ necessario per prima cosa capire come funziona prima di aggiungerla al dispositivo integrato.
Sistemi FAT16 e FAT32: come aggiungere memoria di massa alle applicazioni integrate
Le schede SD o MMC tendono a gestire la loro memoria in dimensioni fisse conosciute come settori o talvolta dimensioni di pagina, che solitamente sono di 512 o 256 byte. In un sistema FAT alcuni di questi settori sono utilizzati per la File Allocation Table, che agisce come un indice, mentre gli altri settori sono utilizzati per la memorizzazione dei dati.
Tutti questi settori possono essere uniti per formare ciò che è noto come cluster. Le dimensioni dei cluster possono variare da 1 a 64 settori. I cluster sono gli enti che sono stati monitorati all'interno della File Allocation Table. Dato che il cluster può variare da 1 a 64 settori, deve essere presa una decisione sulla dimensione dei cluster. Il vantaggio di avere una più ampia dimensione dei cluster è che per gestire la memoria viene utilizzato un minor numero di cluster e quindi è obbligatoria una minore File Allocation Table.
Questo rende le cose più efficiente sul sistema dei file, ma usa molto spazio della memoria quando ci sono memorizzati piccoli file per ogni cluster. Quindi sostanzialmente si desidera scegliere la dimensione dei cluster in base al tipo di dati e le dimensioni con cui si dovrà lavorare. Più piccoli sono i dati e più piccola sarà la dimensione dei cluster.. In tal modo si garantisce un uso efficiente della memoria.
La presente File Allocation Table è solo una tabella contenente informazioni relative a ciascun cluster. Ad esempio in un sistema FAT16 ogni tabella è un numero intero a 16-bit che dimostra se il cluster se è vuoto o pieno, legato ad un altro cluster, riservato o se contiene settori danneggiati. Un cluster pieno è rappresentato da 0xFFFF mentre uno vuoto è dato da 0x0000. Quando un file richiede più di un cluster di spazio di memoria, si forma una catena di cluster e la File Allocation Table collega questi cluster avendo l'indirizzo del prossimo cluster presente in ogni indice fino all'ultimo cluster, che ha un 0xFFFF per rappresentare la fine dei dati o l'ultimo cluster nel file. Anche 0x0001 rappresenta un cluster riservato mentre 0xFFF7 rappresenta un cattivo cluster. La tabella seguente descrive tali caratteristiche.
La File Allocation Table è molto importante e due o più copie di essa sono memorizzate prima dei cluster dei dati. Lo scopo principale della File Allocation Table è quello di tenere traccia dello status dei cluster (vuoto, pieno) e la posizione, ma non contiene alcuna informazione circa i file attualmente archiviati. Per questo scopo abbiamo la root directory.
La root directory possiede un’importante informazione sul file come il nome, l'estensione, gli attributi (archivio, directory, se è nascosto, di sola lettura, sistema e volume), la data e l’ora della creazione, l'indirizzo del primo cluster del file/directory dei dati e, infine, le dimensioni del file/directory. La root directory è memorizzata dopo l'ultima copia della File Allocation Table e prima di presentare i cluster dei dati. La struttura della root directory è indicata nella seguente tabella.
Gli attributi hanno alcune maschere di bit nell’entrata della directory. Sono 01 per la sola lettura, nascosto per 02, 04 per il sistema, 08 per l’etichetta di volume, 10 per la sottodirectory, e il 20 per l’archivio. La data e l'ora memorizzano l'ultima volta che il file è stato modificato. Per quanto riguarda il Tempo i bit 15 a 11 rappresentano le ore, i bit 10 a 5 rappresentano i minuti e i bit 4 a 0 rappresentano i secondi diviso per due. Per quanto riguarda la Data i bit 15 a 9 rappresentano anno a partire dal 1980 al 2107, 8 bit per rappresentare Mese 5, e 4 a 0 bit rappresentano la il giorno. La sezione del primo cluster collega il file con la File Allocation Table. Questo numero punta al primo cluster contenente il file dei dati. Infine, la sezione Dimensioni contiene (in byte) le dimensioni dei file dei dati.
È possibile utilizzare le informazioni dalla directory principale per scrivere una varietà di funzioni per il vostro sistema integrato. Ad esempio, l'ora e la data di stampa di un sensore di dati in un logger dati.
Ora che si conosce la struttura di base del sistema FAT16, è possibile iniziare a sviluppare applicazioni per le quali gli utenti possono facilmente comunicare con il dispositivo integrato e un computer. Aggiungere un dispositivo di memorizzazione di massa come una scheda SD significa aumentare la flessibilità a qualsiasi dispositivo. Consuma molto scrivere il codice necessario per l'attuazione del sistema FAT16, nonché il codice per supportare la comunicazione con una scheda SD. La buona notizia è che ci sono molti software liberi e librerie a pagamento che si prendono cura dei codici al posto vostro. Tutto quello che bisogna fare è modificare il codice per adattare le piadinature specifiche e l'architettura del microcontrollore.
Ad esempio Microchip offre “File I/O Functions Using Microchip's Memory Disk Drive File System Library”, che è fondamentalmente il sistema FAT16 per alcuni dispositivi PIC. È possibile scaricare il codice sorgente e il report dell’applicazione da qui. Inoltre, in alcuni casi ci sono a disposizione moduli di hardware che implementano il sistema FAT per voi. Grazie a loro si risparmia il tempo di sviluppo, ma questi chip sono molto costosi e utilizzati in gran parte in dispositivi di archiviazione di massa USB. Personalmente trovo che siano uno spreco di denaro, dato che è relativamente semplice implementare il sistema FAT sul microcontrollore.
Leggi la versione italiana: FAT16 and FAT32 Systems: How to Add Mass Storage to Your Embedded Applications
penso che il FAT sia ancora il più usato per le memorie esterne in quanto leggibile praticamente da tutti i sistemi operativi.
come sappiamo, linux legge tutto ma non si può dire lo stesso degli altri sistemi.
inoltre penso (ma non sono sicuro) che lo spazio riservato dal filesystem FAT sia inferiore rispetto agli altri. daltronde questo filesystem è vecchiotto e comporta diversi svantaggi, ma probabilmente non rilevanti per questo tipo di applicazioni. (tanto per citare una delle limitazioni più grandi: dimensione massima dei file di 4 Gb)
ma vi sono altri tipi di allocazione come quelli utilizzati da i sistemi linux che secondo me sono migliori da quelli FAT e NTFS, tanto non si ha bisogno di file di grandi dimensioni in questi microcontrollori.
il FAT è l’ideale per la sua semplicità di implementazione,
nessun sistema linux riesce ad essere così semplice,
è soprattutto visto la sua età non necessita di licenza.
Rileggendo l’articolo,
Per una volta leggo qualcosa che è stato progettato meglio dalla casa Microsoft,
nel FAT è stato implementato il Le date che può andare 1980 al 2107,
A differenza di file system di linux o Mac che per le date usano il formato “Unix time”,
Che pochi sanno che un giorno arriverà a overflow 2018.
Speriamo che questo piccolo problema sarà risolto prima di questa data.
Se non vado errato 19/01/2018 alle ore 03:15:28 tutti i 32 bit saranno a uno.
o ext3 o ext4 non sono a pagamento e la licenza GNU è gratuita, basta mettere il file di testo relativo alla licenza. Fra l’altro molti NAS lavorano su questo formato.
Ti informo che le strutture di Ext4 utilizzate dai sistemi linux dalla 2.6 in poi sono state progettate per il completo supporto all’indirizzamento a 64 bit.
ci sarà da scommetterci che anche la data fatidica ancora sarà molto utilizzato ext2-3,
semplicemente perché i sistemi non sono stati aggiornati per ragioni di costi.
ancora tuttora esistono dei server che sono accesi e in servizio da ormai più di 10 anni.
sei poco informato molti router soprattutto quelli più evoluti utilizzano sistemi linux e ti parlo di prodotti che sono il fiore all’occhiello della tecnologia.
Dubito che un problema del genere passerebbe inosservato e irrisolto… ad ogni modo è possibile passare da ext3 a ext4 senza perdere i dati…
E’ sicuramente un interessante discussione quella sulla quale verte l’argomento. Intato bisogna fare i complimenti a chi ha scritto questo articolo proprio per il suo linguaggio tecnico utilizzato durante le spiegazioni e che, nonostante la difficoltà trattata, riesce comunque ad essere molto comprensibile anche per chi non ha numerose conoscenze tecniche. Intanto per rendere ancora più semplice il tutto, anche per chi non ne sa proprio nulla, si può definire il Fat 32 come un’evoluzione dello standard Fat. Quest’ultimo, come ben specificato anche nell’articolo, con il Fat potremo utilizzare solo delle schede di memoria o penne usb fino a 2GB mentre con il Fat 32 potremo arrivare a ben 32Gb. Per questo consiglio di utilizzare quando è possibile sempre lo standard Fat 32.
Bisogna fare attenzione però, proprio perché alcune console come Xbox360 o Wii supportano uno solo dei due ma questo può anche capitare con alcuni sistema operativi( non windows) quindi prima di formattare accertatevi quale sia compatibile con la vostra periferica. Inoltre nell’articolo non si parla della possibilità di formattazione in NTFS: infatti se dovessimo avere a nostra disposizione un disco rigido o una chiavetta superiore a 32Gb, allora non avremo più la possibilità di utilizzare Fat32 ma solo questo standard. Grazie a questo standard, avremo la possibilità di avere una minore frammentazione del disco fisso, avremo un minore spazio occupato e potremo inserire file anche più grandi di 4Gb. Per questo tutti gli Hard Disk esterni o interni devono essere formattati in questo formato. Non è possibile utilizzare NTFS se la chiavetta è minore di 4Gb. Bisogna inoltre ricordare che se abbiamo una chiavetta da 16Gb ma la formattiamo in Fat 32, non sarà comunque possibile inserirgli file che siano maggiori di 4Gb e quindi è preferibile, se abbiamo in mente di lavorare con file di grosse dimensioni, formattare in NTFS.
con il FAT32 si può superare tranquillamente 32Gb è andare fino al livello teorico 2TiB( (2024 GoB),
io personalmente ho un disco 500 Go formattato in FAT32, Metafar è quello è necessario usare GParted.
http://it.wikipedia.org/wiki/File_Allocation_Table#FAT32
Le FAT saranno anche le più semplici, io personalmente preferisco lavorare con le ext3 o ext4!!!
Hai conoscenze anche di Xbox 360 ? Con la jtag si può leggere fat e non ntfs ma senza nulla che file system adottano?
Perché se metto nel pc la chiavetta formattata da Xbox non la riconosce se non con xstaff
per l’xbox360 usa Fat32. Tuttavia dal menu system della console xbox360 devi selezionarla come periferica ed eseguire una procedura guidata che ti permetterà di utilizzarla sulla console.
installaci il linux sulla tua xbox
embemmed , cmq gia fatto ho messo la ditro gentoo 😛
Articolo molto bello complimenti! Lavoro spesso con Microchip e mi è sempre passato per la mente di gestire una SD per il salvataggio di un log file con estensione txt da poter leggere successivamente su PC ma affrontare la gestione del file system mi ha sempre scoraggiato. Per ovviare alla mole di codice da dover trattare stavo prendendo in considerazione un oggetto (integrato) con cui comunicare tramite uart e che implementasse all’interno la gestione dei vari file system, ma dopo questo articolo penso che prima proverò a gestirlo io. Se ci sono sviluppi pubblicherò sicuramente il lavoro.