Расширение флеш-памяти

[pvvx]

> print(node.heap())
19472
Всю можно использовать? Если так то выжить можно кое как. Все таки не 4 кб.

Нет - надо оставить буфер для приема-передачи блоков по WiFi, а то упадет при соединении и т.д. Оптимальный мининум - 10 кбайт.

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

Файлы исходников работы с Flash датируются "* copyright (c) Espressif System 2010" - годом. Это первое и второе - ничего Espressif не исправит, если там что-то не то. Всё надо делать самим, а не попрошайничать.

 

[Victor]

Вышли NodeMCU прошивки с поддержкой 1, 2 и 4M

 

[pvvx]

Вышли NodeMCU прошивки с поддержкой 1, 2 и 4M

Как это понять? Поддержка до 16Mегобайт и так должна была быть изначально. Что - NodeMCU исправили свой собственный баг?
Или они проверили и указали какие типы flash гарантированно работают?

 

[Victor]

Как это понять? Поддержка до 16Mегобайт и так должна была быть изначально. Что - NodeMCU исправили свой собственный баг?
Или они проверили и указали какие типы flash гарантированно работают?

Для каждого размера - своя прошивка.

Проблема, видимо, в SDK - есть такой файл esp_init_data_default.bin в котором хранятся значения по умолчанию для старта SoC. Так вот, его расположение в прошивках для разного размера памяти разное.

Ну а если залить прошивку для 1М памяти в модуль с 2М памяти, похоже что прошивка не только не будет использовать память свыше 1М, но и вообще может не стартануть. Но это догадки, нужно пробовать на реальном модуле с увеличенной памятью.

 

[pvvx]

А каков смысл увеличения программного кода, если для него за глаза хватает 512кб?
(единственное что там требуется - вынос из этой зоны сегментов сохранения всяческих пользовательских данных)
Конкретнее:
При использовании flash для хранения своей информации ничего делать не требуется.
Все процедуры, работающие записью/чтением flash, работают с таком порядке:
Cache_Read_Disable();
свои дела();
Cache_Read_Enable();
Код программ, загрузчиков, как был в первом разделе (512к) так и пусть сидит там, а область сохранения данных просто выноситься за этот раздел.
Даже если в начальной области имеется разметка, загружаемая для работы с flash, то указав там навсегда, что flash у нас 16Mб получаем доступ к любому подходящему размеру чипа...

 

[Victor]

А каков смысл увеличения программного кода, если для него за глаза хватает 512кб?

NodeMCU поддерживает хранение файлов. Там почти настоящая файловая система. Можно хранить скрипты на LUA (которые потом, разумеется, можно запустить) или данные.

 

[pvvx]

NodeMCU поддерживает хранение файлов. Там почти настоящая файловая система. Можно хранить скрипты на LUA (которые потом, разумеется, можно запустить) или данные.

Я уже понял. Это же надстройка над настройкой, именуемая NodeMCU. Т.е. язык высокого уровня, занимающийся перестановкой бит в регистрах процессора (Мер города, который по жалобе каждого пользователя собственными руками чинит протекший кран - переизберут однозначно, т.е. язык умрет).

 

[Victor]

Я уже понял. Это же надстройка над настройкой, именуемая NodeMCU. Т.е. язык высокого уровня, занимающийся перестановкой бит в регистрах процессора (Мер города, который по жалобе каждого пользователя собственными руками чинит протекший кран - переизберут однозначно, т.е. язык умрет).

Возможно вы и правы, но всё же это спорный вопрос. Для себя и для дома - самое то. Не писать же отдельную прошивку для отправки показаний одного DS1820 Никаких тебе заморочек с SDK и компиляторами. Скрипт в 20 строк и получен желаемый результат.

Да и язык высокого уровня проще изучать новичкам, особенно тем, для кого работа с микроконтроллерами лишь хобби в свободное время. Кроме того, LUA сейчас активно используется в IoT.

Так что как знать...

 

[pvvx]

Возможно вы и правы, но всё же это спорный вопрос. Для себя и для дома - самое то. Не писать же отдельную прошивку для отправки показаний одного DS1820 Никаких тебе заморочек с SDK и компиляторами. Скрипт в 20 строк и получен желаемый результат.

Да и язык высокого уровня проще изучать новичкам, особенно тем, для кого работа с микроконтроллерами лишь хобби в свободное время. Кроме того, LUA сейчас активно используется в IoT.

Так что как знать...

Вы немного не поняли меня, т.к. я пропустил промежуточные предложения для сокращения текста. Да и ладно.
(Смысл описать сходу мне сложно - я не писатель и не журналист, но он в том, что уже есть базовые методы, отлаженные, в низкоуровневом ПО. А надстройщики плодят протоколы над протоколами. Так рождаются новые никчемные протоколы, во первых по началу содержащие кучу ошибок и требующие отладки, во вторых нужные только ради этой надстройки и язык превращается в ассемблер. Игра ради игры. В итоге он расширяется по нишам и отмирает. Так произошло со многими языками. Бэйсик, Java к примеру... )

Вернемся к нашим баранам. В SDK есть такая структура:
typedef struct{
uint32 deviceId;
uint32 chip_size; // chip size in byte
uint32 block_size;
uint32 sector_size;
uint32 page_size;
uint32 status_mask;
} SpiFlashChip;

Она объявлена в esp_iot_sdk/include/spi_flash.h, данные очень похожи на данные, считываемые из внутренних параметров самой flash, но не дано ни одной процедуры, которая работает с ней или выдает её. Явно потерли, а эти процедуры “засикретили”.
С ней работает какая-то из процедур, описанных в esp_iot_sdk/ld/eagle.rom.addr.v6.ld
Да и вышел новый SDK 0.9.4 - ща буду разбираться... и до них дошло, что espconn кривая в tcp...
Включили uint32 spi_flash_get_id(void); и так известную. На этом с flash в SDK 0.9.4 больше ничего не добавили.

 

[brig]

Произвел тестирование новых прошивок LUA nodeMCU (0.9.2 build 2014-12-19) на своем модифицированном модуле. Пока не впечатляет. Разработчик не обеспечил использование всей доступной области флеш-памяти и не избавился от косяков при переполнении (якобы) этой области. Отчет здесь.

 

[pvvx]

Произвел тестирование новых прошивок LUA nodeMCU (0.9.2 build 2014-12-19) на своем модифицированном модуле. Пока не впечатляет. Разработчик не обеспечил использование всей доступной области флеш-памяти и не избавился от косяков при переполнении (якобы) этой области. Отчет здесь.

А толку?
Откройте проект и напишите:

extern SpiFlashChip * flashchip;

if(flashchip != NULL) os_printf("FlashID: 0x%08x\nChip size: %d\nBlock size: %d\nSector size: %d\nPage size: %d\nStatus mask: 0x%08x\n",
flashchip->deviceId, flashchip->chip_size, flashchip->block_size, flashchip->sector_size, flashchip->page_size, flashchip->status_mask );
else os_printf("Unknown Flash type!\n");
Получите:
FlashID: 0x001640ef
Chip size: 524288
Block size: 65536
Sector size: 4096
Page size: 256
Status mask: 0x0000ffff
Это всё, что знает система о вашей flash. Команды чтения и записи не проходят за пределы размера flash и выдают ошибку.
Писатель LUA nodeMCU наверняка об этом всём не знает.

 

[brig]

Откройте проект и напишите:

Я бы с удовольствием, но, к сожалению, телепатом не являюсь.

Это всё, что знает система о вашей flash.

А что ещё требуется (кроме знания принципиальной схемы устройства)?

Писатель LUA nodeMCU наверняка об этом всём не знает.

Сомнительно. Ему тогда вообще не удалось бы адаптировать стороннюю библиотеку для работы с файлами на SPI-флеш памяти данного модуля...

 

[pvvx]

Сомнительно. Ему тогда вообще не удалось бы адаптировать стороннюю библиотеку для работы с файлами на SPI-флеш памяти данного модуля...

В исходниках nodeMCU ничего по данному поводу нет, кроме жесткого переключения адреса сохранения для разных версий Т.е. никакой проверки и поддержки в 'биосе' (встроенной ROM в чип) для записи/чтения flash там не осуществляется.

 

[brig]

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

 

[pvvx]

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

Надейтесь. Мне заказ флэшек и новых модулей ещё не пришел.
А пока единственная программа, которая говорит о размере flash и дает её считать и другие потроха - эта: https://yadi.sk/d/h5DdeGxSdYyaD

 

[pvvx]

Чтение закэшированной области Flash (отображаемой в область памяти) блоками более определенного размера (что-то более 2500 байт вроде - уже забыл) вызывает protected. Если в Nodа-х - MCU-уах - Lua-х чтение идет из области кэша flash, то это ещё одна беда для больших flash. Так сделано у многих...

 

[brig]

беда для больших flash

Чем "большая flash" отличается от "небольшой flash" с точки зрения доступа к данным в данной системе?

 

[pvvx]

Чем "большая flash" отличается от "небольшой flash" с точки зрения доступа к данным в данной системе?

Областью кеширования. Если вы не знаете программирования + архитектуры данного чипа + его биоса + аппаратных фичей, то объяснять это будет долго - на пару томов потянет...
Я читаю flash по SPI, а многие по адресному пространству, куда она кешируется программно-аппаратно. Но эти области надо задавать. Для этого требуются полные знания по архитектуре чипа и его регистров. Так что ждите, когда ко мне придут новые модули и большие flash и я займусь этим
А пока рассчитываем на вас, что напишите всем (в том числе и писателям фишек с Lua) как им читать и управлять разными flash. У вас же есть уже большая flash.

 

[brig]

Областью кеширования.

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

А пока рассчитываем на вас, что напишите всем (в том числе и писателям фишек с Lua) как им читать и управлять разными flash.

В какой системе программирования?

 

[pvvx]

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

Значит вы не знаете как работает ESP8266EX.
У любого современного процессора есть кэш. Из него и выполняется программа и через неё пересылаются данные. При чем тут размер ОЗУ?
Flash он читает блоками в OЗУ, предназначенную для её кэширования. Достаточно памяти ОЗУ на один сектор flash. Память нужна т.к. не изготавливают ещё серийной flash со скоростью передачи данных для проца MCU работающего на частоте более 80MHz (а у головы ESP8266 - 160MHz) или она будет золотая (или требуется интерфейс с сотнями ног для распараллеливания потока на дцать flash чипов). Но там не всё хорошо реализовано с перехватом выхода адреса за пределы блока - по этому непрерывное чтение вызывает ошибку protected...
Обращайтесь к изготовителю SDK и чипа

В какой системе программирования?

Для ESP8266 есть SDK. Больше пока ничего. Остальное, всё что налеплено на нем - или не работает или виснет и не годится для использования. Народ кинулся писать всякое, не доделав базовый SDK и не изучив сам чип. Надеюсь вы нам подскажите, что там надо поменять и исправить, чтобы поддерживал большую flash.
Что куда и как ремапится в адресном пространстве сообщество ещё изучает https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map
Но там многое неверно. Для исследования я написал web читалку памяти...