Си начинающим с нуля - IAR Atmel

т.е. - переменных пять, одна из них 3-х байтовая, итого - Леха: 7 байт пишутся

касаемо энергоёмкости процесса записи в ЕЕПРОМ, то есть таковая для отдельного ATMEL-чипа, где типовой ток состовляет 2мА @ 5В; толкнувшись, запись внутри МК будет аппаратно завершаться независимо от программного режима, только питание будет критично - народ отделяется от кренки диодом и ставит гига-бочку к ноге меги

Вам следует сделать эксперимент по току потребления: сначала просто стоять в режиме IDLE со всей остановленной переферией, какая не нужна; потом тоже, но непрерывно записывая по готовности в ячейку-смертницу разные "дурацкие" байты, а результаты - огласить нам

birua: толкнувшись, запись внутри МК будет аппаратно завершаться независимо от программного режима

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

birua: потом тоже, но непрерывно записывая по готовности в ячейку-смертницу разные "дурацкие" байты

А почему "смертницу"? Разве она может совсем загнуться если питание закончится не вовремя? Просто значение испортится, но ячейка ведь должна остаться целой?
Я думал вывести сигнал на ногу проца и цепануть осцил к питанию и к этой ноге. В итоге получу то, что реально чувствует проц (при обнаружении отсутствия питания он вскинет 1 на ноге, а когда питание почти закончится он уйдет в RESET по BOD и на ноге будет высокоимпеданстное состояние) и как при этом меняется питание.

Если прикинуть, то при потреблении тока 2 мА с 5 до 2,7В проц может питать кондер на 100 мкФ в течение 100 мс.

Леха: задал в EEADR адрес 2-й и т д.

да, разумеется - байт_за_ход

вот ещё одно преимущество страничной записи во внешний чип - НЕ Леха надо выполнять команды проверки - совпадают ли значения, чтобы зря не писать, т.к. всё-равно пишется за раз вся страница, независимо от того - была ли она модифицирована полностью или частично или вообще нет (через внутренний страничный буфер) Леха: Это я все учту на будущее

конечно, пропажа питания - не повредит аппаратуре, всё уцелеет 100%, но потому - "смертницу", что за минуту подобного "дроча" можно будет выбрать до 10% её официального ресурса по перезаписи

да - делайте на ноги всякие технические выдачи импульсов (например, после каждой удачной записи байта, для оценки длительности цикла ЕЕПРОМ при конкретном вольтаже); только чтобы зафиксировать, когда Леха: на ноге будет высокоимпеданстное состояние - кто-то (резистор) должен разрядить/зарядить паразитную ёмкость вывода и пробника на ней

предлагая эксперимент, я предлагал задаться целью точного измерения величины тока потребления birua: в режиме IDLE со всей остановленной переферией, какая не нужна; а потом, добавив в код пробуждение и непрерывно-бесконечную запись (по мере готовности начинать очередную, понятно) - быстро снять полное потребление, для прикидки тау успевания выгрузки нужного нам числа байт

birua: вот ещё одно преимущество страничной записи во внешний чип - НЕ Леха надо выполнять команды проверки - совпадают ли значения, чтобы зря не писать, т.к. всё-равно пишется за раз вся страница

birua: предлагая эксперимент, я предлагал задаться целью точного измерения величины тока потребления

Про резистор, разумеется понятно.

преимущество, преимущество - это преимущество в контексте скорости, а для ресурса и для внутренней и для внешней - резерв параллелизма вширь_рядом_класть - велик просто по беспределу

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

Ну в ДШ написано, что работа проца при "подкрученном" сверх нормы RC-генераторе негарантированна, т. к. этот же генератор тактирует запись в ЕЕПРОМ. Т. е. получается, что действительно довольно точное время. А что касается самого RC-генератора, то проц у меня принимает команды от пульта от телека по протоколу RC-5 с контролем временнЫх допусков согласно правилам. Т. е. тут сомневаться не приходится, иначе прога не работала бы.
Кроме того, при 1м запуске забыл считать и зашить калибровочный байт генератора - так все равно работало все, только, как мне показалось, "пульт чуть хуже ловился".

Аппноту ту я кстати полистал, суть понятна. Мне просто кажется немного "не по-пацански" когда при каждом тычке кнопки на пульте у меня пишется флешка... Может я не прав и слишком загоняюсь? По рассчетам действительно выходит что если тыкать пульт 10 раз в день, то устройство проживет 27 лет. Но у меня недавно после 5-летней ежедневной эксплутатации трагически сдохла флешка Кингстон на 8 гиг. Хотя максимум что я делал - это просто сохранял с заменой новую версию файла. И далеко не 10 раз в день, а 1 раз. А ведь это не Мега за 40 рублей, а специально предназначенный для работы с файлами девайс. И записей там по даташиту наверняка не 10 000, а под 1 лям.
Тест от одного товарища, ссылка на который здесь приводилась, конечно впечатлил. Но тест длился 1 день. А данные лежат во флешке годы, т. е. затворы могут еще и "спускать" электроны потихоньку. Ведь они не могут быть абсолютно "герметичными". Ну и т. п. Так что может на практике 100 000 записей - это только-только? Ведь не будет же Атмел в ущерб себе занижать ТТХ в 30 (!) раз

всё дело в температуре помноженной на выход годных при текущем тех.процессе:
Data Retention, Reliability Qualification results show that the projected data retention failure rate is much less than 1 PPM over 20 years at 85°C or 100 years at 25°C

Вы наверное удивитесь, но в супер-флешах основная ставка сделана не на надёжность отдельной ячейки (не сколько 10^n перезаписей), а на развитую систему коррекции ошибок в сочетании с заложенным резервом

но мы уходит в дремучие дебри от "Си начинающим с нуля - IAR Atmel", rotoff

P.S.
birua: все слышали о восьми с полтиной
Леха: Ну в ДШ написано

я Вам могу показать старый документ с другой цифрой в первом абзаце:

Many applications use the built-in EEPROM of the AVR to preserve and hence restore system information when power is removed from the system. The programming time for storing a single byte of data in the On-chip EEPROM between 3 and 8.5 ms and write access is therefore constrained by this write time. (Многие приложения используют встроенную EEPROM AVR, чтобы сохранить и, впоследствии, восстановить системную информацию при отключении питания системы. Время программирования для сохранения одного байта данных в On-chip EEPROM между 3 и 8.5 мс, и собственно возможность сохранения поэтому сдерживается этим временем записи.)