A diferença entre Flash bruta, SPI Flash e SD Card
Antes de comparar LittleFS, SPIFFS e sistemas de arquivos para SD Card, precisamos separar três coisas que muitas vezes são tratadas como se fossem iguais: a Flash interna do microcontrolador, a Flash externa SPI/QSPI/OSPI e o cartão SD. Todas servem para armazenar dados de forma persistente, mas o modo como o firmware conversa com cada uma é muito diferente.
A Flash interna do microcontrolador é a memória não volátil que normalmente armazena o próprio firmware. Em alguns projetos, uma parte dela pode ser reservada para parâmetros de configuração, número de série, calibração, contador de uso ou pequenas tabelas. O problema é que essa memória costuma ter ciclos limitados de apagamento e gravação, exige operações por páginas ou setores, e normalmente não é ideal para arquivos grandes ou escritas frequentes. Em muitos casos, gravar constantemente na Flash interna pode reduzir a vida útil do dispositivo.
A Flash externa SPI, QSPI ou OctoSPI é uma memória não volátil conectada ao microcontrolador por um barramento serial. Ela é muito usada quando o projeto precisa armazenar páginas web embarcadas, imagens, logs, arquivos de configuração, bancos de dados simples ou até modelos de inteligência artificial embarcada. Nesse cenário, o microcontrolador conversa diretamente com a memória: envia comandos de leitura, escrita, apagamento de setor e consulta de status. Como a Flash não permite sobrescrever livremente qualquer byte já gravado, o sistema de arquivos precisa entender essa limitação física.
É justamente nesse ambiente que LittleFS e SPIFFS brilham. Eles foram projetados para memórias Flash em que o firmware precisa lidar com blocos apagáveis, páginas graváveis, desgaste por ciclos de escrita e risco de corrupção caso a energia caia durante uma operação. Em outras palavras, eles são adequados quando o microcontrolador enxerga a memória quase “crua”, tendo que administrar diretamente seus blocos.
O SD Card, por outro lado, é diferente. Internamente, ele também usa memória Flash, mas essa Flash é controlada por um circuito interno do próprio cartão. Esse controlador faz tarefas como mapeamento de blocos, correção de erros, distribuição de desgaste e gerenciamento físico da memória. Para o microcontrolador, o SD Card aparece como um dispositivo de blocos: o firmware lê e escreve setores, geralmente de 512 bytes, sem controlar diretamente páginas internas, blocos de apagamento ou células Flash.
Por isso, em projetos com STM32N6 usando SD Card, o caminho mais comum é usar um sistema de arquivos do tipo FAT, especialmente FATFS, porque ele trabalha bem sobre dispositivos de bloco e permite compatibilidade com computadores. Isso significa que o cartão pode ser removido do equipamento, inserido em um PC e seus arquivos podem ser lidos normalmente. Essa é uma vantagem enorme para aplicações de aquisição de dados, dataloggers, gravação de diagnóstico, coleta de sensores e atualização de parâmetros.
A diferença conceitual pode ser vista assim:
No caso do STM32N6, que possui recursos avançados e pode ser usado em aplicações de visão computacional, inteligência artificial de borda, controle industrial e aquisição de dados, o SD Card é especialmente interessante para armazenamento de grande volume. Um sistema pode, por exemplo, coletar dados de sensores em uma tarefa FreeRTOS e gravar arquivos .csv, .bin ou .json no cartão. Outra tarefa pode ler configurações de inicialização, enquanto uma terceira pode enviar relatórios pela rede. O cuidado principal é impedir que várias tarefas acessem o sistema de arquivos ao mesmo tempo sem proteção.
Assim, uma regra prática pode ser adotada: use LittleFS ou SPIFFS quando estiver lidando diretamente com Flash embarcada; use FATFS ou FreeRTOS+FAT quando estiver lidando com SD Card. Essa regra não é absoluta, mas evita muitos problemas de projeto. Tecnicamente, é possível criar adaptações, mas nem sempre vale a pena forçar LittleFS ou SPIFFS sobre um cartão SD, porque o SD já possui uma camada interna de gerenciamento e se comporta como mídia de bloco.
Essa distinção será importante para a próxima parte, onde faremos o comparativo direto entre LittleFS e SPIFFS, analisando robustez, desgaste, diretórios, uso de RAM, limitações e adequação para projetos embarcados modernos.
