[stells 12]

2. При запуске считаем кол-во битов =1 в избранных регистрах и ячейках ОЗУ. Назовем это число N1, а общее кол-во битов во всех этих регистрах и ячейках ОЗУ Nn.

интересно, а есть на осциллограммах похожий временной интервал? 64 ячейки*8бит*5команд(к примеру)=2500тактов

[VladislavS 39]

Господа, всем спасибо за участие! Меня срывают в Израиль "спасать проект" - участвовать в дальнейших разборках временно не могу.

 

В боевой фонарь пока зашиваю следующий алгоритм:

1. При старте считываем режим из EEPROM и принимаем его за текущий, инкрементируем режим и записываем обратно в EEPROM.

2. Через 2-3 секунды подмаргиваем диодом и записываем в EEPROM текущий режим (делаем откат).

 

Собсвтвенно и всё. Как выяснилось в другом форуме, фонари с таким алгоритмом тоже есть. Может это даже и правильней - никаких недокументированных возможностей, никаких переходных процессов - все на штатном питании происходит.

 

интересно, а есть на осциллограммах похожий временной интервал? 64 ячейки*8бит*5команд(к примеру)=2500тактов

На одной плате есть, но там похоже SUT так зашиты и непонятно когда точно он включается. На второй настолько быстрый старт, что я думаю 2500 тактов там не влезет.

[Demeny 0]

Похоже, что все просто.

Помимо задействованного в схеме (ADC1), tiny13 имеет ещё и открытые, неподключенные входы АЦП. Открытый вход АЦП ведет себя так, что если на нём "повисела единица" - затем падение напряжения может длиться с десяток секунд...

Поэтому если какой-либо многофункциональный вывод сконфигурировать как выход и подать на него "единицу", а в момент пропадания питания (регистрируемого основным АЦП на ноге 7) успеть сконфигурировать этот вывод как вход АЦП - то после повторного включения питания остаточное напряжение на этом входе (на его паразитной емкости) отображает время, прошедшее после выключения.

[mp41 0]

В боевой фонарь пока зашиваю следующий алгоритм:

...

Не мешало бы делать проверку целостности ячейки после записи и в случае порчи включать "самый правильный" режим.

[ILYAUL 0]

Похоже, что все просто.

...неподключенные входы...

Правильно . Вот там сейчас и роюсь, кое -что наклёвывается.

[stells 12]

если какой-либо многофункциональный вывод сконфигурировать как выход и подать на него "единицу", а в момент пропадания питания (регистрируемого основным АЦП на ноге 7) успеть сконфигурировать этот вывод как вход АЦП - то после повторного включения питания остаточное напряжение на этом входе (на его паразитной емкости) отображает время, прошедшее после выключения.

можно и как подтянутый вход его сконфигурировать, но при оцифровке заряд паразитной емкости входа (~5пФ) перераспределится с зарядом конденсатора АЦП (14пФ) и все будет не так красиво, как Вам кажется на первый взгляд

[Demeny 0]

можно и как подтянутый вход его сконфигурировать, но при оцифровке заряд паразитной емкости входа (~5пФ) перераспределится с зарядом конденсатора АЦП (14пФ) и все будет не так красиво, как Вам кажется на первый взгляд

Ну тогда при нормальной работе можно периодически переключать функционал вывода между "выход с лог. 1" и "вход АЦП", чтобы конденсатор АЦП всегда был подзаряжен и готов к отслеживанию времени выключения.

Но что-то мне подсказывает, что можно и без этого обойтись, видел я эти картинки разряда открытого входа АЦП - смотрится достаточно красиво, почти гауссов (полу-)колокол. :rolleyes:

[VladislavS 39]

Не мешало бы делать проверку целостности ячейки после записи и в случае порчи включать "самый правильный" режим.

 

Ну само собой - при любом значении в EEPROM какой-то из валидных режимов все равно надо включить. Думаю, дядькам, которые знают про LDI, такие вещи очевидны. :)

[adc 0]

...

вот еще результаты:

r0 - стабильно 18 (при очень котортких перерывах питания значение 16, нулевого не добился)

r1 - стабильно всегда 34, не добился иного

r2 - 0 всегда

r3 - помнит 0 до 1 секунды, при больших интервалах принимает значение 4 или 6

r15 - стабильно 1, изредка 3, нуля не добился

r20 - стабильно 22, нуля не добился

r25 - стабильно 0 при любых перерывах питания

r30 - стабильно 16, нуля не добился

 

вот, такие пироги... :)

Может попробовать проверять скопом несколько ячеек памяти (допустим 10 или 20) и по среднему "обнулению" судить о продолжительности выключения? Брать, так сказать, статистикой.

[stells 12]

чтобы конденсатор АЦП всегда был подзаряжен и готов к отслеживанию времени выключения.

это делали (см. например пост 155), но, во-первых, присутствуют какие-то отклонения результатов измерений, а, во-вторых (как справедливо заметил ISV), в ПИКах АЦП нет, а программа наверняка универсальная

 

при этом, что общего у вариантов на АВР и ПИК:

- диод и кондер по питанию;

- три драйвера светодиодов;

- компаратор на борту (и именно его вход в обоих случаях почему-то подключен к драйверам);

- внутренние РОН и ОЗУ

вот вероятнее всего что-то из этого списка и работает

Изменено 18 января, 2010 пользователем stells

[ISV 0]

это делали (см. например пост 155), но, во-первых, присутствуют какие-то отклонения результатов измерений,

имхо, повторяемость будет не 100%-ная.. а я за 2 года увлечения подобными фонарями ни разу не слышал о браке или глюках с переключением режимов. оно либо работает, либо сгорело :)

 

во-вторых (как справедливо заметил ISV), в ПИКах АЦП нет, а программа наверняка универсальная

не факт. иначе, зачем было во всех схемах на Tiny вешать резисторы на отдельный порт.

 

при этом, что общего у вариантов на АВР и ПИК:

- диод и кондер по питанию;

- три драйвера светодиодов;

тоже не оно. кондер с диодом - да, везде. а вот выход везде разный. более того, в некоторых тупых схемах проц еще и функции ШИМ-контроллера выполняет (в схеме повышения/понижения напряжения, кроме режимов).

[ARV 1]

кажется, на диаграмме было видно 2 записи в EEPROM... так вот, я думаю, что одна из записей как раз сохраняет "исходное" состояние тестового регистра, а второе - сам режим работы. при старте сравнивается "исходное" состояние и фактичнское, в итоге не тлько отличаем режимы/состояния, но и делаем автоподстройку... кстати, эффект от АЦП был проверен хотя бы на аре камней? есть уверенность, что он более повторяем, чем состояния регистров?

[stells 12]

я думаю, что одна из записей как раз сохраняет "исходное" состояние тестового регистра

так Вы же сами провели исследование по способности регистров устанавливаться в любимое состояние - там не видно, что наверняка через 2-3 секунды регистр его принимает

 

хотя по группе регистров можно попробовать. если это самое первое включение контроллера после прошивки, сформировать какой-нибудь избыточный код (CRC, LRC или Хэмминга) для группы (или всех) регистров и записать его в EEPROM. также в EEPROM записать, что первое включение уже было (поставить битик, что контрольный код уже сформирован). тогда при коротком отключении с высокой степенью вероятности контрольный код не совпадет с сохраненным. так?

 

или даже не заморачиваться с избыточными кодами, а сохранить в EEPROM копию любимых состояний всех РОН (только один раз это делать и поставить битик, что любимые состояния сохранены). тогда если хоть 1 бит неправильный, то было короткое отключение, а если все совпали - то длинное

Изменено 18 января, 2010 пользователем stells

[galjoen 0]

Вот, выкладываю программу, предположительно определяющую длительность выключения питания:

.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

Просьба, у кого есть возможность - попробуйте на реальных устройствах. Будет хоть какая то статистика. К сожалению, у меня сейчас проверить в реале возможности нет.

Всё сделал максимально железонезависимо. Нужно только задать начало и конец области ОЗУ. BegRAM и EndRAM соответственно. Но длина куска д.б. не больше 0x1FFF. Если у кого подключено внешнее ОЗУ - попробуйте на нём. Тоже интересно...

 

ЗЫ У нас сейчас жутко глючит интернет (3G Мегафон). В своих программах, которые это дело проверят, каждый 3-й пакет с ошибкой CRC. А тут без проверки, поэтому могут быть ошибки в коде. Что и было при первой попытке выложить...

[stells 12]

сохранить в EEPROM копию любимых состояний всех РОН (только один раз это делать и поставить битик, что любимые состояния сохранены). тогда если хоть 1 бит неправильный, то было короткое отключение, а если все совпали - то длинное

P.S. естественно после контроля программа должна изменить содержимое РОН (проинвертировать). итак:

1.если при первом включении в первом регистре EEPROM записаны 1, то делаем п.2, иначе п.3

2.нулевую ячейку EEPROM пропускаем (на всякий случай), в первую ячейку записываем нули (копии любимых состояний сохранены), в следующие 32 ячейки копируем РОН и переходим к п.4

3.значения РОН сравниваем с сохраненными любимыми значениями из EEPROM. если совпали, то длинное отключение, если хоть 1 бит не совпал - то короткое. меняем или не меняем режим

4.инвертируем все РОН

5.выполняем основную программу

Изменено 18 января, 2010 пользователем stells