2017-01-16 18 views
2

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

[n bytes address1][data1][data2][data3] 
[n bytes address2][data1][data2] 
[n bytes address3][data1][data2][data3][data4][data5][data6] 

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

Какое оптимальное решение для этой задачи?

Работаю с avr atxmega.

+0

Какова максимальная и минимальная длина записи? Сколько записей? –

+0

около 3000 записей и минут около 40, а max - 80 байт, и я использую внешнюю память, но моя проблема в организации. как легко найти и получить доступ к записям – ZonderComand

+0

У вас, вероятно, есть 3000x80 байт, я бы, вероятно, сделал все записи 80 или, может быть, 128 байт, чтобы выровнять их с потенциальными границами страниц. Как «поиск» записей зависит от того, что вы ищете. Я не думаю, что какая-то сортировка имела бы смысл, но, возможно, какая-то индексация/маркировка/группировка. –

ответ

2

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

Также остерегайтесь секторов. Секторы - это самая маленькая группа для стирания. Если ваши данные превышают границу сектора, это может привести к поломке данных.

+1

Хорошая точка зрения на проблему стирания сектора, но на устройствах AVR EEPROM - это стирание байта/запись, поэтому это не должно быть проблемой. Помимо этого я согласен с тем, что это простой подход, но только длина записи не слишком сильно отличается. –

0

Фрагментация памяти имеет тенденцию быть гораздо менее проблематичной, если вы реализуете алгоритм «наилучшего соответствия» для (идеально, полностью) повторного использования «дыр» вместо «первого соответствия» (вы будете торговать скоростью для эффективность). В случае, если ваши данные имеют определенную степень детализации (похоже, это так), вы можете работать довольно эффективно.

Организовать пустую области в EEPROM с помощью связанного списка свободного, и убедитесь, что вы обыскать весь список свободного для областей, где часть данных, которые вы хотите сохранить приспосабливает точно, или в пределах определенного допустимого края накладных расходов , Если вы не можете найти такую ​​область, используйте самую большую свободную область. Это серьезно сокращает (если не позволяет избежать, в зависимости от ваших данных) фрагментацию.

0

Существует несколько подходов, выбор зависит от размера EEPROM, максимального количества записей (обозначим через N) и максимального размера записи (пусть это будет S): Первый подход довольно очевиден: if (N * S) < = свободный размер EEPROM, тогда вы можете просто выделить равные блоки максимального размера для каждой записи. Например, если размер EEPROM равен 2048, а каждая запись имеет максимальный размер 31 байт и не более 64 записей, вы можете выделить 64 записи по 32 байта каждый, используя первый байт, чтобы обозначить размер записи.

Если размер каждой записи может варьироваться в широком диапазоне, или общее количество не определено (Вы хотите ель как можно больше), то есть два фрагментации подходов:

1) дефрагментация данных. Каждый раз, когда нет непрерывного блока требуемого размера, вы будете перемещать все данные, пока не будет свободного блока требуемого размера.

Например, если размер записи варьируется в пределах 127 байт, вы можете использовать первый байт для обозначения типа и размера блока. Например. старший бит равен 1 - когда блок свободен, 0 - если он содержит данные. Более низкие 7 бит содержат размер блока. Этот подход достаточно хорош, но поскольку данные перемещаются, может потребоваться соответствующим образом обновить все ссылки на данные.

2) Храните данные фрагментированными. Вы можете выделить количество блоков определенного размера (например, 32 байта каждый = максимум 64 записи для EEPROM 2048 байт). Первый будет содержать индекс блока, где данные продолжаются, скажем, 0xFE - значение для последнего блока в цепочке, 0xFF - для обозначения пустого блока. Остальные 31 байт блока содержат данные. Это может сделать процесс чтения несколько более сложным, но местоположение данных для каждой записи будет неизменным в течение целого периода времени.

+0

wow спасибо! это очень хорошее решение, используя первый байт! – ZonderComand