Attiny15L таймер не считает или ошибся в программе?

[Volodiatel]

Здравствуйте! Написал программу для управления двумя нагрузками под сабжевый контроллер. Внешними импульсами с частотой сети 50 Гц активируется запуск нагрузок, к этому-же выводу подключен таймер TMR0. Нагрузки отключаются либо при пропадании напряжения сети, либо при нескольких переполнениях таймера TMR0. Так-же происходит переключение нагрузок при кратковременых пропаданиях напряжения сети (более 164 мС). Импульсы сети подаются на INT0 (PB2 вывод 7). Для исключения глюка в Протеусе, выводы PB1(вывод 6) и PB2 соединены между собой. Проблема в том, что в эмуляции все работает. За исключением задержки (на таймере TMR1), которая составляет 2,8 сек. Но в железе нагрузки не отключаются после выдержки времени. Я начинающий на этом поприще, подскажите, что я не так делаю. Может есть какие-то нюансы, которые я не учел? Было предположение, что не считает таймер TMR0, но замена его на программный счетчик проблемы не решила. (Создал еще одну переменную и считал количество прерываний по INT0)

Текст программы такой:

Спойлер

.include "tn15def.inc"

.equ out_lamp = 3; выход управления освещением
.equ out_vent = 4; выход управления вентилятором

.def flags = R22; регистр флагов
.equ power = 0; flags для фильтрации помех
.equ vent = 1; flags,1 флаг включения вентилятора
.def mode = R23 ; переменная для хранения режима работы 01- лампа, 10 - вентилятор, 11 - лампа и вентилятор
.equ vent_mode = 0;mode,0 вентилятор
.equ lamp_mode = 1;mode,1 лампа

.def delay = R19 ; переменная для хранения времени задержки до 22 мин
.def delay_H = R20; переменная для хранения времени задержки выше 22 мин
.def ms_delay = R21 ; переменная для хранения времени задержки выключения выключателя

.def temp = R16 ; регистр временного хранения
.def temp_int = R17 ; временная переменная для использования в прерывании
.def temp_sreg = R18 ;временная для SREG



.cseg
.org 0

;векторы прерываний
rjmp init ; reset On
rjmp int_int0 ; INT0
reti; I/O pins off
reti; Timer1 compA Off
rjmp int_timer1; Timer1 overlow
rjmp int_timer0; Timer0 overlow
reti; EEPROM ready Off
reti; Analog Comp Off
reti; ADC conversion Off

;инициализация при первом запуске
init:

; ldi temp, 0x67
; out OSCCAL,temp ; тактовая частота для протеуса


sbi ACSR,ACD ;отключить компаратор

; ldi temp,0b10000000
; out ACSR,temp;для отладки в мплабе, в протеусе работает верхняя строчка. (в железе пробовал и так, и так, не влияет)

ldi temp,0b01000000 ;настройка прерываний
out gimsk,temp ; разрешить внешнее прерывание по INT0
ldi temp,0b00000011
out MCUCR,temp ; настройка прерывания INT0 по фронту

; ldi temp,(1<<INTF0)
; out GIFR,temp ; для протеуса, почему-то устанавливается флаг прерывания при разрешении прерываний по INT0, поэтому его опускаем принудительно (в железе пробовал и так и так, не влияет)

ldi temp,( 1<<TOIE1|1<<TOIE0)
out timsk,temp ; разрешить прерывания при переполнении таймеров TMR0 и TMR1

ldi temp,0b00011000 ;настройка порта
out ddrb,temp;PB3,PB4 на выход


ldi mode,3; запись режима лампа + вентилятор



;_____включили выключатель, запускаем систему, согласно режима работы ________
on:
;выдержка таймера устанавливается в зависимости от режима

clr temp
out tcnt1,temp; обнуление таймеров
out tcnt0,temp

ldi ms_delay,1 ; задержка 164мс

; ldi delay,255; 5,12 сек*255 = 22мин пока отключана
ldi delay,2; для проверки,основной режим работы 10 сек.

; sbrc mode,lamp_mode; если включено освещение включаем 1 час выдежки
; ldi delay_H,2; 22мин*3 = 64мин.(2-1-0 3 такта)
; для проверки, пока отключена
;_____

ldi temp,(1<<CS02|1<<CS01|1<<CS00)
out tccr0,temp ;запуск таймера с внешним входом по фронту
sei ; разрешаем прерывания

on_wait: ;ожидаем наличия сетевого напряжения
sbrs flags,power
rjmp on_wait

; ldi temp,(1<<PSR1)
; out SFIOR,temp ; сброс прескаллера на всякий случай, пробовал - не влияет, отключил

ldi temp,(1<<CS13|1<<CS12|1<<CS11|1<<CS10)
out tccr1,temp ;запуск таймера TMR1 с предделителем СК/1024, переполнение через 164 мс по эмуляции 2,8 сек, в железе вроде нормально


sbrc mode,lamp_mode
sbi PORTB,out_lamp
sbrc mode,vent_mode
sbi PORTB,out_vent ; запуск вентилятора и лампы согласно режима работы


stopwait:
tst delay_H ;проверка срабатывания таймера общей выдержки
brne off_on_en
tst delay
breq stopall

off_on_en:
tst ms_delay ;проверка срабатывания выключателя
breq off_on
rjmp stopwait

;========обработка включения/выключения выключателя===========
off_on:
cli ; запретить прерывания
cbi portb,out_vent; выключаем все
cbi portb,out_lamp

clr temp
out tccr0,temp
out tccr1,temp ; стоп таймеры

cbr flags,(1<<power)

dec mode ;переключение режима от большего числа к меньшему
tst mode
brne on
ldi mode,3;кольцевание режима 3-2-1-3 и т.д.

rjmp on
;=====================





;__________________ После отработки таймера выдержки___________________________

stopall:
cbi portb,out_lamp; выключаем освещение
sbrc mode,vent_mode; если вентилятор был включен - выключаем на 22 мин.( пока 5 сек)
rjmp vent_off

;__________________ждем выключения-включения выключателя _____

stop_1: ;отработка включения/выключения выключателя
tst ms_delay
brne stop_2
rjmp off_on


stop_2:; выключатель не выключался
; вентилятор включить на 1 мин каждые 22 мин. (пока 5 сек включен, 5 сек выключен)
tst delay ;проверка таймера
brne stop_1
sbrc flags,vent
rjmp vent_off
sbi PORTB,out_vent;включение вентилятора
sbr flags,(1<<vent); установка флага включенного вентилятора

ldi delay,1 ; для проверки. время работы вентилятора 5 сек.
; ldi delay,12; установка выдержки 1 мин (пока отключено)

rjmp stop_1

vent_off:;выключение вентилятора на 22 мин.
cbi PORTB,out_vent
cbr flags,(1<<vent);сброс флага включеного вентилятора

ldi delay,1 ;для проверки, время паузы вентилятора 5 сек
; ldi delay,255; установка выдержки 22 мин. (пока отключено)

rjmp stop_1
;_____

;+++++++ Обработка прерываний +++++++++++++++++++++++++++++++
int_int0:
;каждый фронт импульса сети сбрасывает счетчик задержки выключателя
in temp_sreg,SREG

clr temp_int
out tcnt1,temp_int
ldi ms_delay,1


sbr flags,(1<<power)

out SREG,temp_sreg
reti

int_timer0: ;счет таймера переполненй каждые 5,12 сек

in temp_sreg,SREG

subi delay,1
sbci delay_H,0

out SREG,temp_sreg
reti

int_timer1: ;счет таймера переполнений 164 мС
in temp_sreg,SREG

dec ms_delay

out SREG,temp_sreg
reti

Последний раз редактировалось Volodiatel Чт янв 16, 2020 18:42:34, всего редактировалось 1 раз.

[akl]

Код:

;subi delay,1 ;(пробовал и так и так, не влияет)
dec delay
sbci delay_H,0


Команда dec не работает с флагом C! Поэтому должна быть команда subi

[BOB51]

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

[Volodiatel]

1.JPG

(79.4 KiB) Скачиваний: 239

akl писал(а):

Код:

;subi delay,1 ;(пробовал и так и так, не влияет)
dec delay
sbci delay_H,0


Команда dec не работает с флагом C! Поэтому должна быть команда subi

Спасибо, это я уже от безысходности... Конечно, оставлю subi.

Пока переменная delay_H равна 0, для проверки, что-бы не ждать час.

Схему проверки кода в железе - выкладываю:

1.JPG

(79.4 KiB) Скачиваний: 239

Это не совсем детектор нуля, скорее детектор наличия импульсов сетевого напряжения.Импульсы во первых сбрасывают счетчик TMR1 по прерыванию INT0 , что-бы не происходило переполнения и не менялся режим, и управляют счетом таймера TMR0 отсчитывая время, после которого нагрузки (светодиоды) выключаются. Сейчас режим работы такой - обе нагрузки включаются при возникновении импульсов сети, через 10 сек обе нагрузки выключаются и одна из нагрузок начнет включаться/выключаться с интервалом 5 сек/5 сек. Питание микроконтроллера не выключается. При выключении импульсов сети и последующем включении, происходит смена режимов (одна из нагрузок или обе нагрузки включаются и таймер начинает считать заново). Вот переключение режимов работает в железе, то есть прерывание по INT0 происходит, но нагрузки (или одна из нагрузок в зависимости от режима работы) не выключаются через 10 сек.

[BOB51]

Может вот такую поставить?
http://img.radiokot.ru/files/20529/1r6lu2clr1.JPG

[Volodiatel]

BOB51 писал(а):

Может вот такую поставить?
http://img.radiokot.ru/files/20529/1r6lu2clr1.JPG

Ну, мне чем проще, тем лучше. Осциллом смотрел - импульсы чистые от 0 до +5В. В проекте не будет гальванической развязки, так что обойдусь вообще резистивным делителем. Это пока, чтобы йоком не токнуло... Да и частота входящих импульсов 50 Гц, а на предложенной схеме - 100Гц. Можно перерасчитать время задержки, но устройство хотя-бы работать должно, а тут - тупик.

[BOB51]

Там энергопотребление и разогрев деталюшек значительно отличаются.
Да и форма импульса получше/стабильнее (и другая частота - по импульсу на каждый полупериод).
Ну то уже лишь предложение "на посмотрямс".

Относительно программки...
Проще набросать заново под конкретный алгоритм.
В Вашем случае описание алгоритма неполное - ибо добавлена еще задержка по С/Т1, для каких-то неописанных нужд.
Дешифровать чужой код для получения исходной задачи с последующим его(кода)анализом задачка требующая несколько большей, чем нужно мозготрепки.
Скинете полное описание алгоритма - возможно и гляну попристальнее, чего сделать надо...

Ну и кроме проччего такой автомат превосходно симулируется и средствами самой AVR Studio (в частности старой 4.19).

Еще один вопрос - а к чему именно тини15?
Это ведь весьма редкостный старый МК (на сегодня режим имитации имеется у аттини25/45/85) в основном для высокоскоростной обработки интервалов времени. Для обычного бытового таймера такой режим явно избыточный.
Просто из-за того что есть в наличии?
тинька 13-я заметно более распространена...

[Volodiatel]

Как это должно работать - поясняю.... Включаем выключатель, подающий питание на освещение и вентилятор, находящиеся в ванной. Выключатель один, нагрузки 2, поэтому управляем МК. Загорается свет, запускается вентилятор. Это 3 режим. Запускается таймер на TMR0 с внешним входом, отсчитывающий выдержку 1 час (для проверки у меня стоит время 10 сек). Каждое переполнение таймера происходит через 5,12 сек , поэтому считаем переполнения (delay) - это получается 5,12с*256=22 мин приблизительно. Переменная delay_H считает количество переполнений delay, то есть 3*22 приблизительно час. Если выключатель выключить и включить на время, большее чем 164 мС, а это время определяется работой таймера tmr1 и переменной ms_delay (я просто еще не решил, какая будет задержка, поэтому ввёл переменную), режим работы устройства переключится на следующий, то-есть на только освещение, а вентилятор выключится. Следующий режим -только вентилятор. Отсчет времени начнется сначала. Задержка переключения на TMR1 нужна, что-бы режим не переключался от "миганий света", то есть от кратковременных пропаданий электричества длительностью в несколько периодов. Далее, если свет не включен, время работы вентилятора составит 22 мин. Если время работы подходит к концу, а выключатель не трогали, освещение и вентилятор отключатся. Но вентилятор будет включаться каждые 22 мин на 1 мин (для проверки 5 сек работает, 5 сек выключен), пока не щелкнут выключателем кратковременно или не выключат его на длительное время, что приведет к пропаданию питания МК. TMR1 сбрасывается в прерывании INT0 импульсами сетевого напряжения. Прерывание настроено по фронту импульса. По фронту настроен и счет TMR0. Я пробовал различные комбинации (фронт/спад, спад/спад, спад фронт), устройство не выключает нагрузку. В эмуляторе все работает. Я приложу проект в Протеусе, правда он версии 8.8.

А почему этот контроллер? Да потому, что у меня есть их много.... Не выбрасывать же?... Просто хочется разобраться.... На 13-м я писал, там Си и все предсказуемо. Ну, относительно, конечно, но проблем вроде не возникло. На 15 контроллер компилятор си не предусмотрен - хороший повод изучить ассемблер. Да и с симулятором все хорошо, правда в Протеусе. Мплабом симулил только на начальном этапе, куски кода, от всяких детских ошибок. АВРстудио не симулил. Кстати, последняя АВРстудио поддерживает 15 тиньки. 6-я и 5-я - без поддержки этих МК.

Вложения

Timersu.zip

(18.61 KiB) Скачиваний: 203

[BOB51]

Примитив с трехуровневым аппаратным стеком (даже у "куцехвостых среднемладших" ПИКов и то 8-уровневый аппаратный стек) и отсутствием ОЗУ (наличие только файла СОЗУ) для тренировки под ассемблером?
Да еще при тактовой 1,6МГц (единственно возможной).
Садомазохизм однако...

У меня тинька 12-я завалялась, однако ставить ее куда в более-менее сложное приложение сегодня просто себе дороже (это несмотря на наличие распечатки даташита с "заметками на полях" и проработанных шаблонов-заготовок под ассемблер).
А 15-ю при наличии 13й и 25/45/85 вообще в расчет не брал - делать проработку документации под разовую заморочку однако влоом...
Ассемблер же (в отличии от Си) требует наличия под руками дотошно проработанного документа, особо ежли объём ПЗУ всего-то под 256 команд (512 байт для АВРки=256 командных слов ибо команда 2 байтовая). Да и без подпрограмм в данном случае не обойтись, добавим прерывания - а это тоже СТЕК... В результате МК вроде и есть... И в то же время - всего-то или "коллекционный образец" или для простейших автоматов сгодится.

[akl]

ATtiny15 мне очень нравилась. Можно сказать с неё начинал. Примитивна как лом.
Volodiatel Не нравится мне Ваш формирователь, если он реализован так как нарисован. Нет разрядной цепи конденсатора.

Спойлер

Вложения

Формирователь_20мс.PNG

(12.94 KiB) Скачиваний: 234

Последний раз редактировалось akl Пт янв 17, 2020 13:24:37, всего редактировалось 1 раз.

[BOB51]

В принципе само формирование алгоритма топикстартером представляется весьма спорным.

С моего взгляду...
Имеем электронную версию программно управляемого переключателя рода работы.
Пока не вдаваясь в вопрос питания...
Подача напряжения на "устройство", включающее в себя два вида нагрузки -"вентилятор" и "лампу"
вызывает переход к исходно (или ранее) определенному состоянию.
Как вариант рассматривается:
1. "вентилятор" + "лампа" + дополнительный опцион регулирования;
2. "вентилятор" + дополнительный опцион регулирования;
3. "лампа" + дополнительный опцион регулирования;
4. отключение нагрузок и ... переход в режим ожидания очередного включения...
"Агентом переключения" является отсутствие питающего нагрузку напряжения в пределах
"больше, чем минимальное" и "менее, чем максимальное" - определяется вобщем в "условных енотах"...

Реализация пункта 4 зависит от выбранной схемы питания нашего эдектронного переключателя - аккумулятор или сетевой источник.
Данный пункт топикстартер "упустил"...
Несмотря на "упущения" сам алгоритм не требует чего-то более чем базового генератора тайм-сетки и программных счетчиков.
Сигнал перехода через нуль необходим разве что для определения команд вида "кратковременное отключение источника питания нагрузки" и его реализация как на аппаратном, так и на программном уровне может варьироваться в зависимости от примененной схемы питания всего усторйства на МК.
В остальном... Реализация под аттини13 не представляет проблем. Могу чегось нашкарябать... Относительно 15-й мне явно ВЛОМ - там уже алгоритм пущай самостоятельно правит...

[Volodiatel]

По поводу схемы: виноват, правил на скорую руку. Вот то, что в железе:

2.JPG

(78.48 KiB) Скачиваний: 245

Уважаемый ВОВ51. Огромное спасибо за ваше участие в моей проблеме. Я только изучаю ассемблер, и могу допустить какие-то вещи, для людей с опытом совсем простые, но для меня еще не очевидные. Я просто хочу разобраться, где я накосячил, или есть какие-нибудь особенности в применении того, что я изобразил. Я не прошу дорабатывать, изменять или делать заново устройство, которое я тут наваял на другом контроллере, другими методами или как видите вы. Я просто хочу понять, что-бы не допускать каких-либо ошибок в дальнейшем. Ни в коем случае не хочу вас обидеть или задеть. По крайней мере я благодарен за те советы, что вы мне дали.

А пока..... Вопрос остается открытым. Если не придираться к алгоритму и реализации, почему программа работает в Протеусе и не работает в железе? Что я уже только не пробовал.... Кстати, дебаг в Атмел студио 7.0 для этого контроллера у меня не заработал...... Говорит нет инструмента для дебаггинга.....

Еще вопрос. Может глупый. А есть методы контроля регистров и переменных в живом контроллере? Ну, так-же, как в Протеусе? Загрузил программу и пошагово или по точкам останова ее выполняешь....

Добавлено after 1 hour 38 minutes 45 seconds:
Вдогонку.... Вычитал в даташите вот такое примечание:
When changing the ISC10/ISC00 bits, INT0 must be disabled by clearing its Interrupt Enable bit in the GIMSK register. Otherwise
an interrupt can occur when the bits are changed.

Я правильно понял, что Атмел рекомендует сначала настроить биты ISC10/ISC00, а уже потом настраивать маску прерываний в регистре GIMSK? Я поменял строчки местами (стало так):

ldi temp,0b00000011
out MCUCR,temp ; настройка прерывания INT0 по фронту

ldi temp,0b01000000 ;настройка прерываний
out gimsk,temp ; разрешить внешнее прерывание по INT0


Глюк в Протеусе исчез. Значит не глюк? А вот в железе ничего не изменилось. И еще заметил, что если включить питание без синхронизации, происходит кратковременное включение нагрузки. Значит происходит прерывание? Почему? Из-за чего может подниматься флаг прерывания, если оно не вызывается внешним сигналом? Прерывание настраивается по фронту импульса.

[BOB51]

Если чего-то непонятно - Делаем все заново.
Делаем программные тест-модули с жестко и однозначно исполняемым алгоритмом и четко понимаемым кодом да явноопределяемой индикацией состояния исполнения теста. Гоняем те тесты и корректируем программу по полученным результатам.
Отрабатываются каждый участок программы по-отдельности, а затем проверяется общая сборка с "пошаговой пристыковкой".
Насчет "в симуляторе работает, а в реале нет" - симулятор - не железо, а программа. Их тоже люди пишут.
Простейший функционал обычно В БОЛЬШИНСТВЕ СЛУЧАЕВ работает нормально. А вот имитация аппаратно-зависимых ресурсов чаще всего имеет определенные ограничения. У Вас задействованы аж три ресурса - оба таймера и внешние прерывания (это помимо вызова подпрограмм).
Для МК, имеющего всего 3-уровневый аппаратный стек это весьма большая угроза "уйти в нежданчик" из-за случайных взаимоналожений вызовов от аппаратных модулей и текущих подпрограмм.
Как я уже выше говорил - проверить можно лишь при наличии самого МК (как и прикладной код детально проанализировать - симулятор тут не поможет).
Если бы речь шла только об анализе на уровне алгоритмов и программ не касающихся аппаратных модулей (работа АЛУ, машинных команд, ОЗУ, ПЗУ)- тогда можно чего сказать. А в программе, использующей аппаратные модули необходима и проработка документации и проработка еррат и макетные тесты. Тут Вам придется ждать тех, кто с данным кристаллом плотно работает.
Касательно приемов работы с аппаратными модулями...
Обычно сначала инициализируются данные "по умолчанию" (если имеются - например для таймеров или регистров, задающих параметры работы и при том еще и соблюдаем последовательность загрузки/чтения байтов в случае если регистры данных двухбайтовые), затем задается конфигурация, затем разрешаем прерывания и лишь в конце даем запуск (касательно таймеров).
Попытка смены данных и/или конфигурации после разрешения прерываний/запуска "на ходу" - без остановки модуля и/или предварительного запрета прерываний - требует детальнейшей проработки (часто приводит к критическим ошибкам).

[Volodiatel]

BOB51 писал(а):

Если чего-то непонятно - Делаем все заново.

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

В остальном согласен с вами. Буду отлаживать программу по функциональным частям в железе, так-же как делал это в симуляторе.

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

[BOB51]

Это ПРОГРАММИРОВАНИЕ - пора привыкать к тому, что не всякий изначально задуманный алгоритм в конечном итоге будет удачным.
Скорее наоборот. Так что попал в "цейтнот" - забудь все и начинай с чистого листа.

Помимо прочего есть еще проблема сохранения запроса на прерывание в случае отложенного прерывания и/или снятия сигнала источника запроса к моменту "освобождения очереди".
Так что смотрим соответствующие "нюансы" - особо в отношении режима "внешних прерываний".
Я уже выше высказывал предположение, что использовать оба таймера и внешние прерывания в данной конструкции весьма избыточное мероприятие.
А вот вопрос "от чего всю самоделку кормим" значительно более важен при планировании алгоритма.
Однако... Опять же - тест/отладку могу только относительно 13-й тиньки сделать.
Далее, базируясь на алгоритме - адаптируем его под соответствующий кристалл.

Volodiatel писал(а):

Здравствуйте! Написал программу для управления двумя нагрузками под сабжевый контроллер.

Можешь просто описать словами свои задумки по алгоритму, без всяких там привязок к внутренностям МК и протеусу? Так как то, что ты пытаешься воспроизвести «кучей» таймеров и внешних прерываний не значит что это единственно правильное решение. А то за много букаф не понятно, что там должно быть.

[BOB51]

Да и ПОЛНУЮ СХЕМУ необходимо представить, а не "обгрызенный пример".
Я не случайно указал на то, что в зависимости от выбранного варианта питания устройства алгоритм программы будет весьма кардинально отличаться (и соответственно реал и ЩПРОТ дадут несовместимые результаты).
Вариант 1
http://img.radiokot.ru/files/20529/23trieoyfq.GIF
Предусматривается работа с сетевым источником питания контроллера.
Датчиком наличия напряжения/сработки главного выключателя является схемное решение в самом источнике
(если источник трансформаторного типа, а не "импульсник" - иначе придется таки зеро-кросс ставить).
Алгоритм "спящего режима" не имеет.
Вариант 2
http://img.radiokot.ru/files/20529/23trj2qqz1.GIF
Работа от акумулятора/батарейки.
Наличие датчика зеро-кросс ОБЯЗАТЕЛЬНО.
Алгоритм намного более сложный, так как обязательно наличие селектора первичного включения (первой подачи питания на МК) и перезапуска после "длинной паузы" ("горячий старт") с обязательным наличием режима "повер даун".
Возможен также и гибрид первого и второго вариантов с автоматической подзарядкой акумулятора - но то уже "максимум навороченности".


Очепятался при наборе блок-схемы (набросок "на скору руку") - там питание ~220В и прочие "не те буковы" могут наблюдаться...

[Volodiatel]

Еще раз описать то, что должно быть? Легко.

Включаем выключатель, подающий питание на освещение и вентилятор, находящиеся в ванной. Загорается свет, запускается вентилятор. Через 1 час свет выключается, вентилятор включается каждые 22 мин на 1 мин. Если выключатель выключить и включить включится только освещение, отсчет времени начнется сначала. режим работы устройства переключится на следующий, то-есть на только освещение, а вентилятор выключится. Следующий режим - только вентилятор работает 22 мин и далее 1 мин каждые 22 мин. Если выключить и сразу включить выключатель, включится освещение и отсчет времени начнется сначала.

Полная схема? Она уже представлена. НИЧЕГО более не будет. Вместо светодиодов - реле. Вместо оптоэлектронной развязки - резистивный делитель и диодик, пропускающий одну полуволну. Питание устройство - балластный конденсатор, диодный мост, стабилитрон на 5В фильтрующий электролитический конденсатор. Вот, даже нарисовал:

1.JPG

(112.83 KiB) Скачиваний: 211

Теперь другое дело. Не буду спрашивать зачем именно такой алгоритм… раз такой нужен, пусть будет. Задам один вопрос – схему можно будет переделать или этот вариант окончательный и переделке не будет? ИМХО лучше отслеживать клацанье выключателя с делителя который подключен сразу после диодного моста…

1.png

Добавлено after 13 minutes 4 seconds:
Начал знакомится с тини15… какое-то не привычное чудо-юдо…

[Volodiatel]

То Самсусамыч:

Спасибо, ну хоть кто-то не предлагает сменить страну пребывания....

Мысль отслеживать сетевое напряжение с делителя обуславливается тем, что режимы работы устройства нужно переключать сетевым выключателем - щелк - горит свет и работает вентилятор, щелк - только свет, щелк - только вентилятор. И так по кругу. Поэтому снимать напряжение питания с контроллера нельзя, аккумулятор ставить не хочется, а конденсатор 1000мк должен несколько секунд продержать питание. Что-бы реле не брали лишний ток, можно установить диод по питанию и реле подключить перед ним . Тогда конденсатор будет запитывать МК не хуже аккумулятора. После диодного моста идет уже постоянное напряжение. Можно поставить резистор, тогда выделяются импульсы 100 Гц, которые и можно отследить. Но, мне кажется, это несущественным. Можно применить МОС с детектором 0 и симисторы вместо реле. сэкономим ток, а регулировать яркость освещения или скорость работы вентилятора не надо.