Esp32 очистить оперативную память

Обновлено: 07.07.2024

Это может оказаться полезным, когда скетч работает некорректно, и трудно определить причину ошибки. Ниже на примере показано, как определить количество свободной памяти RAM вызовом функции memoryFree.
Пользовательская функция memoryFree использует системные переменные для вычисления количества свободной оперативной памяти RAM. Обычно системные переменные невидимы - они создаются компилятором для собственного использования (для управления внутренними ресурсами).Количество свободной памяти может меняться с течением времени, пока работает Ваша программа. Очень важно удостовериться, что Вы не тратите больше памяти, чем имеется в наличии у системы.Вот несколько основных причин потребления памяти RAM:
• Когда Вы инициализируете константы:

• Когда Вы декларируете глобальные переменные:

• Когда делаете вызов функции:

• Когда динамически выделяете память:

Объект String системы Arduino использует динамическое выделение памяти для строк. Вы можете проверить это, если добавите в начало кода примера определение строки String s = "\n";, и затем добавите в код loop перед задержкой строки:

После запуска этого варианта скетча Вы увидите, что количество памяти уменьшается, потому что каждая прокрутка цикла loop увеличивает размер строки. В какой-то момент память переполнится, и программа перестанет работать. Поэтому не увеличивайте размер строк сверх необходимого, и следите за их размером. Также будьте особенно внимательны с кодом, который использует динамическое выделение памяти. Не пишите код, который динамически создает разное количество переменных в зависимости от некоторых параметров во время своей работы, потому что очень сложно бывает найти ошибки во время выполнения кода, связанные с переполнением памяти.

Также в библиотеках часто объявляются константы и глобальные переменные, о которых Вы можете не знать, но они также расходуют RAM. У библиотеки Serial, например, есть глобальный массив из 128 байт, который используется как буфер для приходящих последовательных данных. Только это использует одну восьмую от общего объема памяти старого Arduino на микроконтроллере ATmega168.

Добрый день. Пришел на форум по такому вопросу: делаю Бейсик компьютер для школьного кружка(веду его сам). Сильная нехватка оперативной памяти. Всего на плате 500+ кило памяти. Фактически используется 300+. 200 залочены я так понимаю под вай-фай, сетевой протокол и прочее.
Как то можно малой "кровью" разблокировать хотя-бы частично эту не используемую память, вай-фай и сеть не планируются использоваться. PSRAM и память медленная на флеше под оперативную в данном случае не подходят, нет нормального/вообще нет доступа по DMA к этим секторам, а там как раз крутится 800х600 драйвер VGA+память операционки Бейсика.
Дополнительную оперативку в виде чипа тоже к ESP32 не приделать я так понял.
Напишите пожалуйста кто может знает что. Буду благодарен за любую информацию.

nikolz

Well-known member

Добрый день. Пришел на форум по такому вопросу: делаю Бейсик компьютер для школьного кружка(веду его сам). Сильная нехватка оперативной памяти. Всего на плате 500+ кило памяти. Фактически используется 300+. 200 залочены я так понимаю под вай-фай, сетевой протокол и прочее.
Как то можно малой "кровью" разблокировать хотя-бы частично эту не используемую память, вай-фай и сеть не планируются использоваться. PSRAM и память медленная на флеше под оперативную в данном случае не подходят, нет нормального/вообще нет доступа по DMA к этим секторам, а там как раз крутится 800х600 драйвер VGA+память операционки Бейсика.
Дополнительную оперативку в виде чипа тоже к ESP32 не приделать я так понял.
Напишите пожалуйста кто может знает что. Буду благодарен за любую информацию.

а почему бы не сделать LUA компьютер?
Все тоже самое что и в бейсике (в том числе интерактивный режим исполнения) плюс Wifi, BLE, Сеть, звук ,файловая система и т д и т п
К тому же этот язык во всех компьютерных играх используется , редакторе текста SCITE в промышленном оборудовании и т д и т п

nikolz

Well-known member

свой интерпретатор бейсика Вы можете поместить полностью во flash.
Памяти вам должно хватить на все. Вы что-то не так программируете.
монитор придется делать алфавитно-цифровой
либо с внешней памятью

nikolz

Well-known member

l15ar

Member

Добрый день. Пришел на форум по такому вопросу: делаю Бейсик компьютер для школьного кружка(веду его сам). Сильная нехватка оперативной памяти. Всего на плате 500+ кило памяти. Фактически используется 300+. 200 залочены я так понимаю под вай-фай, сетевой протокол и прочее.
Как то можно малой "кровью" разблокировать хотя-бы частично эту не используемую память, вай-фай и сеть не планируются использоваться. PSRAM и память медленная на флеше под оперативную в данном случае не подходят, нет нормального/вообще нет доступа по DMA к этим секторам, а там как раз крутится 800х600 драйвер VGA+память операционки Бейсика.
Дополнительную оперативку в виде чипа тоже к ESP32 не приделать я так понял.
Напишите пожалуйста кто может знает что. Буду благодарен за любую информацию.

Проблема с памятью в ESP32 решаема!
Во первых, если вам не нужен BLE, WiFi и некоторые другие вещи, нафиг сие, память свободна!
Во вторых, корень проблемы лежит в использовании операционной системы RTOS в прошивке, нафиг её, память свободна, ресурсы свободны!
В третьих, можно расширить объем оперативной памяти, подключая последовательную оперативную память.

blog.pagefault-limited.co.uk

Lolin32 Lite (ESP32) 8MB PSRAM Upgrade Mod - Pagefault Blog

By piggybacking a PSRAM chip on to the existing flash chip we can get a whopping additional 8MB of addressable RAM.


-- не нужно предлагать людям то, что многие из них отвергают, как недостойное! Многим ненравится Lua, не своей фантастической скоростью, своим фиговым синтаксисом! :\

Контроллер ESP32 имеет всего 512КБ оперативной памяти, и в сложных проектах разработчик может столкнуться с ее нехваткой. В статье рассказано о встроенных программных инструментах ESP IDF, которые позволят найти проблемные точки и оптимизировать их.

Контроллер ESP32 имеет 512 КБ памяти SRAM. Хотя этот объем может показаться относительно небольшим, при грамотном использовании он может предоставить множество возможностей для разработчика.

Исходный код приложения обычно содержит ряд файлов и библиотек, и компоновщик в своей работе извлекает из этих компонентов различные функции и переменные. Компоновщик обычно оптимизирует объекты, которые не используются (или на которые не ссылаются) в готовой прошивке. Таким образом, в зависимости от того, что вы делаете в своем приложении, вклад различных компонентов в использование памяти меняется.

В состав фреймворка ESP IDF входит утилита idf_size.py, которая позволит оценить использование памяти, чтобы вы могли идентифицировать и оптимизировать проблемные точки. Утилита связана со скриптами сборки, поэтому вы можете напрямую запускать команду make target, чтобы увидеть потребление памяти, не запоминая других команд.

Давайте посмотрим, как можно использовать эту утилиту, чтобы оценить эффективность использования памяти.

Память, выделенная под конкретные компоненты

Первое, что нужно сделать при анализе распределения памяти, это посмотреть, какое влияние каждый из используемых компонентов оказывает на окончательный образ прошивки. Это можно сделать, указав цель size-components для системы сборки. Выполнение этой команды после сборки приложения examples/wifi/power_save дает следующий результат:

$ make IDF_PATH=

/work/idf size-components
Total sizes:
DRAM .data size: 14200 bytes
DRAM .bss size: 23224 bytes
Used static DRAM: 37424 bytes ( 143312 available, 20.7% used)
Used static IRAM: 62344 bytes ( 68728 available, 47.6% used)
Flash code: 368546 bytes
Flash rodata: 65916 bytes
Total image size:

511006 bytes (.bin may be padded larger)
Per-archive contributions to ELF file:

Archive File

DRAM.data

& .bss

IRAM

Flash code

& rodata

Total

На экране видна итоговая информация об объеме, занимаемом всеми компонентами прошивки. Кроме того, в таблице предоставлена подробная информация по каждому из компонентов:

  • data: это размер секции .data приложения. В этой секции размещаются предварительно инициализированные данные и константы.
  • bss: это размер секции .bss. Здесь размещаются любые глобальные или статически определенные переменные и объекты, которые инициализируются нулями при загрузке.
  • IRAM: это размер секции кода ( .text ), которую необходимо загрузить в IRAM. Обратите внимание, что большая часть кода может быть выполнена непосредственно из флэш-памяти (XIP), без необходимости загрузки его в IRAM. Как правило, сюда попадает код, который выполняется в контексте прерывания или непосредственно обращается к флэш-памяти для чтения/ записи.
  • Flash Code: это размер секции кода ( .text ), которая размещается во флэш-памяти и выполняется непосредственно оттуда. Большая часть вашего раздела кода окажется именно в этом столбце.
  • Flash rodata: здесь показаны данные, предназначенные только для чтения и используемые прошивкой (строки, статически инициализированные и неизменяемые массивы). Поскольку доступ к флэш-памяти возможен во время выполнения программы, нет необходимости загружать секцию в память.
  • Total: общий используемый объем памяти для этого компонента.

Конечно, особое внимание нужно уделить размерам разделов IRAM и DRAM, так как именно объем SRAM является ограничивающим фактором (512 КБ) относительно флэш-памяти (порядка 2–8 МБ).

Поиск проблемной сущности

Допустим, вы узнали, что один из используемых вами компонентов потребляет гораздо больше памяти, чем должен. Вы можете изучить проблему глубже, чтобы определить, какая сущность в этом компоненте больше всего влияет на объем используемой памяти. Это можно сделать, используя цель size-symbols для системы сборки. Например:

$ make IDF_PATH=

/work/idf size-symbols COMPONENT=soc
Total sizes:
DRAM .data size: 14200 bytes
DRAM .bss size: 23224 bytes
Used static DRAM: 37424 bytes ( 143312 available, 20.7% used)
Used static IRAM: 62344 bytes ( 68728 available, 47.6% used)
Flash code: 368546 bytes
Flash rodata: 65916 bytes
Total image size:

511006 bytes (.bin may be padded larger)
Symbols within the archive: libsoc.a (Not all symbols may be reported)
Symbols from section: .dram0.data
str1.4(605) __func__$3446(23) __func__$3425(21) rtc_clk_cpu_freq_value(20)
Section total: 669
Symbols from section: .dram0.bss
s_cur_pll(4) s_cur_freq(4)
Section total: 8
Symbols from section: .iram0.text
rtc_init(1020) rtc_clk_cpu_freq_set(472) rtc_clk_bbpll_set(380) rtc_clk_cal_internal(369) .iram1(282) rtc_clk_cpu_freq_get(172) rtc_clk_32k_bootstrap(170) rtc_clk_32k_enable_internal(149) rtc_clk_wait_for_slow_cycle(129) rtc_time_get(96) rtc_clk_cpu_freq_value(96) rtc_clk_cal(78) rtc_clk_xtal_freq_get(68) rtc_clk_slow_freq_get_hz(51) rtc_clk_apb_freq_get(50) rtc_clk_32k_enable(49) rtc_clk_fast_freq_set(46) rtc_clk_slow_freq_set(43) clk_val_is_valid(32) .iram1.literal(28) rtc_clk_apb_freq_update(23) rtc_clk_slow_freq_get(16) clk_val_to_reg_val(14) reg_val_to_clk_val(8)
Section total: 3841
Symbols from section: .iram0.vectors
Section total: 0
Symbols from section: .flash.text
Section total: 0
Symbols from section: .flash.rodata
soc_memory_regions(704) soc_memory_types(320) str1.4(159) soc_reserved_regions(48) soc_reserved_region_count(4) soc_memory_region_count(4)
Section total: 1239

Для получения дополнительной информации по использованию памяти различными сущностями компонента в командной строке make был использован дополнительный параметр COMPONENT = <имя_компонента>. Например, в приведенном выше примере была запрошена информация для компонента «soc».

В результатах вывода команды виден вклад каждой сущности (функции, переменной или объекта) этого компонента в общий размер прошивки. Обратите внимание, что размер каждой функции виден в секции .iram0.text, а, например, массивы soc_memory_types и soc_memory_regions (определенные в soc_memory_layout.c как «const»), помещены во флэш-память, поскольку они предназначены только для чтения.

Результат работы команды может быть эффективно использован для точного определения того, какие части ваших компонентов вносят заметный вклад в использование оперативной памяти контроллера, что позволит вам сосредоточиться на эффективной оптимизации именно этих компонентов.

При создании различных проектов на ESP32 для хранения файлов используем файловую систему SPIFFS. А если файлы и папки созданы программой в SPIFFS, то, что там хранится, посмотреть не получится. Также бывают случаи, с которыми я столкнулся на днях при создании ЧПУ станка на ESP32. Прошивка ESP32_GRBL создает файл конфигурации, который не переписывается при переустановке GRBL. Я без проблем могу найти данный файл и удалить его по имени, но как же быть новичку. Сегодня в уроке рассмотрим, как можно отформатировать SPIFFS используя всего одну команду.

Для данного урока у вас должны быть заранее созданные файлы в файловой системе. В этом нам поможет пример SPIFFS_Test. Который располагается «Примеры -> SPIFFS -> SPIFFS_Test».

созданные файлы в файловой системе. В этом нам поможет пример SPIFFS_Test.

Данный пример нужно немного изменить: закомментируем строки, которые удаляют файлы после их создания. И получим вот такой код.

Данный пример нужно немного изменить: закомментируем строки, которые удаляют файлы

Загрузим пример в ESP32. Как настроить работу ESP32 в среде Arduino IDE читайте тут: Установка, прошивка платы ESP32 в Arduino IDE (Windows, Mac OS X, Linux).

Откроем монитор порта и увидим, что у нас также хранятся файлы от прошивки GRBL:

также создались 2 файла: foo.txt, hello.txt

Загрузим пример в ESP32. Как настроить работу ESP32 в среде Arduino IDE

Код удаления всех файлов из файловой системы SPIFFS ESP32.

Начнем с подключения библиотеки SPIFFS.h, чтобы у нас был доступ к управлению файловой системой SPIFFS.

Затем объявим функцию с именем listAllFiles, которая выведет список всех файлов файловой системы SPIFFS. В этой функции откроем корневой каталог « / », а затем будем перебирать все файлы, вызывая метод openNextFile. При обнаружении файла будем выводить в монитор порта имя текущего файла.

В основной функции setup() установим подключение к последовательному порту.

Затем подключим файловую систему SPIFFS, чтобы мы могли ее использовать.

После этого перечислим все файлы в файловой системе SPIFFS, прежде чем форматировать их.

Сейчас будем форматировать файловую систему, вызвав функцию SPIFFS.format(). Этот метод не принимает аргументов и возвращает в качестве вывода логическое значение, указывающее, была ли процедура успешной (true) или неудачной (false). Мы сохраним возвращенное значение для проверки ошибок.

И напоследок снова выведем в монитор порта список файлов в файловой системе SPIFFS, чтобы убедиться, что они действительно были удалены. Второй вызов должен выдать пустой список.

В итоге получим вот такой код удаления всех файлов из файловой системы SPIFFS на плате ESP32.

Проверка форматирования файловой системы SPIFFS на плате ESP32.

Чтобы проверить код, сначала откройте последовательный монитор Arduino IDE, чтобы убедиться, что не пропустили вывод программы. Затем скомпилируйте код и загрузите его в ESP32, предполагая, что у нас ранее были созданы файлы в файловой системе SPIFFS.

созданы файлы в файловой системе SPIFFS

В итоге должны получить результат, аналогичный показанному на рисунке ниже. Как видно, перед процедурой форматирования все файлы перечислены. После форматирования, ранее существовавшие файлы стираются, и поэтому ничего не выводится в монитор порта.

Проверка форматирования файловой системы SPIFFS на плате ESP32.

Обратите внимание, что процедура форматирования может занять некоторое время, поэтому вам придется подождать некоторое время, пока не будет выведен пустой список.

Вот такой простой способ поможет отформатировать файловую систему ESP32.

Понравился Урок ESP32 Arduino. Удалить все файлы. Форматирование SPIFFS? Не забудь поделиться с друзьями в соц. сетях.

А также подписаться на наш канал на YouTube, вступить в группу Вконтакте, в группу на Facebook.

Понятие хранения в программировании хранения включает в себя методы хранения данных для последующего использования. ESP32 имеет ОЗУ, но когда ESP32 выключен, содержимое ОЗУ теряется. Таким образом, нам нужен механизм, чтобы сделать это хранилище более постоянным. ESP32 обычно имеет доступ к флэш-памяти, которая электрически подключается через специальную шину SPI. Обычно размер флеш-памяти составляет 4 Мбайт. Мы можем получить доступ к флэш-памяти через SPI Flash API.

Содержание

Partition table

Архитектура ESP32 представляет собой концепцию, называемую таблицей разделов, которая в основном представляет собой «карту» или «Макет» того, что содержится во флэш-памяти. Таблица разделов находится в 0x8000 во флэш-памяти и имеет длину 0xC00 байт, что обеспечивает пространство для около 95 отдельных таблиц записей. Каждая запись в таблице имеет структуру записи, которая логически содержит:

  • type – The type of the partition. One of:
    • data
    • app
    • nvs – Used for non volatile storage.
    • phy
    • factory
    • coredump – Used to hold core dumps.
    • ota
    • fat – Used for the FAT file system.

    Таблица разделов доступна для наших приложений только для чтения и может получена с помощью API ESP-IDF. Таблица записывается во флэш-память при прошивке.

    Размер смещения является необязательным. Пустые смещения будут размещены смежно после предыдущих данных. Смещения выравниваются по 64 КБ.

    Инструмент под названием «gen_esp32part.py» доступен как часть инструментария для построения двоичных представлений таблицы. Мы можем построить двоичную таблицу из файла значений, разделенных запятыми, используя: $ Gen_esp32part.py -verify input_partitions.csv binary_partitions.bin

    Мы можем преобразовать двоичный файл обратно в CSV, используя:

    $ Gen_esp32part.py --verify binary_partitions.bin input_partitions.csv

    И мы можем перечислить содержимое двоичного файла, используя: $ Gen_esp32part.py binary_partitions.bin

    Таблица разделов, используемая вашим приложением, определяется командой make menuconfig в разделе Partition Table

    See also: • Partition API • esp_vfs_fat_spiflash_mount • esp_vfs_fat_register

    Non Volatile Storage

    Энергонезависимое хранилище - это память, которая может быть записана так, чтобы после выключения или перезапуска, те же данные могут быть прочитаны из него снова без потерь. В рамках этих данных мы можем хранить конфигурационные и эксплуатационные значения для наших приложений. Например, мы можем сохранить сетевой SSID и пароль таким образом, чтобы когда устройство перезапускается, он знает, к какой сети подключиться, и пароль для представления.

    Хранилище разделено на именованные области. Для данной именованной области мы можем сохранить и прочитать пару имя / значение в хранилище. Существуют функции getter / setter для большинства типов данных, включая целые числа с знаком и без знака, строки и двоичные данные.

    Именованная область открывается для доступа вызовом nvs_open (). Имя области передается как параметр. Нам возвращен логический «дескриптор», который мы впоследствии можем использовать для ссылки на эту область хранения. Как только мы получим дескриптор, мы можем записать и прочитать элементы именованных данных. Элементы данных ссылаются на имя ключа эффективно превращая область хранения в хэш-карту. Если мы изменим данные, выполнив функцию set, это не приведет к тому, что данные будут записаны в энергонезависимое хранилище. Вместо этого хранилище обновляется, когда мы вызываем nvs_commit (). Это зависит от внутренней реализации того, когда выполняется фактическое обновление, и это может произойти до nvs_commit (). Контракт заключается в том, что, когда мы возвращаемся из nvs_commit (), мы уверены, что все обновления обработаны. Когда мы выполнили все наши наборы и получили, мы должны вызвать nvs_close (), чтобы объявить, что мы больше не будем работать с хранилищем в это время, чтобы время выполнения могло очистить любые ресурсы, которые он мог открыть.

    Детали алгоритмов, используемых для управления NVS, раскрываются в документации. Цель NVS на высоком уровне - хранить простые строки и целые числа и другие флаги, а не быть богатой структурой «файловой системы». В настоящее время дефрагментация не выполняется в хранилище.

    Virtual File System

    Виртуальная файловая система (VFS) - это архитектура, предоставляемая ESP-IDF, которая дает нам возможность сохранять и загружать данные из наших приложений с использованием ввода-вывода файловой системы.

    VFS не привязан к какой-либо одной конкретной технологии, а вместо этого является архитектурной абстракцией, используемой для обеспечения интерфейса ввода-вывода для множества различных реализаций.

    Ключом к VFS является тип данных, называемый esp_vfs_t. Эта структура содержит следующее:

    • fd_offset –
    • flags – Operational flags. Use ESP_VFS_FLAG_DEFAULT.
    • close/close_p – Close a previously opened file.
    • closedir/closedir_p – Close a previously opened directory.
    • fstat/fstat_p – Get stats/details of a file.
    • link/link_p – Create a new link to a file.
    • lseek/lseek_p – Change the data pointer within a file.
    • mkdir/mkdir_p – Create a new directory entry.
    • open/open_p – Open a named file.
    • opendir/opendir_p – Open a directory for reading.
    • read/read_p – Read the contents of a file.
    • readdir/readdir_p – Read a record from a directory.
    • rename/rename_p – Rename a file.
    • rmdir/rmdir_p – Delete a directory entry.
    • seekdir/seekdir_p – Set the position of the next readdir().
    • stat/stat_p – Get stats/details of a file.
    • telldir/telldir_p – Return the current direction stream.
    • unlink/unlink_p – Remove a file.
    • write/write_p – Write into a file.

    После заполнения структуры нам необходимо зарегистрировать нашу новую виртуальную файловую систему с вызовом esp_vfs_register ().

    Нам нужно знать, что предполагаемый вызывающий файл ввода-вывода ожидает среду, похожую на POSIX.

    See also: • esp_vfs_register • Virtual filesystem componen t

    VFS Implementations

    Поскольку VFS предоставляет архитектурную модель, нам необходимо рассмотреть ее фактические реализации. По состоянию на 2016-11 реализаций пока нет. Первыми ожидаемыми реализациями будут файловые системы, хранящиеся во флэш-памяти. Они будут обеспечивать постоянное хранение данных через API файлов. Первыми кандидатами на реализацию являются FAT и/или SPIFFS.

    Мы также можем создавать собственные специализированные реализации. Одной из интересных идей - позволить ESP32 быть сетевым клиентом внешних файловых систем. Например для:

    Может показаться странным иметь доступ к данным сетевого устройства через файловый механизм только для того, чтобы он затем обрабатывал запросы в качестве другого сетевого вызова . однако могут быть преимущества. ESP32 может кэшировать полученные данные либо в ОЗУ, либо в локальной флэш-памяти и выполнять только внешние сетевые запросы, если запрашиваемые данные недоступны в другом месте.

    При работе с файловыми вводами-выводами мы можем использовать механизмы файлов потоков, импортированные через «stdio.h», или использовать ввод / вывод файлов нижнего уровня, импортированных через «fcntl.h».

    FATFS File System

    Файловая система FatFs представляет собой реализацию файловой системы FAT / exFAT, как показано в более ранних операционных системах ПК, таких как MS-DOS и ранние версии Windows (до FAT32 и NTFS).

    Реализация является открытым исходным кодом и поставляется «предварительно перенесенной» в ESP32 как часть дистрибутива ESP-IDF. Отображение ESP-IDF для FATFS сопоставляет файловую систему с функциями posix IO. Это означает, что нам не нужно изучать какие-либо специальные API-интерфейсы для чтения и записи файлов. Мы можем использовать функции open (), close (), read (), write () и другие методы, открытые через виртуальную файловую систему.

    Прежде чем мы сможем использовать эти API, нам нужно выполнить предварительную настройку.

    1. Вызовите esp_vfs_fat_register
    2. Вызовите ff_diskio_register
    3. Вызовите f_mount
    1. Закройте все открытые файлы
    2. Вызвать f_mount с помощью NULL
    3. Вызовите ff_diskio_register с помощью NULL
    4. Вызовите esp_vfs_fat_unregister

    По умолчанию имена файлов ограничены старым форматом 8.3 (короткие имена), однако, если мы выберем, мы можем включить длительное управление именами файлов в настройках make menuconfig.

    • FatFS – Generic FAT File System Module
    • Virtual File System
    • FatFs file system

    Spiffs File System

    Файловая система SPI (SPIFFS) - это механизм файловой системы, предназначенный для встроенных устройств. Чтобы настроить SPIFF, нам нужно определить некоторые числа. Во-первых, это размер физической страницы. Далее следует размер физического блока. Затем мы определяем размер логического блока. Это будет некоторый целочисленный множитель размера физического блока.

    Вся файловая система SPIFFS должна быть кратной размеру логического блока. Далее следует размер логической страницы, который является некоторым множителем размера логического блока.

    Общий размер ESP32 составляет 64 КБ для размера логического блока и 256 для размера логической страницы.

    Чтобы было ясно, 1 блок - это n x страниц.

    Когда выполняется вызов API SPIFFS, нулевой или положительный ответ указывает на успех, а значение <0 указывает на ошибку. Характер ошибки можно получить через вызов SPIFFS_errno (). Реализация SPIFFS не обеспечивает прямой доступ к флэш-памяти. Вместо этого функциональная область, называемая уровнем абстракции оборудования («hal»), предоставляет эту услугу. Для интеграции SPIFFS необходимо создать три функции, которые имеют следующие заголовки:

    В случае успешного выполнения, код возврата SPIFFS_OK (0). На ESP32 они будут сопоставляться с API-интерфейсами SPI.

    Чтобы использовать файловую систему SPIFFS, мы должны выполнить вызов SPIFFS_mount (). В результате создается структура конфигурации, которая сообщает SPIFFS, сколько флэш-памяти доступно и множество других свойств. Кроме того, некоторые рабочие хранилища должны быть выделены для различных внутренних операций. Эти размеры могут быть настроены. Ниже приведен пример конфигурации для установки файловых систем:

    После того, как мы установили файловую систему, мы можем открыть файл, записать в него контент и закрыть его. Например:

    Аналогично, если мы хотим прочитать данные из файла, мы можем выполнить следующее:

    Использование файловой системы SPIFFS может быть иерархической по своей природе, так что она содержит как каталоги, так и файлы, но, похоже, на самом деле это не так. Существует только один каталог с именем root. Корневой каталог - «/». Чтобы определить членов каталога, мы можем открыть каталог для чтения с помощью API SPIFFS_opendir (), и, когда мы закончим, закройте операцию чтения с помощью вызова API SPIFFS_closedir (). Мы можем пройти через записи каталога с вызовами SPIFFS_readdir ().

    Чтобы это стало ясно, в Linux, если мы создали «/a/b/c.txt», это обычно создало бы файл c.txt в каталоге с именем «b» в каталоге с именем «a». В SPIFFS это фактически создает один файл с именем «/a/b/c.txt», где символы «/» являются просто частью имени файла. Когда мы выполняем SPIFFS_opendir (), на самом деле нет структуры каталогов, а всего лишь один плоский список ВСЕХ файлов, которые могут иметь или не иметь «слэши» в их именах. Чтобы создать файл, мы можем использовать API SPIFFS_open (), предоставив флаг SPIFFS_CREAT.

    • SPIFFs API
    • Github: pellepl/spiffs
    • Github: igrr/mkspiffs – The mkspiffs tool.
    • SPI Flash
    • Virtual File System mapping to SPIFFS

    Building SPIFFs for the ESP32

    Под заголовком «"let's build on each other» была проделана отличная работа портирования SPIFF в ESP32 командой LUA (Jaume Olivé Petrus). Исходный код можно найти на github. Они упаковали его как компонент ESP-IDF.

    mkspiffs tool

    В дополнение к фантастической библиотеке SPIFF существует также инструмент под названием «mkspiffs», который может принимать структуру каталогов в вашей файловой системе и создавать из него образ SPIFF, который затем может быть загружен во флэш-память для предоставления предварительно загруженных данных.

    Можно скачать репозиторий Git для mkspiffs и скомпилировать его. Я не обнаружил проблем и скомпилировал их с первого раза.

    • -c <directory to pack>
    • -u <dest to unpack into>
    • -l – list content
    • -i – visualize content
    • -b <number> – Block size in bytes (for example 65536)
    • -p <number> – Page size in bytes (for example 256)
    • -s <number> – fs image size in bytes.

    В результате получим файл образа:

    Когда у нас есть файл образа, чтобы его загрузить выполняем:

    See also: • Github: igrr/mkspiffs – The mkspiffs tool.

    The ESP File System – EspFs

    В рамках проекта есть утилита под названием «mkespfsimage», которая принимает во вход набор имен файлов и потоков в качестве вывода данных изображения, которые должны быть свернуты. Например:

    (Обратите внимание, что проект имеет возможности сжатия, которые я игнорирую на данном этапе).


    После того, как данные находятся во флэш-памяти, мы можем затем использовать API-интерфейсы, предоставленные компонентом, для выполнения базового доступа к данным:

    • EspFsInitResult espFsInit(void *flashAddress)
    • int espFsFlags(EspFsFile *fh)
    • EspFsFile *espFsOpen(char *fileName)
    • int espFsRead(EspFsFile *fh, char *buff, int len)
    • void espFsClose(EspFsFile *fh)

    Была предпринята попытка портировать код для использования технологий ESP32 и можно найти здесь.

    Это добавляет новую функцию:

    • int espFsAccess(EspFsFile *fh, void **buf, size_t *len)

    Эта функция возвращает указатель на весь контент файла, который хранится в buf.

    Длина файла сохраняется в len, а также возвращается из функции в целом.

    Доступ к данным осуществляется непосредственно из flash без каких-либо копий ОЗУ.

    Кроме этого, необходимо выделить память:

    • EspFsInitResult espFsInit(void *flashAddress, size_t size)

    Вот пример приложения:

    SD, MMC and SDIO interfacing

    Secure Digital (SD) является стандартом для съемных носителей. Эти устройства также известны как «флеш-карты» или «SD-карты». Идея состоит в том, что SD-карта содержит данные, которые могут считываться и записываться. Карты SD хранят данные как необработанную память, и обычно создается файловая система, которая живет поверх данных. Обычно используются форматы файловой системы FAT16 и FAT32. Карты SD имеют различные физические размеры и с различными возможностями и скоростью.

    Карты бывают трех размеров, известные как «SD», «miniSD» и «microSD», от самых больших до самых маленьких.

    В зависимости от емкости карты делятся на три типа:

    • SD - до 2GB (FAT12 / FAT16)
    • SDHC - до 32Gb (FAT32)
    • SDXC - до 2Tb (extFAT) - не поддерживается

    Дополнительной характеристикой SD карты является скорость. Карты делятся на классы:

    • Class 2 2MB/s
    • Class 4 4MB/s
    • Class 6 6MB/s
    • Class 10 10MB/s

    Спецификация SD является большой и всеобъемлющей. Если бы мы сами попытались реализовать спецификацию SD, мы бы рассмотрели целый ряд головоломок. Как таковой, распространено использование ранее существовавших реализаций спецификации, и, к счастью, ESP-IDF предоставляет нам именно это.

    Существует также отличное примерное приложение, представленное в каталоге examples / storage / sd_card ESP-IDF.

    Карта SD может использоваться для хранения данных, но не может использоваться для хранения кода команды для выполнения. Таким образом, SD-карта не должна рассматриваться как альтернатива флэш-памяти, доступной через SPI для хранения кода. SD-карту следует использовать для хранения данных приложения, которые могут быть прочитаны или записаны при запуске приложений.

    Читайте также: