LINUX.ORG.RU

avr & eeprom_update_block()

 ,


0

1

день добрый, товарищи колдуны!

#include <avr/eeprom.h>
eeprom_update_xxx()     // - набор функций для типов byte,dword,float,word
eeprom_update_block()   // - работа с "блоком памяти"

если с 1м набором функций все понятно: - обновление/запись «области eeprom»/кастомного типа происходит, если данные не совпадают

по поводу 2го типа - не совсем понятно. допустим имеется структура

typedef struct 
{
uint8_t  a;
uint16_t b; 
uint32_t c;
} TSet;

то при вызове «апдейта», в случае неравенства одного из полей структуры - будет обнавлен только «одно» поле, или вся структура?! судя по описанию - обновиться/будет перезаписана вся структура.

за удобство загрузки/сохранения одним махом целой структуры - я не говорю, реально удобно! НО...получается, что если есть необходимость поотдельно работать с полями структуры, и менять периодически значения (не все сразу), то в данном случае eeprom_update_block() является не очень эфективным (в плане циклов перезаписи ячеек памяти)?!

обычно я сам составляю карту EEPROM, сам расчитываю указатели к переменным и, следовательно, не имею «указанных» проблем, обращаюсь напрямую, читаю/пишу/обновляю переменные «персонально».

сейчас решил разобраться более детально, ну и «удобства - скопом за раз» читать/сохранять структуры очень заманчиво!

какие будут мнения по этому поводу?! спасибо.

p.s. уточнение: чтени/перезапись идет во внутр. цикле побайтно! тут все понятно! URL
что по поводу оптимального доступа к отдельный полям структуры (имеется в виду - запись/обновление в eeprom)?

★★★★

Последнее исправление: sunjob (всего исправлений: 3)

Ответ на: комментарий от anonymous

да, побайтно во внутреннем цикле! спасибо p.s. уже наткнулся url

что по поводу оптимального доступа к отдельный полям структуры (имеется в виду - запись в eeprom)?

sunjob ★★★★
() автор топика
Последнее исправление: sunjob (всего исправлений: 4)
Ответ на: комментарий от anonymous

подробно:

записи байта

про это я сразу обновил информацию

теперь меня интересует вот что (совсем подробно)
загрузили даные из eeprom в структуру TSet

как теперь можно обновлять «изменения» сделанные в «конкретном одном поле», не использую общую функцию eeprom_update_block()

если не понятно, еще подробнее:

TSet set;
eeprom_read_block();
...
set.a = 10;
...
eeprom_update_byte(set.a); // ???

я, конечно, понимаю, что данные распологаются последовательно в eeprom, но вот сам EEMEM имеет «особенность» оптимизировать расположение данных/структур в памяти на свое усмотрение. если структур несколько и они «достаточно большие и разношерстные», то заранее неизвестно как они будут расположены в памяти, в каком порядке (и, возможно (*), внутреннее расположение будет тоже оптимизировано)

(*) - вот тут я и немного неуверен/сомневаюсь. по идее, можно к адресам полей структуры обращаться по смещению (если данные будут распологаться без «неизвестной оптимизации» (*))

так понятнее?! клацал по телефону, накатал как есть... :о)

п.с. еще раз подчеркиваю, что если нет «особой внутренней оптимизации» расположения и данные структуры идут последовательно, то, вообщем, вопросов нет, обращаемся как к массиву / по смещению.

sunjob ★★★★
() автор топика
Ответ на: комментарий от sunjob

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

адрес поля будет, например, таким: my_sruct_ee_addr + (char*)&my_struct.field - (char*)&my_struct

а насчёт времени: чтение из eeprom происходит мгновенно, это только запись приходится ждать. поэтому в обоих вариантах записи (через *block или через *\xxx) затраченное на обновление значения в eeprom время будет почти одинаковым. если ты, конечно, такты не считаешь. хотя если бы считал, то писал бы на асме. да?

anonymous
()
Ответ на: комментарий от anonymous

eeprom_update_block просто копирует кусок из памяти в eeprom, как есть.

Это вызывающе неверная информация.

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

anonymous
()
Ответ на: комментарий от sunjob

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

anonymous
()
Ответ на: комментарий от sunjob

EEMEM имеет «особенность» оптимизировать расположение структур в памяти

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

anonymous
()
Ответ на: комментарий от anonymous

мои текстовые выкусы из даташита / форумов

запись байта в eeprom длится несколько миллисекунд.
тактируются I/O операции от спец. внутр. генератора

+

datasheet: Table 8-1.EEPROM Mode Bits
3.4 ms - Erase and Write in one operation !!! ONE OPERATION !!!
1.8 ms - Erase / Write only

+

datasheet: Bit 0 – EERE: EEPROM Read Enable
Table 8-2. EEPROM Programming Time
typical programming time for EEPROM access from the CPU
3.3 ms

+

среднее время 8.5 мс (из форума)

допускаю, что запись одной ячейки (поправьте, сслыки/пруфы)
+

размер EEPROM - 1КБ

а если обьем данных 1024 байт?!

по поводу вашего

на этом фоне выполнение пары десятков инструкций из eeprom_read_block

разговор идет об записи

спасибо

sunjob ★★★★
() автор топика
Последнее исправление: sunjob (всего исправлений: 5)
Ответ на: комментарий от anonymous

с точки зрения сишки нет никакой разницы где у тебя расположена структура - в основной памяти или в eeprom.

как минимум разные секции

EEMEM - это просто атрибут, указывающий в какой секции

у меня происходит оптимизаация последовательности расположения структур (если их менять, добавлять)

далее - на данную под-тему (*) халиварить не буду (ни времени, ни желания)

спасибо

(*) что такое EEMEM и точки зрения/разницы на расположение

sunjob ★★★★
() автор топика
Последнее исправление: sunjob (всего исправлений: 3)
Ответ на: комментарий от sunjob

разговор идет об записи

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

на одном мегагерце и 3 миллисекундах на перезапись ячейки eeprom получается соотношение примерно 1 к 70: количество перезаписанных байт (1) и, за то же время, количество прочитанных байт, не требующих перезаписи (70). килобайт на 1 мегагерце «прочитается» функцией eeprom_update_block где-то за 14.5 миллисекунды, что соответствует перезаписи 5 байтов.

как минимум разные секции

к си это не относится. указатель на eeprom ничем не отличается от указателя на рам.

anonymous
()