Мелкие вопросы по МК и ПЛИС.

SmarTrunk

Это банально, может дело и не в этом, но нельзя в ЕЕПРОМ писать постоянно, в процессе работы программы - ЕЕПРОМ сдохнет. Обычно, надо писать все в ОЗУ, а в ЕЕПРОМ сохранять перед выключением (но надо дать МК чуть времени на сохранение, и сигнал "питание пропало"), или один раз при изменении какого-то параметра (громкости, яркости экрана и т.д.)

Реклама

Prosperous

Это банально, может дело и не в этом, но нельзя в ЕЕПРОМ писать постоянно, в процессе работы программы - ЕЕПРОМ сдохнет. Обычно, надо писать все в ОЗУ, а в ЕЕПРОМ сохранять перед выключением (но надо дать МК чуть времени на сохранение, и сигнал "питание пропало"), или один раз при изменении какого-то параметра (громкости, яркости экрана и т.д.)

Т.е. читать начальные данные из EEPROM в буфер, перезаписывать их, и при необходимости сохранять обратно в EEPROM? А где лучше хранить, просто в обычном буфере или лучше буфер разместить в памяти программ?

Реклама

Gudd-Head

Prosperous писал(а):в памяти программ?

Если только у вас МК Ramtron с FRAM памятью

Т.к. у флэш памяти ресурс на порядок меньше, чем у ЕЕПРОМ.

ut1wpr

Prosperous писал(а):
Это банально, может дело и не в этом, но нельзя в ЕЕПРОМ писать постоянно, в процессе работы программы - ЕЕПРОМ сдохнет. Обычно, надо писать все в ОЗУ, а в ЕЕПРОМ сохранять перед выключением (но надо дать МК чуть времени на сохранение, и сигнал "питание пропало"), или один раз при изменении какого-то параметра (громкости, яркости экрана и т.д.)
Т.е. читать начальные данные из EEPROM в буфер, перезаписывать их, и при необходимости сохранять обратно в EEPROM? А где лучше хранить, просто в обычном буфере или лучше буфер разместить в памяти программ?

Как угодно делайте. Лишь соблюдайте правило - перписывать eeprom требуется как можно реже. По возможности сделайте интерливинг по ячейкам, чтобы равномернее распределять "износ". Рекомендуют при старте сохраняемые переменные сосчитывать в ОЗУ и работать с ними. В случае пропадания питания применить механизм опережающего сохранения данных в ЕЕПРОМ. Этот прием используется веками. Еще до появления МК в том виде, как они сейчас есть. Или как вариант, примените внешнее малопотребляющее ОЗУ с бекапом по питанию.

Реклама

Alexeyslav

Для EEPROM гарантируется 100тыс. циклов записи, это всего лишь 27 часов посекундной записи. Возможно, из-за ошибки в программе запись туда производится довольно часто... для параметров которые изменяются чаще чем раз в 30...60 минут(выработка ресурса через 5-10 лет) лучше использовать FRAM память. Ну и дешевый вариант - запитать контроллер от ионистора.

Реклама

Prosperous

Да нет, на этапе отладки не очень часто, а уж в рабочем режиме будет очень не часто

У меня тупой вопрос, а считывать в ОЗУ это что имеется ввиду? Организовать обычный буфер, скажем типа unsigned char и читать туда данные? или как то по другому это делается?

В случае пропадания питания применить механизм опережающего сохранения данных в ЕЕПРОМ

А как это делается? Поделитесь секретом, если не сложно

Реклама

Alexeyslav

Переменные разместить в отдельном непрерывном блоке ОЗУ, тогда проще будет восстанавливать с EEPROM и сохранять.

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

ut1wpr

А как это делается? Поделитесь секретом, если не сложно

Секрет Полишинеля...
Я не знаю вашей среды программирования. Я работаю в IAR. Там достаточно просто:

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

__eeprom u16 ee_val1 = 0x1234;
__eeprom u8 ee_val2 = 255;

u16 val1;
u8 val2;

void main( void ){
......
val1 = ee_val1;
val2 = ee_val2;
....

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

В блоке питания устройства выпрямительный мост изолируется от основной сглаживающей емкости диодом.
Сразу после моста ставится очень небольшой конденсатор, тау разряда которого около 3-5 периодов сети.
Напряжение с этого конденсатора на вход внешнего прерывания. Настройка на срабатывание по низкому уровню.
Емкость основного сглаживающего конденсатора рассчитывается так, чтобы времени его разряда хватило на время, за которое блок необходимых переменных гарантированно
сохранился в eeprom. PDF, калькулятор и немного терпения. Все процессы и их времянки по записи в EEPROM - в документации на данный МК.
По пропадании сети на время 3-5 периодов, напряжение на входе прерывания падает, но на основном конденсаторе еще достаточно энергии.
Срабатывает прерывание, обработчик сохраняет все критические переменные и замыкается в бесконечную петлю. Прямо в обработчике.
Для работы программы - это полный конец. Дальше основной конденсатор разряжается и все умирает.
В обработчике примерно так:

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

ee_val1 = val1;
ee_val2 = val2;
for( ;; );

Схемотехнических решений в этом направлении можество. Если у вас мощные потребители, нужно ставить отдельный стабилизатор для МК, чтобы хватило времени на сохранение данных. В обработчике можно также перевести все исполнительные механизмы в безопасное состояние, или любые другие действия. Только нужно тщательно просчитать время выполнения обработчика, чтобы оно не превысило тау разряда конденсатора поддержки.
Этим приемом пользовались и продолжают пользоваться множество разработчиков, прокручивая те или иные варианты желеха и программ. Тип МК при этом не имеет значения. Важна идея, которую я постарался понятно изложить.

Prosperous

спасибо, возьму на вооружение

avreal

ut1wpr писал(а):По пропадании сети на время 3-5 периодов, напряжение на входе прерывания падает, но на основном конденсаторе еще достаточно энергии.

Аналогично. Только…
«Если ты не параноик, то это не означает, что они за тобой не следят».

ut1wpr писал(а):
Код: Выделить всё
ee_val1 = val1;
ee_val2 = val2;
for( ;; );

Возможна ситуация, когда выключатель (или что-то по дороге) «пошелестел» или там им щёлкнули но сразу вернули назад. Напряжение сразу после моста просело, по сигналу ACLO

вошли в обработчик, но тут напряжение восстановилось, не опустившись после стабилизатора до того уровня, при котором срабатывает BOR/POR.
А мы висим в обработчике.

Довольно вероятная ситуация даже при питании от сети (причём чем больше основной конденсатор, тем вероятнее ситуация), а уж в автомобиле так по нескольку раз на дню может быть риск нарваться — заводимся, борт просел настолько, чтобы сработала проверка первичного, но не наcтолько, чтобы заметно просело питание микроконтроллера.

Посему у меня в таких местах for(;;) сидит проверка питания и при его восстановлении у установлении самосброс по WDT (для AT89C5x было по внешнему).
Дальше софт проходит стандартную процедуру старта с анализом предыдущего сохранённого состояния, возможно, с откатом/повтором операций с EEPROM/внешней флеш. Не тех операций, кторые состояние сохраняли (на них конденсаторов хватало, а если не хватило, сбой CRC записи сохранения, то это уже более серьёзная разборка), а тех, которые от внешних воздействий по питанию и защищались.

В большинстве случаев «недопропадание», короткое и длинное пропадания питания не различаются.
Только один раз нужно было различать именно «недопропадание» и короткий просад («заводимся») от длинного выключения («сняли клемму»).

ut1wpr

AVREAL
Саша, да кто же спорит. Я вывалил адепту общее направление. Сколько еще может быть ситуаций! А сколько может и не быть... Ведь ты прекрасно знаешь, невозможно достичь универсальности. Только при реализации конкретных решений буду конкретные проблемы.
По сказанному тобой можно сделать вывод и транслировать его - не обольщайтесь кажущейся простотой. Всегда есть и дадут о себе знать подводные камни. Причем в самый неподходящий момент. Надо быть готовым к их обходу...

ut1wpr

avreal писал(а):Только…
«Если ты не параноик, то это не означает, что они за тобой не следят».

Меня уже поправили. И я сменил на текст оригинала: "Если у вас нет паранойи, это не значит, что за вами не следят!". Ты об этом

Вроде в оригинале не было ОНИ...

И вообще: "Ты суслика видишь?..."

Dmitriy Karpov

Я начинающий. Недавно закончил свою первую прогу-часы на ATmega8. Сами часы писал сам, индикацию взял из обучалки. Решил испытать. Спустя сутки выяснилось, что они отстают аж на 4 секунды. Кварц у меня 16 МГц. Принципиально ли использовать часовой кварц? Секунды отсчитываю по прерыванию компаратора таймера. Может лучше просто цикл задержки?
Вообщем, кому не трудно посмотрите код во вложении.

Gudd-Head

Dmitriy Karpov писал(а):Спустя сутки выяснилось, что они отстают аж на 4 секунды

4/86400 ≈ 4.6*10^(-5) = 46 ppm. Для кварцев HC49S типичная точноть 50 ppm. А у вас какой стоит?

igor-x

подскажите пож. следующее:
вот нашел ресурс http://opencores.org/projects

для какого типа (или производителей) ПЛИС созданы проекты?

Dmitriy Karpov

Хм.. а как бы эт узнать? На нем написано MBC 16.000 Он высокий такой. Брал в Митино и не заморачивался тогда не о какой точности ибо вообще с микроконтроллерами дело не имел.

Gudd-Head

Вообще не понимаю прикола изобретения часов, когда есть готовые часовые ИМС с календарём. А есть ещё и со встроенным MEMS резонатором.

Dmitriy Karpov

Я не ставил цель изобретать велосипед. Просто хотелось потренировать на чём то, что хорошо известно. Так говорите всё от кварца зависит?

Gudd-Head

Dmitriy Karpov писал(а):Так говорите всё от кварца зависит?

Найдите точный частотомер и померьте

В небольших пределах вроде даже можно частоту подстроить ёмкостью, которой шунтируется кварц.
Я в ваш код не вглядывался. Может, вы там таймер останавливаете и/или пропускаете прерывания от таймера.

zero648

Dmitriy Karpov писал(а):Спустя сутки выяснилось, что они отстают аж на 4 секунды. Кварц у меня 16 МГц. Принципиально ли использовать часовой кварц? Секунды отсчитываю по прерыванию компаратора таймера. Может лучше просто цикл задержки?
Вообщем, кому не трудно посмотрите код во вложении.

Выкини эти строки из обработчика, изза них отставание и происходит, счетчик сам должен обнуляться при совпадении.
;****************************************************
; ОБРАБОТЧИК ПРЕРЫВАНИЯ КОМПАРАТОРА
;****************************************************

Timer1_compA1:
ldi Temp,0 ;обнуление таймера
out TCNT1H,Temp
out TCNT1L,Temp

cpi Dg,9
breq Load
inc Dg
rjmp Output

Load: ldi Dg,0
Output: reti ;выход из обработчика

И здесь включить режим СТС:

ldi Temp,0b00001100 ;тактовый сигнал СК/256 + режим СТС
out TCCR1B,Temp