Поиск качественной литературы по мк. КР580ВМ80А

[Starichok51]

не дольше, если результат ВСЕГДА будет с первой проверки.
а если понадобится несколько заходов на эту проверку, то будет дольше.

[Just_Fluffy]

Еще раз - мы говорим о частном случае, когда запись в ЕЕПРОМ не должна поломать динамическую индикацию.
Для этого можно сделать конвейер. И пинать конвейер можно либо прерыванием, либо периодической проверкой флага.
Если исходить из общего требования к минимизации времени работы с еепромкой - то прерывание, возможно, будет быстрее (зависит от периодичности проверки флага). Если раз в миллисекунду, то может и не будет.
А вообще - почти без разницы. Просто мне не нравятся категоричные утверждения, что нужно делать только вот так и никак иначе.
А в общем случае скрестить динамическую индикацию и запись в еепром можно кучей способов. Можно даже обойтись вообще без прерываний )))) AQ29 оценил бы, он не любит прерывания...

[OKF]

Поддерживаю. Если можно обойтись без прерываний - почему бы и нет.) И даже с блокирующей записью в ЕЕПРОМ ничего страшного, зависит от ситуации. От периодичности и кол-ва записываемого. А зато видно - запись прошла.)))

[BOB51]

При наличии аппаратного модуля записи я вообще проблем не наблюдаю - запуск процесса, а затем контроль результата в любом из "окон" процесса сканирования.

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

[shonty]

И пинать конвейер можно либо прерыванием, либо периодической проверкой флага.

Если конвеер и динамическая индикация, то, как вариант, можно обойтись без прерываний и проверки флагов.. Просчитать гарантированное количество циклов межу записями в ЕЕПРОМ.

[Just_Fluffy]

shonty, либо экономить время и ресурс еепромки, как сделано в eeprom_update_byte() - прочитать еепромку - и если там уже есть то значение, что нам надо - не писать повторно. А если там биты только гасятся - то писать без стирания...

[Starichok51]

Просто мне не нравятся категоричные утверждения, что нужно делать только вот так и никак иначе.

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

А если там биты только гасятся - то писать без стирания

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

[Just_Fluffy]

а где я сказал, что нужно делать только вот так и никак иначе?

Со всем уважением к вам, но я считаю ваше утверждение категоричныи и преподнесенным, как единственно верное

каждый байт в еепром пишется с предварительным стиранием

Опять же, это утверждение для восьмой меги. У других мег еще бывают биты ЕЕРМх. И если мы обсуждаем уже ЕЕПРОМку, то запись отдельно от стирания в АВРках существует и может быть применена для увеличения ресурса ЕЕПРОМки.

[Starichok51]

сожалею, то моё слово "нужно" было воспринято, как как единственно верное решение. хотя я не собирался быть таким категоричным.
поскольку я с записью еепром сталкивался только в меге8, я не знал о существовании в других АВРках записи отдельно от стирания.

[shonty]

моё слово "нужно" было воспринято, как как единственно верное

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

Добавлено after 4 minutes 25 seconds:
Если вкратце, то "нужно" - предоставляет выбор
"должнО" - выбора не предоставляет

[OKF]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4676373#p4676373"]И если мы обсуждаем уже ЕЕПРОМку, то запись отдельно от стирания в АВРках существует и может быть применена для увеличения ресурса ЕЕПРОМки.[/uquote]
На данном свойстве делал людям счётчик наработки до 9999 часов с посекундной записью в ЕЕПРОМ. На >10 лет работы должно хватить, при заявленных 100000 циклах записи EEPROM.

[Just_Fluffy]

OKF, о, интересно. Алгоритм какой?

[OKF]

Ой, давно это было, в 2019-м). Начал смотреть - накручено, фиг поймёшь. Лишний раз убеждаюсь, нужно писать максимально понятно.

Спойлер

Ну вот ЧТО тут можно понять!

Код: Выделить всё

/*
  Пользователь задаёт время работы таймера (timer_preset).
  После секундной паузы включется лампа и timer начинает обратный отсчёт.
  Для восстановления текущего значения таймера, сохраняется время его стопа (timer_stop_time)
  на основании которого происходит вычисление значения таймера после подачи питания.
  Время наработки (total_hour и total_second) считается при включенной лампе.
  Для уменьшения износа EEPROM каждую секунду в массив total_second пишется только 1 бит,
  т.о. заполнение всего массива происходит один раз за один час работы лампы, что 
  гарантирует время работы ус-ва более 10 лет, при заявленных 100000 циклах записи EEPROM.
  Реально же, ресурс EEPROM достигает 3 млн, что больше чем на порядок от заявленных Atmel!
  Для других EEPROM-переменных для этих целей используются кольцевые буферы.
  Для total_hour и timer_preset используется дублирование и мажоритарный выбор при включении.
*/
/*
  uint16_t timer_preset     - стартовое значение таймера обратного отсчёта (еепром)
  uint16_t timer            - текущее значение таймера на экране
  uint32_t timer_stop_time  - время выключения таймера (еепром) (0, при timer_preset = 0)
                            = timer_preset + total_hour + total_second
                              не записывается при timer (timer_preset) == 0.
  bool lamp                 - состояние лампы (еепром)
  uint16_t total_hour       - время наработки, часы - на экране (еепром)
  uint16_t total_second     - время наработки, секунды (еепром)
*/

[BOB51]

А просто подвесить внешнее RTC с энергонезависимой ОЗУ для временного хранения данных?
Быстро и удобненько (та же DS1307 в качестве ОЗУ) или еще чего по современнее......
А уж там следим за питанием, запасом времени и прочими ленивыми факторами при копировании в ЕЕПРОМку и/или даже флеш программ...

[OKF]

Это когда ты сам проектируешь. А тут у заказчика готовое изделие, которое его не устраивало в работе (не всегда сохраняло время наработки). Я делал по его схеме, с его комплектующими.
Считаю что ЕЕПРОМ надёжней батарейки. Которую RTC никак не контролирует.

[shonty]

На >10 лет работы должно хватить, при заявленных 100000 циклах записи EEPROM.

В нулевых помню на импортном оборудовании чипы лететь начинали через 4-5 лет непрерывной работы. Тогда напрямую из испании чипы выписывали. Просто меняли в панельках.
Не было тут дилеров.
Но это рассматривалось как "особенность оборудования"

[AlexS4]

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

еще можно просто литиевый аккумулятор на питание всего msc и любым способом не давать ему работать в полную силу от батарейки, самый тупой способ - код коричневый на напряжение от батареи. тогда и eeprom не нужен и копеечным литиевым пакетиком можно хоть год держать sram.

[OKF]

[uquote="AlexS4",url="/forum/viewtopic.php?p=4676485#p4676485"]да, для экономии ресурса - имхо самое простое и полезное записывать по аварии питания...[/uquote]
Именно так и было у заказчика и которое его не устраивало.

[AlexS4]

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

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

[BOB51]

[uquote="OKF",url="/forum/viewtopic.php?p=4676477#p4676477"]Это когда ты сам проектируешь....
Считаю что ЕЕПРОМ надёжней батарейки. Которую RTC никак не контролирует.[/uquote]
В далекие времена (2001-2002) делал "счетчик заказа" для копировалок.
Подсчет и сортировка по формату вылезших их копировального аппарата листиков плюс функция "вложенного заказа" и прочее (включая суммарный накопитель с момента первого включения, часики побочным эфектом)...
Тогда еще на АТ89С2051 + DS1307 и ЖКИ МТ10Т7-7...
https://img.radiokot.ru/files/20529/3o3195xyfn.GIF
НОСТАЛЬЖИ...