Главная страница
Библиотека (скачать книги)
Скачать софт
Введение в программирование
Стандарты для C++
Уроки по C#
Уроки по Python
HTML
Веб-дизайн
Ассемблер в среде Windows
ActiveX
Javascript
Общее о Линукс
Линукс - подробно
Линукс - новое
Delphi
Паскаль для начинающих
Турбопаскаль
Новости
Партнеры
Наши предложения
Архив новостей





Отметим, что процедура разрешения записи двухступенчатая: "лишний" флаг EEMWE (официально он называется "флаг управления разрешением записи") введен, очевидно, для дополнительного предохранения EEPROM от несанкционированной записи при сбоях, когда МК может выполнять произвольную последовательность команд. Устанавливаемый программно флаг EEMWE независимо ни от чего сбрасывается аппаратно через четыре такта, и если в течение этих тактов флаг EEWE не будет установлен, то далее его установка не окажет никакого влияния. Расчет сделан на то, что при выполнении произвольных операций каждый из этих флагов в принципе может быть установлен случайно, но случайное совпадение этих действий в нужной последовательности практически исключено. Именно поэтому при отсутствии в программе процедуры записи в EEPROM вероятность порчи данных в ней значительно ниже. А вот при наличии такой процедуры мы своими руками вписываем нужную последовательность, и данные при выключении питания достаточно часто оказываются испорченными.

Установленный нами бит разрешения EEWE В регистре управления сбросится автоматически, когда запись закончится — этого сброса мы и ожидаем в начале процедуры. На всякий случай, как мы говорили, то же самое рекомендуется делать и при чтении, но практически всегда (если только мы не читаем непосредственно после записи) это не будет задерживать программу дольше, чем на время выполнения команды sbic, т. е. на два машинных цикла. Сама процедура получается даже короче (листинг 9.2).

Листинг 9.2
ReadEEP: /в ZH:ZL — адрес откуда читать /возврат temp — прочтенный байт
sbic EECR,EEWE /ожидание очистки флага записи
rjmp ReadEEP
out EEARH,ZH /старший адреса
out EEARL,ZL /младший адреса
sbi EECR,EERE /бит чтения
in temp,EEDR /чтение ret /конец ReadEEP
В этих процедурах регистр z не играет никакой выделенной роли, просто служит удобной парой регистров, которую можно заменить на любую другую.
Отметим еще, что на время записи следует запрещать прерывания: если между установкой флага EEMWE И флага EEWE "вклинится"" стороннее прерывание, то первый окажется сброшен и никакой записи не произойдет. Если мы используем процедуру записи внутри какого-то прерывания, то, разумеется, об этом можно не думать, поэтому в процедуре, приведенной в листинге 9.2, команд запрета/разрешения прерываний нет, но в общем случае об этом забывать не следует.

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

При первичной загрузке можно пойти двумя путями: самый простой заключается в том, чтобы создать еер-файл по методике, описанной в главе 5, и загружать его в EEPROM отдельно. При отладке программы в дальнейшем можно выключить fuse-бит EESAVE, отвечающий за стирание EEPROM в процессе программирования flash-памяти (см. последний раздел главы 5), и первоначально введенные значения констант по умолчанию будут сохраняться в дальнейшем. Недостаток такого подхода— при каких-то манипуляциях в процессе отладки схемы можно, не заметив того, запросто испортить капризную EEPROM (например, случайно подав на какие-то выводы повышенное напряжение) и потом долго недоумевать, почему все перестало работать.
Конечно, при отлаженных схеме и программе загрузка данных в EEPROM через отдельный файл предпочтительна с точки зрения простоты. Но за счет усложнения программы можно сделать иначе, когда содержимое EEPROM по умолчанию будет обеспечиваться автоматически, и вам не придется об этом заботиться даже при случайной ее порче.

В таком случае загрузку нужно делать при запуске МК, в процедуре RESET. Но записывать константы каждый раз при включении питания не только не имеет смысла (тогда проще их хранить прямо в тексте программы), но и крайне неудобно для пользователя: нет ничего хуже устройства, заставляющего себя инициализировать при каждом сбое питания (не идите на поводу у горе-разработчиков бытовых приборов, в которых при каждом включении приходится заново устанавливать часы — лучше бы тогда часов не было вообще). Если схема спроектирована верно, и EEPROM надежно защищена от сбоев, автоматическая запись должна производиться один-единственный раз при первом запуске контроллера; кроме того, она должна осуществляться при случайной порче данных.



     
 

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru