avr & eeprom_update_block()

Notes:

In addition to the write functions there is a set of update ones. This functions read each byte first and skip the burning if the old value is the same with new. The scaning direction is from high address to low, to obtain quick return in common cases.

Что непонятно?

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

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

на все update-функции используется одна процедура записи байта: https://github.com/avrdudes/avr-libc/blob/main/libc/misc/eeupd_byte.S#L87

уже наткнулся url

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

извини, я тебя не понимаю.

подробно:

записи байта

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

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

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

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

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

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

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

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

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

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

чем он тебе не понравился?

временем! если структура большая...

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

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

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

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

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

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

чтение из eeprom происходит мгновенно

скажете тоже! я уже не говорю про запись...

вот именно, исходники же есть. вот основной цикл:

1:	ld	r18, -X
	XCALL	eeprom_update_r18
2:	subi	n_lo, lo8(1)

#if	RAMEND > 0xFF  ||  E2END > 0xFF
	sbci	n_hi, hi8(1)
#endif

	brsh	1b

где тут магия?

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

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

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

где тут магия?

Магия в функции eeprom_update_r18.

нет там никакой магии. это просто обновление байта по адресу с декрементом адреса.

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

запись байта в 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

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

спасибо

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

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

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

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

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

спасибо

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

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

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

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

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

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