Работа с EEPROM в Алгоритм билдере максимально упрощена.
Фактически она не отличается от работы с обычной памятью SRAM:
1 создаем переменную в таблице переменных
sshot-1.png [ 4.88 КБ | Просмотров: 7812 ]
2 дальше как обычно
- читаем EE_name --> r16
- записываем 123 --> EE_name
Но, несмотря на простоту, нужно учитывать определенные нюансы работы с EEPROM.
1 самая очевидная проблема - ограниченное количество циклов ЗАПИСИ в ячейку EEPROM (читать ячейку можно сколько угодно раз). Например, для ATtiny2313 (для которой здесь приведены примеры) количество циклов составляет 100 000. Вроде бы и много, но если, например, непрерывно делать запись в одну ячейку, то всего через 5 минут ячейка станет неработоспособной. В виду этого всегда нужно заранее понимать как будет производится запись и не допускать ненужные циклы записи.
2 у EEPROM есть один недостаток: при снижении напряжения питания хранящиеся в ней данные могут быть повреждены.
Чтобы исключить это можно удерживать микроконтроллер в состоянии сброса встроенным детектором напряжения питания (Brown-Out Detector — BOD) на все время, пока напряжение питания находится ниже нормы (BOD выставляется фьюзами).
3 теперь переходим к менее очевидным вещам. Если время чтения ячейки EEPROM занимает 1 такт (ну не считая подготовки регистров EEPROM к чтению - еще тактов 5), то запись ячейки EEPROM довольно продолжительна. Время записи зависит от микроконтроллера и лежит в пределах 3-4 мС. Это довольно долго, что может вызвать сбои, например в программной реализации каких либо протоколов, ШИМ и тому подобное.
Здесь есть выход. В принципе, сам процесс записи в EEPROM автономен и во время записи можно выполнять другой кусок программы. В самом Билдере контроль записи включен по умолчанию (Меню/Опции проекта/ЕЕ макро)
sshot-2.png [ 6.31 КБ | Просмотров: 7812 ]
Но этот контроль стоит ПОСЛЕ операции записи (проверяется обнуление бита EEWE (для ATtiny2313 EEPE)). Это самый безопасный вариант, который не допустит каких либо ошибок в работе с EEPROM, но при этом микроконтроллер остановится в ожидании этих 3 мС до окончания записи.
Билдер позволяет перенести проверку окончания записи в начало макрооперации записи
sshot-3.png [ 6.37 КБ | Просмотров: 7812 ]
позволяя программе выполнять какие либо действия совместно с процессом записи в EEPROM.
4 следующая проблема появляется как только Вы переключили Билдер в режим контроля окончания записи в НАЧАЛО макрооперации записи! Проблема в том, что нельзя позволять программе, на время записи, выполнять какие либо действия с EEPROM. Проблему с запретом записи решает сама макрооперация записи, так как проверка окончания записи стоит в начале и новая запись не запустится пока не закончится предыдущая (хотя МК на время ожидания опять остановится
) О запрете чтения Вам придется побеспокоится самому. Вот так:
sshot-4.png [ 2.54 КБ | Просмотров: 7812 ]
5 но и это еще не все грабли! В целях защиты EEPROM от ошибочных записей разработчики внедрили в МК защитный механизм: команда начала записи в EEPROM, должна следовать (выполнится) сразу после команды разрешения записи в EEPROM. Если, например, прошла команда разрешения записи, потом вдруг вызвалось какое либо прерывания и после выхода из прерывания выполняется команда начала записи в EEPROM, то никакой записи в EEPROM не будет. Для этого нужно запрещать прерывания для этих двых команд. Прерывание запрещает ДО и разрешает ПОСЛЕ сама макрооперация записи в EEPROM
sshot-5.png [ 6.7 КБ | Просмотров: 7812 ]
Но если Вы осуществляете запись в EEPROM в самом теле прерывания, то макрооперация по окончанию записи в EEPROM разрешит прерывания, что в самом теле прерывания не должно быть! Поэтому Вам нужно в этом случае отключить в настройках макрооперации записи EEPROM блокировку главного прерывания, дабы не ломать логику работы прерывания.