Код
volatile __regvar __no_init unsigned char mode @ 15;
Он занулён намертво при старте. Не думаю что R20 чем-то отличается в этом плане.
Полная версия этой страницы: Как распознать кратковременное выключение на Tiny13
Компилятор IAR. Пробовал с регистрами общего назначения. Конкретно R15 вот так:
Он занулён намертво при старте. Не думаю что R20 чем-то отличается в этом плане.
Он занулён намертво при старте. Не думаю что R20 чем-то отличается в этом плане.
Цитата(@Ark @ Jan 15 2010, 09:49) 
Так и храните! Не отключайте батарею, да и все. 
На ее ресурс это практически не повлияет. Ток потребления в режиме спячки - 100nА. Наверное, саморазряд батареи больше....
это технически весьма сложно - понадобится тянуть дополнительный провод от кнопки через скользящие контакты. кроме усложнения, это снизит надежность фонаря из-за лишних контактов.
На ее ресурс это практически не повлияет. Ток потребления в режиме спячки - 100nА. Наверное, саморазряд батареи больше....
Да ну, проблема питания контроллера во время выключаения решается гораздо проще простым электролитом.
Цитата
это технически весьма сложно -... это снизит надежность фонаря из-за лишних контактов.
Вы, видимо, не поняли - скользящие контакты, при таком решении, совсем выбрасываются из конструкции, а не добавляются новые...
Цитата(VladislavS @ Jan 15 2010, 18:00)
Да ну, проблема питания контроллера во время выключаения решается гораздо проще простым электролитом.
это кратковременная работа. а предлагалось удерживать таким образом режим или настройки яркости.при этом, кстати, при смене или глубоком разряде питающего элемента данные потеряются. кроме того, исключается такая возможность в фонарях, питающихся от 1 элемента (от 1.0В в случае севшего аккумулятора). В общем, не годится этот метод категорически :)
VladislavS, а дайте, пожалуйста, осциллограммки ноги PB1 в моменты включения и отключения
Цитата(@Ark @ Jan 15 2010, 18:02)
Вы, видимо, не поняли - скользящие контакты, при таком решении, совсем выбрасываются из конструкции, а не добавляются новые...
определенно, надо Вам посмотреть устройство современного фонарика как правило, кроме откручивающейся для смены батарей кнопки, откручивается и головная часть с капсулой драйвера. В частности, мои любимые Fenix'ы всю электронику содержат в отдельной "голове", далее корпус - просто аллюминиевая трубка и накручивается кнопка на торце. То есть, контакт только один - через корпус фонаря. Батарея изолирована от корпуса, минусовой контакт подключается на корпус через кнопку.
Цитата
определенно, надо Вам посмотреть устройство современного фонарика...
Определенно, Вы ничего не поняли.
Ну, да ладно...
Цитата(@Ark @ Jan 15 2010, 18:26)
Определенно, Вы ничего не поняли. Ну, да ладно...
ладно, поясняю дополнительно, коль так: Ну, да ладно...сейчас в фонаре только 2 прижатых контакта - полюса батареи. Плюс два контакта через резьбу - торцы корпуса к голове и кнопке. Если делать питание головы фонаря постоянным, надо соединить минус батареи к корпусу постоянно, а освободившийся контакт кнопки довести до головы еще одним проводником. При этом, сохранив возможность откручивать голову и кнопку - то есть, добавляются два скользящих контакта внутри трубки корпуса к голове и кнопке. Есть модели фонарей Nitecore (например, D10 - фото разобранного внизу страницы) с изолированным подвижным "пистоном" между корпусом фонаря и батареей, работающим как кнопка, замыкая на корпус. Но на стабильность работы данной модели фонаря есть нарекания именно из-за примененного решения.
PS: многие из присутствующих наверняка и не сталкивались с софременными профессиональными фонарями
PPS: но тут продолжать обсуждать не будем - оффтоп.
Цитата
.. многие из присутствующих наверняка и не сталкивались с софременными профессиональными фонарями
М-да, видимо, дальше кнопок на питании и скользящих контактов - фантазия разработчиков "профессиональных фонарей" упорно не движется.
Цитата
... но тут продолжать обсуждать не будем - оффтоп.
Согласен.
Добрался таки я до фонарика коллеги. Fenix LD20 Premium Q5 http://superfonarik.ru/Fonari/Fenix-LD20-P...-2-sht--23.html .
Кнопка, установленная в фонарике ведёт себя следующим образом , при сильном нажатии на кнопку , раздается характерный щелчок и фонарик вкл или откл. При лёгком , не до щелчка , переключаются режимы фонарика - чуть нажал и отпустил переключился.
Кнопка, установленная в фонарике ведёт себя следующим образом , при сильном нажатии на кнопку , раздается характерный щелчок и фонарик вкл или откл. При лёгком , не до щелчка , переключаются режимы фонарика - чуть нажал и отпустил переключился.
Цитата(stells @ Jan 15 2010, 16:18)
VladislavS, а дайте, пожалуйста, осциллограммки ноги PB1 в моменты включения и отключения
Только в понедельник.
Прибор на работу уехал.Вот из старых измерений. Разрешение не очень, но общую картину видно. Волосня справа - ШИМ.
Нажмите для просмотра прикрепленного файла
Цитата(VladislavS @ Jan 15 2010, 17:22)
Вот из старых измерений. Разрешение не очень, но общую картину видно
надо полагать, что маленький пичок при включении синхронен с тем, что Вы приводили на ноге PB0?
что-то ШИМ какой-то непонятный, практически постоянная 1, может быть это уже совсем неплохо
я к чему... емкость 3-х драйверов, плюс емкость ноги контроллера, плюс емкость монтажа могут дать неплохой результат. проверить эту версию просто - аккуратно отпаять ногу контроллера
и еще... сравнить бы эту осциллограмму при длинном и коротком отключении
Цитата(stells @ Jan 15 2010, 21:12)
надо полагать, что маленький пичок при включении синхронен с тем, что Вы приводили на ноге PB0?
Судя по всему да.
Цитата(stells @ Jan 15 2010, 21:12)
что-то ШИМ какой-то непонятный, практически постоянная 1,
Так оно и есть. Это режим Hi - 100% яркости. И даже при этом они не просто единицу ставят, а короткие импульсы остаются. Наверное особенности реализации ШИМ на таймере. Хотя таймер можно было бы и отключать. Но они не заморачивались.
Цитата(stells @ Jan 15 2010, 21:12)
проверить эту версию просто - аккуратно отпаять ногу контроллера
Осталась последняя плата с оригинальной прошивкой - жалко убить. Думаю резистора 10 кОм хватит.
Цитата(VladislavS @ Jan 15 2010, 22:08)
Думаю резистора 10 кОм хватит.
наверняка. попробуйте
завтра для очистки совести отпаяю все три корпуса АМС7135 и попробую поведение PIC'a в таком варианте.
Всё . Пипец китайцам 
. Правда я пока не допёр , как они отключают его совсем с этой же кнопки . Остановился на смене режимов- дальше писать лень , да мне это и не нужно. Т.е делал только смену режимов при коротком откл питания.
Если ещё кто-то бьётся с этой задачей могу потерпеть и код не выкладывать , даже будет интересно сравнить подходы к решению. Схема , как у VladislavS , за исключением выходной части , светодиодик подкл прямо к порту.
. Правда я пока не допёр , как они отключают его совсем с этой же кнопки . Остановился на смене режимов- дальше писать лень , да мне это и не нужно. Т.е делал только смену режимов при коротком откл питания.Если ещё кто-то бьётся с этой задачей могу потерпеть и код не выкладывать , даже будет интересно сравнить подходы к решению. Схема , как у VladislavS , за исключением выходной части , светодиодик подкл прямо к порту.
Цитата
Правда я пока не допёр, как они отключают его совсем с этой же кнопки.
Эээ, дык просто отключается питание. Короче, код с пояснениями в студию.
в чем суть-то?
Там и пояснять то нечего. Регистры не сразу сбрасывают то что в них записано. Правда , нашёл ошибочку, разбираюсь , но макетка лежит на столе и работает т.е режимы переключаются
Даже , похоже, что и проверять состояние регисра R7 не требуется. Лишнее это. Устал, сидел два дня с ним, завтра точнее посмотрю. Если кто может уберите из проги строчки
rcall EEPROM_RD
cp R7,temp1
breq MODE
должен по идее итак работать. Мысль такая , что проверяется таблица программ и записанный код в EEPROM равны меняем режим.
P/S Да правильно. (чашка кофе помогла) Алгоритм:
Запускаем первый режим при первом вкл фонарика , записывем его в EEPROM , при размыкании питания и вкл , проверяем режим равны меняем , записываем следуюший EEPROM и т.д. А можно просто счётчик режимов (как идея) , завтра попробую сделать режимов 5
Даже , похоже, что и проверять состояние регисра R7 не требуется. Лишнее это. Устал, сидел два дня с ним, завтра точнее посмотрю. Если кто может уберите из проги строчки
rcall EEPROM_RD
cp R7,temp1
breq MODE
должен по идее итак работать. Мысль такая , что проверяется таблица программ и записанный код в EEPROM равны меняем режим.
P/S Да правильно. (чашка кофе помогла) Алгоритм:
Запускаем первый режим при первом вкл фонарика , записывем его в EEPROM , при размыкании питания и вкл , проверяем режим равны меняем , записываем следуюший EEPROM и т.д. А можно просто счётчик режимов (как идея) , завтра попробую сделать режимов 5
"Причесал" и всё расписал
Цитата(ILYAUL @ Jan 18 2010, 00:25)
Там и пояснять то нечего. Регистры не сразу сбрасывают то что в них записано
так вроде проверял VladislavS эту версию и сказал, что все сбрасывается
Ребят, только мне кажется, что ILYAUL курнул "непадецки"?
Одна загрузка константы в R16 через LPM... Ткните что-ли носом какой регистр там не обнуляется при старте?
Одна загрузка константы в R16 через LPM... Ткните что-ли носом какой регистр там не обнуляется при старте?
я третий раз перечитываю текст программы и ничего не понимаю 
VladislavS, так Вы не попробовали зашунтировать входы драйверов?
VladislavS, так Вы не попробовали зашунтировать входы драйверов?
Нет еще. У нас "дымнуло" устройство в Тель-Авиве - готовлюсь к поездке. Так что, приношу извинения, но опыты по появлению свободной минутки.
вот код для тестирования регистров. несколько экспериментов показали, что разные регистры по-разному реагируют на снятие питания. в моих экспериментах, например, r10 спустя 10 секунд обесточки получал значение при старте 0x08, и сохранял нулевое значение при паузах питания менее 8-10 секунд стабильно. регистр r6 же терял нолик уже спустя 3 секунды обесточки, и принимал значение 1.
эффект налицо, но, видимо, для стабильности определения надо брать несколько регистров и анализировать их состояние...
P.S. как всегда, мега32 и STK500
вот еще результаты:
r0 - стабильно 18 (при очень котортких перерывах питания значение 16, нулевого не добился)
r1 - стабильно всегда 34, не добился иного
r2 - 0 всегда
r3 - помнит 0 до 1 секунды, при больших интервалах принимает значение 4 или 6
r15 - стабильно 1, изредка 3, нуля не добился
r20 - стабильно 22, нуля не добился
r25 - стабильно 0 при любых перерывах питания
r30 - стабильно 16, нуля не добился
вот, такие пироги...
еще результаты, с другим экземпляром меги32... неутешительные: повторяемости по регистрам нет никакой, все регистры имеют иное значение и сохранность данных практически не обеспечивают, т.е. записанный 0 практически мгновенно превращается в какое-то ненулевое значение... хотя при долгих перерывах есть тенденция добавления еще одного битика к "дефолтным"...
порадовал лишь r3 - как и в предыдущей меге четко видна разница между до-секундным перерывом питания и сверх-трехсекундным. в промежуточных интервалах точно не выверял...
первая мега использовалась не больше нескольких часов, перепрошивалась раз 50 (до начала экспериментов), а вторая - юзалась долго, перепрошивалась несколько сотен раз... может, износилась?
эффект налицо, но, видимо, для стабильности определения надо брать несколько регистров и анализировать их состояние...
Код
// регистр для эксперимента
#define REG "r10"
volatile __attribute__((section(".noinit"))) uint8_t mem;
__attribute__((section(".init0"), naked)) void get_r10(void){
register uint8_t tmp asm(REG);
mem = tmp;
}
int main(void){
printf_P(PSTR("\n" REG "=%u"),mem);
asm volatile ("ldi r16,0 \n mov " REG ",r16");
while(1);
}
#define REG "r10"
volatile __attribute__((section(".noinit"))) uint8_t mem;
__attribute__((section(".init0"), naked)) void get_r10(void){
register uint8_t tmp asm(REG);
mem = tmp;
}
int main(void){
printf_P(PSTR("\n" REG "=%u"),mem);
asm volatile ("ldi r16,0 \n mov " REG ",r16");
while(1);
}
P.S. как всегда, мега32 и STK500
вот еще результаты:
r0 - стабильно 18 (при очень котортких перерывах питания значение 16, нулевого не добился)
r1 - стабильно всегда 34, не добился иного
r2 - 0 всегда
r3 - помнит 0 до 1 секунды, при больших интервалах принимает значение 4 или 6
r15 - стабильно 1, изредка 3, нуля не добился
r20 - стабильно 22, нуля не добился
r25 - стабильно 0 при любых перерывах питания
r30 - стабильно 16, нуля не добился
вот, такие пироги...
еще результаты, с другим экземпляром меги32... неутешительные: повторяемости по регистрам нет никакой, все регистры имеют иное значение и сохранность данных практически не обеспечивают, т.е. записанный 0 практически мгновенно превращается в какое-то ненулевое значение... хотя при долгих перерывах есть тенденция добавления еще одного битика к "дефолтным"...
порадовал лишь r3 - как и в предыдущей меге четко видна разница между до-секундным перерывом питания и сверх-трехсекундным. в промежуточных интервалах точно не выверял...
первая мега использовалась не больше нескольких часов, перепрошивалась раз 50 (до начала экспериментов), а вторая - юзалась долго, перепрошивалась несколько сотен раз... может, износилась?
Цитата(ARV @ Jan 18 2010, 10:25)
....вот код для тестирования регистров. несколько экспериментов показали, что разные регистры по-разному реагируют на снятие питания....
Во-во вот и я с этого начал , только сначала ещё писал в регистр своё значение. В итоге вот "понравился" R7 , но при автономной работе макета , появлялись глюки . Зря только потраченное время.
Цитата
...я третий раз перечитываю текст программы и ничего не понимаю .... Ребят, только мне кажется, что ILYAUL курнул "непадецки"?
Одна загрузка константы в R16 через LPM... Ткните что-ли носом какой регистр там не обнуляется при старте?
Одна загрузка константы в R16 через LPM... Ткните что-ли носом какой регистр там не обнуляется при старте?
Забудьте Вы про проверки значений регистров , SRAM и емкостей АЦП - не надо это всё . Всё гораздо проще. Если Вы внимательно всё читали , то я написал алгоритм решения кратковременное выключение на Tiny13
Цитата
Запускаем первый режим при первом вкл фонарика , записывем его в EEPROM , при размыкании питания и вкл , проверяем режим равны меняем , записываем следуюший EEPROM и т.д. А можно просто счётчик режимов (как идея) ....
Расшифровываю , есть две абсолютно независимые от питания памяти в тини EEPROM и память программ. В памяти програм ( конкретно для выложенного кода) зарезервирован один байт со значением $55.
Вставили батарейки в фонарик - включили , первая команда после всех инит прочитать 1 ячейку EEPROM ( RCALL EEPROM_RD) которая заносит в регистр R17 (temp1) значение 1-ой ячейки EEPROM $FF.
Дальше из памяти програм командой LPM ( для тех кто не знает - команда чтения из памяти программ) получаем значение $55 ( в таблице - последняя строчка текста кода) .db $55,00 ( 00 не считается)
Сравниваем выяснем , что они не равны ( не может 55=FF) , CP temp, temp1 - зажигаем LED - записываем значение $55 в EEPROM . Любуемся на горящий LED.
Надоело, выкл вкл питание, Проходим тот же путь , что описано выше до строчки CP temp, temp1 , а вот тут и оказывается , что значение EEPROM $55 = значению $55 из памяти программ и здесь срабатывает команда -
раз равно , пшли помигаем светодиодом breq mode1. При этом заносим в EEPROM значение $56 . Наслаждаемся миганием светодиода . Надоело - передёрнули питание теперь значение $55 не равно значению $56 , светодиод будет опять гореть постоянно и так по кругу.
Цитата(ILYAUL @ Jan 18 2010, 11:54)
Забудьте Вы про проверки значений регистров , SRAM и емкостей АЦП - не надо это всё . Всё гораздо проще. Если Вы внимательно всё читали , то я написал алгоритм решения кратковременное выключение на Tiny13
жаль, что вы невнимательно читали тему. специально для вас конкретизирую: ваш алгоритм одинаково переключит режим и при выключении на 1 секунду, и при выключении на 30 секунд. а надо, чтобы при выключении на 30 секунд режим не менялся, а менялся только при выключении на 1 секунду (это я грубо и кратко задачу перефразировал). прочтите тему с первого поста!
Цитата(ARV @ Jan 18 2010, 12:01)
жаль, что вы невнимательно читали тему. специально для вас конкретизирую: ваш алгоритм одинаково переключит режим и при выключении на 1 секунду, и при выключении на 30 секунд. а надо, чтобы при выключении на 30 секунд режим не менялся, а менялся только при выключении на 1 секунду (это я грубо и кратко задачу перефразировал). прочтите тему с первого поста!
А помоему тема озаглавлена " Как распознать кратковременное выключение на Tiny13" , к тому же я написал , что мне лень писать распознование длительного отключения
Цитата(ILYAUL @ Jan 18 2010, 12:12)
А помоему тема озаглавлена " Как распознать кратковременное выключение на Tiny13" , к тому же я написал , что мне лень писать распознование длительного отключения
ну и где ваш ответ на "кратковременное" ? вы распознали "любое"
ILYAUL, извиини, конечно, но твои изыски с LPM меня заставляют в судорогах биться. LDI в твоём контроллере сгорел что-ли???
А задачу мы решаем как раз ту, которую тебе лень решать.
А задачу мы решаем как раз ту, которую тебе лень решать.
Цитата(VladislavS @ Jan 18 2010, 12:37)
ILYAUL, извиини, конечно, но твои изыски с LPM меня заставляют в судорогах биться. LDI в твоём контроллере сгорел что-ли???
А задачу мы решаем как раз ту, которую тебе лень решать.
А задачу мы решаем как раз ту, которую тебе лень решать.
Длинное это сколько , что бы потом разночтений не было . А LPM - я так привык писать. LDI - загрузка константы в регистор общего назначения, поясните как Вы хотите её использовать вместо LPM ? что-то не врублюсь. Хотя кажется понял , Вас смущает, что в таблице только одно значение, но каr Вы должны были сразу понять , код не окончательный и как он будет развиваться дальше , даже мне пока не все моменты ясны . Так , что пусть так и будет LPM .
Цитата(ILYAUL @ Jan 18 2010, 12:50)
А LPM - я так привык писать. LDI - загрузка константы в регистор общего назначения, поясните как Вы хотите её использовать вместо LPM ? что-то не врублюсь
Вы считаете что команда LPM загружает регистр данными из памяти програм.
А откуда по вашему берутся данные для загрузки в регистор общего назначения командой LDI ???
Цитата(ARV @ Jan 18 2010, 11:03)
эффект налицо, но, видимо, для стабильности определения надо брать несколько регистров и анализировать их состояние...
порадовал лишь r3 - как и в предыдущей меге четко видна разница между до-секундным перерывом питания и сверх-трехсекундным. в промежуточных интервалах точно не выверял...
порадовал лишь r3 - как и в предыдущей меге четко видна разница между до-секундным перерывом питания и сверх-трехсекундным. в промежуточных интервалах точно не выверял...
мне кажется, что даже если анализировать все регистры, то не будет 100% гарантии получения эффекта запоминания, а значит не будет и повторяемости. тем более на АВР и ПИК одновременно. тем более с учетом больших тиражей этих фонарей
если только создавать какой-то адаптивный алгоритм анализа регистров, но это уже почти искусственный интеллект, вряд ли в фонарях с этим заморачиваются
пока более-менее стабильный эффект получен с анализом конденсатора УВХ. сбои могут быть связаны с тем, что программа прерывается в произвольном месте. для устранения сбоев нужно анализировать резкое падение напряжения питания и выключаться, например, с логическим 0 на делителе. правда с ПИКом такой вариант не проходит
ну и емкость драйверов еще пощупать
Цитата(stells @ Jan 18 2010, 15:05)
мне кажется, что даже если анализировать все регистры, то не будет 100% гарантии получения эффекта запоминания, а значит не будет и повторяемости. тем более на АВР и ПИК одновременно. тем более с учетом больших тиражей этих фонарей
Чтобы была повторяемость д.б. автоподстройка. Но судя по отсутствию записи в EEPROM (есть только одна запись - следующий режим) её нет.
Можно понадеяться на статистику и попробовать сделать примитивнейшим образом - во всё неиспользуемое ОЗУ и регистры писать 0, а при включении считать число битов =1. А вдруг прокатит?!?
Т.е. после долгого выключения число битов =1 и =0 примерно равны. А после недолгого - число битов =0 будет больше (ещё будет сказываться обнуление).
Алгоритм такой:
1. Определяем регистры и ячейки ОЗУ, не используемые при работе программы. Условие очень простое т.к. для этой программы достаточно будет 8 регистров.
2. При запуске считаем кол-во битов =1 в избранных регистрах и ячейках ОЗУ. Назовем это число N1, а общее кол-во битов во всех этих регистрах и ячейках ОЗУ Nn.
3. Пишем во все эти регистры и ячейки ОЗУ 0. Этот пункт для последующего включения.
4. Сравниваем N1 с Nn/4.
4.1 Если N1<(Nn/4) - выключение было коротким. Т.е. сохранилось влияние обнуления по п.3 с предыдущего раза. Значит нужно менять режим.
4.2 Если N1>(Nn/4) - выключение было долгим. Т.е. влияние обнуления нет и кол-во битов =0 и =1 примерно одинаковое и равное Nn/2 - режим не меняем.
Я бы сейчас этим занялся, но макета никакого под руками нет и времени абсолютно ни на что не хватает. Но при первой же возможности займусь и код выложу, чтобы и на других процессорах проверить и статистику набрать...
Цитата(galjoen @ Jan 18 2010, 15:57)
2. При запуске считаем кол-во битов =1 в избранных регистрах и ячейках ОЗУ. Назовем это число N1, а общее кол-во битов во всех этих регистрах и ячейках ОЗУ Nn.
интересно, а есть на осциллограммах похожий временной интервал? 64 ячейки*8бит*5команд(к примеру)=2500тактов
Господа, всем спасибо за участие! Меня срывают в Израиль "спасать проект" - участвовать в дальнейших разборках временно не могу.
В боевой фонарь пока зашиваю следующий алгоритм:
1. При старте считываем режим из EEPROM и принимаем его за текущий, инкрементируем режим и записываем обратно в EEPROM.
2. Через 2-3 секунды подмаргиваем диодом и записываем в EEPROM текущий режим (делаем откат).
Собсвтвенно и всё. Как выяснилось в другом форуме, фонари с таким алгоритмом тоже есть. Может это даже и правильней - никаких недокументированных возможностей, никаких переходных процессов - все на штатном питании происходит.
На одной плате есть, но там похоже SUT так зашиты и непонятно когда точно он включается. На второй настолько быстрый старт, что я думаю 2500 тактов там не влезет.
В боевой фонарь пока зашиваю следующий алгоритм:
1. При старте считываем режим из EEPROM и принимаем его за текущий, инкрементируем режим и записываем обратно в EEPROM.
2. Через 2-3 секунды подмаргиваем диодом и записываем в EEPROM текущий режим (делаем откат).
Собсвтвенно и всё. Как выяснилось в другом форуме, фонари с таким алгоритмом тоже есть. Может это даже и правильней - никаких недокументированных возможностей, никаких переходных процессов - все на штатном питании происходит.
Цитата(stells @ Jan 18 2010, 16:38)
интересно, а есть на осциллограммах похожий временной интервал? 64 ячейки*8бит*5команд(к примеру)=2500тактов
На одной плате есть, но там похоже SUT так зашиты и непонятно когда точно он включается. На второй настолько быстрый старт, что я думаю 2500 тактов там не влезет.
Похоже, что все просто.
Помимо задействованного в схеме (ADC1), tiny13 имеет ещё и открытые, неподключенные входы АЦП. Открытый вход АЦП ведет себя так, что если на нём "повисела единица" - затем падение напряжения может длиться с десяток секунд...
Поэтому если какой-либо многофункциональный вывод сконфигурировать как выход и подать на него "единицу", а в момент пропадания питания (регистрируемого основным АЦП на ноге 7) успеть сконфигурировать этот вывод как вход АЦП - то после повторного включения питания остаточное напряжение на этом входе (на его паразитной емкости) отображает время, прошедшее после выключения.
Помимо задействованного в схеме (ADC1), tiny13 имеет ещё и открытые, неподключенные входы АЦП. Открытый вход АЦП ведет себя так, что если на нём "повисела единица" - затем падение напряжения может длиться с десяток секунд...
Поэтому если какой-либо многофункциональный вывод сконфигурировать как выход и подать на него "единицу", а в момент пропадания питания (регистрируемого основным АЦП на ноге 7) успеть сконфигурировать этот вывод как вход АЦП - то после повторного включения питания остаточное напряжение на этом входе (на его паразитной емкости) отображает время, прошедшее после выключения.
Цитата(VladislavS @ Jan 18 2010, 16:42)
В боевой фонарь пока зашиваю следующий алгоритм:
...
...
Не мешало бы делать проверку целостности ячейки после записи и в случае порчи включать "самый правильный" режим.
Цитата(Demeny @ Jan 18 2010, 17:43)
Похоже, что все просто.
...неподключенные входы...
...неподключенные входы...
Правильно . Вот там сейчас и роюсь, кое -что наклёвывается.
Цитата(Demeny @ Jan 18 2010, 17:43)
если какой-либо многофункциональный вывод сконфигурировать как выход и подать на него "единицу", а в момент пропадания питания (регистрируемого основным АЦП на ноге 7) успеть сконфигурировать этот вывод как вход АЦП - то после повторного включения питания остаточное напряжение на этом входе (на его паразитной емкости) отображает время, прошедшее после выключения.
можно и как подтянутый вход его сконфигурировать, но при оцифровке заряд паразитной емкости входа (~5пФ) перераспределится с зарядом конденсатора АЦП (14пФ) и все будет не так красиво, как Вам кажется на первый взгляд
Цитата(stells @ Jan 18 2010, 18:12)
можно и как подтянутый вход его сконфигурировать, но при оцифровке заряд паразитной емкости входа (~5пФ) перераспределится с зарядом конденсатора АЦП (14пФ) и все будет не так красиво, как Вам кажется на первый взгляд
Ну тогда при нормальной работе можно периодически переключать функционал вывода между "выход с лог. 1" и "вход АЦП", чтобы конденсатор АЦП всегда был подзаряжен и готов к отслеживанию времени выключения.
Но что-то мне подсказывает, что можно и без этого обойтись, видел я эти картинки разряда открытого входа АЦП - смотрится достаточно красиво, почти гауссов (полу-)колокол.
Цитата(МП41 @ Jan 18 2010, 17:46)
Не мешало бы делать проверку целостности ячейки после записи и в случае порчи включать "самый правильный" режим.
Ну само собой - при любом значении в EEPROM какой-то из валидных режимов все равно надо включить. Думаю, дядькам, которые знают про LDI, такие вещи очевидны.
Цитата(ARV @ Jan 18 2010, 11:03)
...
вот еще результаты:
r0 - стабильно 18 (при очень котортких перерывах питания значение 16, нулевого не добился)
r1 - стабильно всегда 34, не добился иного
r2 - 0 всегда
r3 - помнит 0 до 1 секунды, при больших интервалах принимает значение 4 или 6
r15 - стабильно 1, изредка 3, нуля не добился
r20 - стабильно 22, нуля не добился
r25 - стабильно 0 при любых перерывах питания
r30 - стабильно 16, нуля не добился
вот, такие пироги...
вот еще результаты:
r0 - стабильно 18 (при очень котортких перерывах питания значение 16, нулевого не добился)
r1 - стабильно всегда 34, не добился иного
r2 - 0 всегда
r3 - помнит 0 до 1 секунды, при больших интервалах принимает значение 4 или 6
r15 - стабильно 1, изредка 3, нуля не добился
r20 - стабильно 22, нуля не добился
r25 - стабильно 0 при любых перерывах питания
r30 - стабильно 16, нуля не добился
вот, такие пироги...
Может попробовать проверять скопом несколько ячеек памяти (допустим 10 или 20) и по среднему "обнулению" судить о продолжительности выключения? Брать, так сказать, статистикой.
Цитата(Demeny @ Jan 18 2010, 18:30)
чтобы конденсатор АЦП всегда был подзаряжен и готов к отслеживанию времени выключения.
это делали (см. например пост 155), но, во-первых, присутствуют какие-то отклонения результатов измерений, а, во-вторых (как справедливо заметил ISV), в ПИКах АЦП нет, а программа наверняка универсальная
при этом, что общего у вариантов на АВР и ПИК:
- диод и кондер по питанию;
- три драйвера светодиодов;
- компаратор на борту (и именно его вход в обоих случаях почему-то подключен к драйверам);
- внутренние РОН и ОЗУ
вот вероятнее всего что-то из этого списка и работает
Цитата(stells @ Jan 18 2010, 21:50)
это делали (см. например пост 155), но, во-первых, присутствуют какие-то отклонения результатов измерений,
имхо, повторяемость будет не 100%-ная.. а я за 2 года увлечения подобными фонарями ни разу не слышал о браке или глюках с переключением режимов. оно либо работает, либо сгорело Цитата(stells @ Jan 18 2010, 21:50)
во-вторых (как справедливо заметил ISV), в ПИКах АЦП нет, а программа наверняка универсальная
не факт. иначе, зачем было во всех схемах на Tiny вешать резисторы на отдельный порт.Цитата(stells @ Jan 18 2010, 21:50)
при этом, что общего у вариантов на АВР и ПИК:
- диод и кондер по питанию;
- три драйвера светодиодов;
тоже не оно. кондер с диодом - да, везде. а вот выход везде разный. более того, в некоторых тупых схемах проц еще и функции ШИМ-контроллера выполняет (в схеме повышения/понижения напряжения, кроме режимов).
- диод и кондер по питанию;
- три драйвера светодиодов;
кажется, на диаграмме было видно 2 записи в EEPROM... так вот, я думаю, что одна из записей как раз сохраняет "исходное" состояние тестового регистра, а второе - сам режим работы. при старте сравнивается "исходное" состояние и фактичнское, в итоге не тлько отличаем режимы/состояния, но и делаем автоподстройку... кстати, эффект от АЦП был проверен хотя бы на аре камней? есть уверенность, что он более повторяем, чем состояния регистров?
Цитата(ARV @ Jan 18 2010, 20:26)
я думаю, что одна из записей как раз сохраняет "исходное" состояние тестового регистра
так Вы же сами провели исследование по способности регистров устанавливаться в любимое состояние - там не видно, что наверняка через 2-3 секунды регистр его принимает
хотя по группе регистров можно попробовать. если это самое первое включение контроллера после прошивки, сформировать какой-нибудь избыточный код (CRC, LRC или Хэмминга) для группы (или всех) регистров и записать его в EEPROM. также в EEPROM записать, что первое включение уже было (поставить битик, что контрольный код уже сформирован). тогда при коротком отключении с высокой степенью вероятности контрольный код не совпадет с сохраненным. так?
или даже не заморачиваться с избыточными кодами, а сохранить в EEPROM копию любимых состояний всех РОН (только один раз это делать и поставить битик, что любимые состояния сохранены). тогда если хоть 1 бит неправильный, то было короткое отключение, а если все совпали - то длинное
Вот, выкладываю программу, предположительно определяющую длительность выключения питания:
Просьба, у кого есть возможность - попробуйте на реальных устройствах. Будет хоть какая то статистика. К сожалению, у меня сейчас проверить в реале возможности нет.
Всё сделал максимально железонезависимо. Нужно только задать начало и конец области ОЗУ. BegRAM и EndRAM соответственно. Но длина куска д.б. не больше 0x1FFF. Если у кого подключено внешнее ОЗУ - попробуйте на нём. Тоже интересно...
ЗЫ У нас сейчас жутко глючит интернет (3G Мегафон). В своих программах, которые это дело проверят, каждый 3-й пакет с ошибкой CRC. А тут без проверки, поэтому могут быть ошибки в коде. Что и было при первой попытке выложить...
Код
.org 0
rjmp begin
.SET BegRAM=0x60; начало участка ОЗУ включительно
.SET EndRAM=0x90; конец участка ОЗУ включительно
; длину больше 0x1FFF байт не делать т.к. возможно переполнение (не проверяется)
.DEF RG00=R26 ; это будет регистр всегда =0
.DEF Rtemp=R27 ; это будет рабочий регистр
.org 0x100 ; адрес после таблицы прерываний
begin:
eor RG00,RG00 ; регистр =0
ldi R28,0 ; 2 байта
ldi R29,0 ; счётчика 1 (N1)
ldi R30,low(EndRAM) ; регистр указатель Z
ldi R31,high(EndRAM)
Loop1:; цикл подсчёта кол-ва едениц в R29:R28 (35 тактов на байт)
ld Rtemp,Z ; читаем проверяемый байт
st Z,RG00 ; обнуляем на следующий раз
ror Rtemp ; выдвигаем бит N0
adc R28,RG00 ; прибавляем его
adc R29,RG00 ; к накопителю N1
ror Rtemp ; бит N1
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N2
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N3
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N4
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N5
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N6
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N7
adc R28,RG00
adc R29,RG00
subi R30,1 ; передвигаем
sbci R31,0 ; указатель
ldi Rtemp,high(BegRAM); проверим на конец
cpi R30,low(BegRAM)
cpc R31,Rtemp
brcc Loop1 ; C=0 - циклимся
; получили в R29:R28 кол-во битов=1 в выбранной части ОЗУ
subi R28,low((EndRAM-BegRAM+1)<<1); сравним с количеством бит
sbci R29,high((EndRAM-BegRAM+1)<<1); в этой части ОЗУ /4 (Nn)
brcc LgPoff
; это было короткое выключение питания
; тут зажигаем к.н. лампочку о коротком выключении
nop ; команда включения короткой лампы
rjmp Cnte
LgPoff:; это было длинное выключение питания
; тут зажигаем к.н. лампочку о долгом выключении
nop ; команда включения длинной лампы
Cnte:; тут начинается основная программа
rjmp Cnte
rjmp begin
.SET BegRAM=0x60; начало участка ОЗУ включительно
.SET EndRAM=0x90; конец участка ОЗУ включительно
; длину больше 0x1FFF байт не делать т.к. возможно переполнение (не проверяется)
.DEF RG00=R26 ; это будет регистр всегда =0
.DEF Rtemp=R27 ; это будет рабочий регистр
.org 0x100 ; адрес после таблицы прерываний
begin:
eor RG00,RG00 ; регистр =0
ldi R28,0 ; 2 байта
ldi R29,0 ; счётчика 1 (N1)
ldi R30,low(EndRAM) ; регистр указатель Z
ldi R31,high(EndRAM)
Loop1:; цикл подсчёта кол-ва едениц в R29:R28 (35 тактов на байт)
ld Rtemp,Z ; читаем проверяемый байт
st Z,RG00 ; обнуляем на следующий раз
ror Rtemp ; выдвигаем бит N0
adc R28,RG00 ; прибавляем его
adc R29,RG00 ; к накопителю N1
ror Rtemp ; бит N1
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N2
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N3
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N4
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N5
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N6
adc R28,RG00
adc R29,RG00
ror Rtemp ; бит N7
adc R28,RG00
adc R29,RG00
subi R30,1 ; передвигаем
sbci R31,0 ; указатель
ldi Rtemp,high(BegRAM); проверим на конец
cpi R30,low(BegRAM)
cpc R31,Rtemp
brcc Loop1 ; C=0 - циклимся
; получили в R29:R28 кол-во битов=1 в выбранной части ОЗУ
subi R28,low((EndRAM-BegRAM+1)<<1); сравним с количеством бит
sbci R29,high((EndRAM-BegRAM+1)<<1); в этой части ОЗУ /4 (Nn)
brcc LgPoff
; это было короткое выключение питания
; тут зажигаем к.н. лампочку о коротком выключении
nop ; команда включения короткой лампы
rjmp Cnte
LgPoff:; это было длинное выключение питания
; тут зажигаем к.н. лампочку о долгом выключении
nop ; команда включения длинной лампы
Cnte:; тут начинается основная программа
rjmp Cnte
Просьба, у кого есть возможность - попробуйте на реальных устройствах. Будет хоть какая то статистика. К сожалению, у меня сейчас проверить в реале возможности нет.
Всё сделал максимально железонезависимо. Нужно только задать начало и конец области ОЗУ. BegRAM и EndRAM соответственно. Но длина куска д.б. не больше 0x1FFF. Если у кого подключено внешнее ОЗУ - попробуйте на нём. Тоже интересно...
ЗЫ У нас сейчас жутко глючит интернет (3G Мегафон). В своих программах, которые это дело проверят, каждый 3-й пакет с ошибкой CRC. А тут без проверки, поэтому могут быть ошибки в коде. Что и было при первой попытке выложить...
Цитата(stells @ Jan 18 2010, 21:08)
сохранить в EEPROM копию любимых состояний всех РОН (только один раз это делать и поставить битик, что любимые состояния сохранены). тогда если хоть 1 бит неправильный, то было короткое отключение, а если все совпали - то длинное
P.S. естественно после контроля программа должна изменить содержимое РОН (проинвертировать). итак:
1.если при первом включении в первом регистре EEPROM записаны 1, то делаем п.2, иначе п.3
2.нулевую ячейку EEPROM пропускаем (на всякий случай), в первую ячейку записываем нули (копии любимых состояний сохранены), в следующие 32 ячейки копируем РОН и переходим к п.4
3.значения РОН сравниваем с сохраненными любимыми значениями из EEPROM. если совпали, то длинное отключение, если хоть 1 бит не совпал - то короткое. меняем или не меняем режим
4.инвертируем все РОН
5.выполняем основную программу
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.