одном устройстве возникла необходимость предоставить высокоуровневый API для работы с Flash памятью. Предположительно это будет доступ как к файлам (но возможно и что-то более простое)
доступ к Flash:

1) Запись данных можно осуществить только в стертый участок. Например если есть 0xFF (стертый байт), то на это место можно записать любой байт. Если есть байт, отличный от 0xFF (например 0x11) то можно гарантированно записать только 0x0 (т.е. всегда можно записать бит 0 вместо бита 1)
2) можно стереть только целый банк фиксированного размера (в данном случае 128КБ)
3) стирание осуществляется достаточно медленно

Проблема:
1) Предоставить досту к Flash как к файлам с возможностью дописывания, стирания и замены
2) Доступно только около 16КБ ОЗУ

Нужен алгоритм и структуры данных для поддержания такой системы
---
язык реализации С, RISC процессор

WA>1) Предоставить досту к Flash как к файлам с возможностью дописывания, стирания и замены

Видимо, тут нужны подробности. В моём понимании того, что тут написано (замена — это перезапись заданного куска?), я вообще не вижу решения поставленной задачи. Что, если я запишу один банк (например, программно генерируемыми данными), а затем захочу сделать замену первых 16Кб в каждом 32Кб-куске (опять же программно генерируемыми данными)? На это просто оперативки не хватит.

Здравствуйте, Аноним, Вы писали:

А>Видимо, тут нужны подробности. В моём понимании того, что тут написано (замена — это перезапись заданного куска?), я вообще не вижу решения поставленной задачи. Что, если я запишу один банк (например, программно генерируемыми данными), а затем захочу сделать замену первых 16Кб в каждом 32Кб-куске (опять же программно генерируемыми данными)? На это просто оперативки не хватит.
подробностей особых нет, по поводу 32КБ и оперативки. 16Кб оперативной памяти доступно для той части кода, которая выполняет функции ОС (доступ к Flash и другой переферии) клиентский код имеет около 2МБ, но использовать эти 2МБ в ОС не хотелось бы
а пролема решаема — пример тому FFS (Flash File System)
по поводу замены — всегда можно скопировать весь банк на новое место с измененным содержанием, а предыдущий кусок стереть.

Здравствуйте, WiseAlex, Вы писали:

WA>Проблема:
WA>1) Предоставить досту к Flash как к файлам с возможностью дописывания, стирания и замены
WA>2) Доступно только около 16КБ ОЗУ

WA>Нужен алгоритм и структуры данных для поддержания такой системы

Если половины FLASH памяти не жалко — есть тупое решение, не требующее большого объема ОЗУ : разделить всю память на 2 половины, если надо перезаписать кластер — копируем его в противоположную половину, а потом стираем старую информацию. Определить, где пустой кластер, а где — информация, можно при загрузке системы, сравнив содержимое кластеров в каждой паре. ОЗУ для такого уродца надо только для хранения таблицы занятых кластеров (по биту на кластер).

Здравствуйте, Fedor Novikov, Вы писали:

FN>Если половины FLASH памяти не жалко — есть тупое решение, не требующее большого объема ОЗУ : разделить всю память на 2 половины, если надо перезаписать кластер — копируем его в противоположную половину, а потом стираем старую информацию. Определить, где пустой кластер, а где — информация, можно при загрузке системы, сравнив содержимое кластеров в каждой паре. ОЗУ для такого уродца надо только для хранения таблицы занятых кластеров (по биту на кластер).
C одной стороны жалко, а с другой — стирание и запись таких объемов будет длиться долго (каждый банк стирается последовательно и около 1с)
В любом случае получаем очень быстрый износ памяти — количество стираний ограничено