LittleFS vs SPIFFS: comparação técnica para microcontroladores
Quando falamos em LittleFS e SPIFFS, estamos falando de dois sistemas de arquivos criados para resolver um problema muito específico: permitir que microcontroladores usem memórias Flash como se fossem pequenos discos de arquivos. Porém, mesmo tendo objetivos parecidos, eles nasceram com filosofias diferentes e isso afeta diretamente a robustez, o desempenho e a manutenção do firmware.
O SPIFFS, sigla para SPI Flash File System, foi durante muito tempo uma das opções mais conhecidas para sistemas embarcados com Flash SPI, especialmente em plataformas como ESP8266 e ESP32. Ele foi projetado para trabalhar com Flash NOR, oferecendo uma camada simples para criar, abrir, ler, escrever e apagar arquivos. Sua proposta era ser pequeno, relativamente fácil de portar e adequado a memórias onde não existe um controlador sofisticado como no SD Card.
O LittleFS, por sua vez, surgiu depois com uma preocupação mais forte em robustez contra falha de energia, consistência dos metadados e distribuição de desgaste. Ele foi desenvolvido pela ARM/mbed e depois passou a ser mantido como projeto aberto. Sua arquitetura usa técnicas como copy-on-write, metadata pairs e wear leveling dinâmico, procurando evitar que uma interrupção no meio de uma gravação destrua a estrutura do sistema de arquivos.
A diferença mais importante entre os dois está na forma como eles lidam com falhas. Em um sistema embarcado real, a energia pode cair durante uma escrita, o watchdog pode reiniciar o sistema, uma bateria pode desconectar ou uma fonte instável pode provocar reset. Se isso acontecer enquanto o firmware estiver atualizando um arquivo de configuração, o sistema de arquivos precisa sobreviver. O LittleFS foi desenhado tendo esse tipo de cenário como prioridade. O SPIFFS também possui mecanismos para lidar com Flash, mas historicamente é menos robusto em cenários de queda de energia e manutenção de metadados.
Outro ponto importante é o suporte a diretórios. O SPIFFS não possui diretórios reais. Ele pode simular caminhos usando nomes de arquivos com barras, como /config/rede.json, mas internamente isso é apenas parte do nome do arquivo. Já o LittleFS suporta diretórios, o que facilita organizar projetos maiores, separando arquivos de configuração, logs, certificados, bancos de dados simples e páginas web embarcadas.
Em termos de uso de memória, ambos são relativamente leves, mas o consumo depende muito da configuração: tamanho de bloco, tamanho de página, cache, número de arquivos abertos e camada de bloco implementada pelo desenvolvedor. Em microcontroladores pequenos, cada kilobyte importa. No caso de um STM32N6, essa limitação é menos agressiva do que em MCUs muito modestos, mas ainda assim é necessário configurar o sistema de arquivos de forma compatível com a memória disponível e com o volume de dados gravado.
A tabela abaixo resume a comparação:
| Critério | LittleFS | SPIFFS |
|---|---|---|
| Mídia típica | Flash NOR interna ou externa | Flash NOR SPI |
| Robustez contra queda de energia | Muito boa | Menor, depende do uso |
| Wear leveling | Sim, dinâmico | Sim, mas mais limitado |
| Diretórios reais | Sim | Não |
| Arquivos grandes | Melhor organização, mas depende da Flash | Possível, mas pode degradar |
| Indicado para novos projetos | Geralmente sim | Apenas quando já existe legado ou restrição específica |
| Facilidade de portar | Boa, exige camada de bloco | Boa, exige camada de bloco |
| Compatibilidade com PC | Não direta | Não direta |
| Uso natural em SD Card | Não é o ideal | Não é o ideal |
Do ponto de vista prático, eu escolheria LittleFS para um projeto novo com Flash externa no STM32N6. Ele é mais moderno, mais robusto e mais adequado para aplicações em que arquivos de configuração e logs precisam sobreviver a resets inesperados. O SPIFFS ainda pode ser útil em sistemas legados ou quando já existe uma base de código construída ao redor dele, mas para novos projetos ele tende a ser uma escolha menos interessante.
Agora, quando o armazenamento principal é um SD Card, a comparação muda. Nem LittleFS nem SPIFFS são a escolha natural para o cartão SD, porque ambos foram pensados para Flash diretamente controlada pelo microcontrolador. O SD Card já possui controlador interno e trabalha como dispositivo de blocos. Nesse caso, a escolha mais coerente é usar FATFS ou FreeRTOS+FAT, especialmente quando se deseja remover o cartão e ler os arquivos em um computador.
Podemos pensar assim:
Uso com Flash externa SPI/QSPI/OSPI:
Preferência moderna: LittleFS
Possível em legado: SPIFFS
Uso com SD Card:
Preferência prática: FATFS ou FreeRTOS+FAT
LittleFS/SPIFFS: possível apenas com adaptação, mas geralmente não recomendado
No contexto do STM32N6 com FreeRTOS e SD Card, o artigo seguirá uma abordagem pragmática: primeiro mostraremos uma arquitetura usando SD Card com FATFS, porque é o caminho mais natural e útil. Em seguida, apresentaremos exemplos de como seria a estrutura de uso com LittleFS e SPIFFS, deixando claro que eles fazem mais sentido quando o armazenamento é uma Flash externa, não o cartão SD.
A decisão técnica pode ser resumida em uma frase: LittleFS e SPIFFS resolvem o problema da Flash bruta; FATFS resolve melhor o problema do SD Card.
