Работа с блоками данных переменной длины, Изменение типа, удаление, добавление Опции

[SZ0]

Стоит задача.
Обработка блоков данных, при этом блоки могут быть разных размеров, у каждого блока 1й байт определяет его тип, по которому мы знаем его размер. Любой блок может быть стёрт или изменён на другой тип.

Проблема и решения.
Перемещение на N блок для его обработки: номер блока собираюсь расчитывать от 1го, т.е. узнаем размер 1го, перешли ко 2му, узнали его размер и так далее.
Стирание блока: выясняем размер по типу следующего за ним блока, сдвигаем на пустое место которое очистил блок, потом следущий за ним и так до последнего блока.
Изменения типа: перед изменением программа оценивает сколько памяти осталось, и в зависимости от выбранного нового типа блока все блоки после изменнённого либо отодвигаются от него либо пододвгаются к нему.

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

Данные будут размещаться в РАМ ATmega2560 и там же обрабатываться, и все сохраняться/считываться из его eeprom при запуске
и сохраняться после настройки в РАМ.

[one_man_show]

Какой максимальный размер блока? Может все-таки внести избыточность, то есть сделать все блоки одинаковой длины, за счет этого упростить алгоритм...

[SZ0]

Какой максимальный размер блока? Может все-таки внести избыточность, то есть сделать все блоки одинаковой длины, за счет этого упростить алгоритм...

Не хотел писать , а надо было.

Первоначально так и было, все блоки одинаковой длинны, и алгоритм обработки прост. Максимальный размер 86 байт, а внутренняя стурктура определялась по 1у байту идентификатора. И обращаться к любому блоку с такой стрктурой просто. Но заказчику стало мало, потребовалось создавать большее количество блоков, например меньших размеров (минимальный 8 байт) и больше гибкости в управлении блоками. Внешняя РАМ исключена, т.к. все ножки проца заняты.

[SysRq]

Ну.. Заложить под каждый из типов объектов свой pool, исходя из наверняка прикидываемого количества объектов каждого типа. Управлять на основе списка структур, в которых на расположение объекта в pool только ссылаться.

[Guest_@Ark_*]

Стоит задача.
Обработка блоков данных, при этом блоки могут быть разных размеров, у каждого блока 1й байт определяет его тип, по которому мы знаем его размер. Любой блок может быть стёрт или изменён на другой тип...

Если по-проще, то сразу закладывайтесь на блоки фиксированного размера. Размер блока нужно выбирать кратным 2^N (чтобы проще было вычислять адреса) и таким, чтобы его легко можно было обрабатывать - помещать во временный буфер, копировать, перемещать. Не слишком большим и не слишком маленьким. Выбирайте из ряда: 16, 32, 64, 128, 256 байт/на блок. Одна запись будет занимать один или несколько блоков.
Нужно зафиксировать формат блока и предусмотреть в нем признаки первого блока записи, количество блоков, признак пустого блока (напр.: кол-во блоков записи=0), контрольную сумму- ессно! Если необходимо сохранить определенный порядок при удалении/вставке записей, введите в формат данных указатель на следующую запись.
Размещаете записи последовательно. Каждая должна начинаться с нового блока. Дописываете новые записи в конец (нужен указатель начала свободной области). При удалении записи объявляете блоки пустыми, но ничего не сдвигаете. Сборкой мусора занимаетесь только когда исчерпаете свободную область.
Не очень все будет эффективно (особенно поиск), но зато обойдетесь без таблицы размещения.
В конце-концов Вы просили как по-проще...

[DpInRock]

А я бы остановился на алгоритме первоначальном.
Он, несмотря на кажущуюся неэффективность - лучший. Потому что дубовый. Стопроцентный.
Т.е. не требует какой-то отладки и поиска ошибок.

Единственное - скорость не слишком. И то - не факт.

[one_man_show]

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

[MMos]

У одного персонажа детской литературы (медика по профессии) был универсальный рецепт: "Касторка и йод!" Автору вопроса я бы в подобном стиле прописал: "Кластеры и таблица размещения!" Для более подробного совета нужна дополнительная информация.

[SZ0]

Если не секрет, раскройте бюджет проекта.

Бюджет не я устанавливаю, я только ПО пишу на заказ.

[one_man_show]

Понимаю. Спросил, чтобы понять, рентабельно ли напрагяться поднимать сложный алгоритм доступа к данным. С опытом выработался подход, при котором ценишь свое время то есть при стоимости изделия в пределах ста зеленых не имеет смысла "городить огород", проще подвести Заказчика к мысли, что для его аппетитов нужно делать новую железку. Не всегда срабатывает, но тем не менее...

[SZ0]

я бы в подобном стиле прописал: "Кластеры и таблица размещения!" Для более подробного совета нужна дополнительная информация.

Всё и подходит к таблицам размещения. Но кажется приближаемся в обсуждениях к жёсткой фиксации блоков в памяти разбивая их сразу по типам на начальном этапе, что должно упростить задачу.