[Wise 0]

Всё верно. Только ток нагрузки там не должен быть 20мА, там от конденсатора отбираться должно не более 5мА (если не светить оба светодиода, или снизить токи через них), остальное съест стабилитрон. Так что и пульсации будут меньше.

 

Считаю вполне реальным снижение емкости балластного конденсатора.

 

..Да, конечно.

Расчет должен делаться на требуемый рабочий ток, с запасом на диапазон изменения сетевого напряжения, на допуск конденсатора..

 

И расхождение в цифрах небольшое, считать через средневыпрямленный ток, или через действующий.

Это я в силу природного занудства.. :)

[gretis 0]

На данный момент решено оставить это схемное решение. Спасибо большое всем за помощь. Персональное спасибо Andrey_B (помнится, еще в другой ветке помогал когда-то) и koyodza (разжевал все так, что осталось только проглотить).

 

Чуть разгребусь, сваяю софтовую часть и выложу на обсуждение...

[gretis 0]

Господа любезные! Туплю :(

В данном случае для реализации RTC мне получается надо прямо в main счетчики вешать? И по ходу программы делать поправки к этим счетчикам на время выполнения соответствующих команд?

[Andrey_B 0]

В данном случае для реализации RTC мне получается надо прямо в main счетчики вешать? И по ходу программы делать поправки к этим счетчикам на время выполнения соответствующих команд?

 

Лучше в прерывании по какому-нибуть таймеру тикать временем. А в основном теле неспеша все остальное.

[smac 0]

Господа любезные! Туплю :(

В данном случае для реализации RTC мне получается надо прямо в main счетчики вешать? И по ходу программы делать поправки к этим счетчикам на время выполнения соответствующих команд?

Лучше RTC все-таки с помощью таймера организовывать, я бы наверное даже внешний генератор на часовом кварце сделал, или можно др. контроллер взять, который позволяет часовой кварц прямо к ногам вешать, без доп. компонентов. Например мега48(88 или 168), у него таймер 2 может считать импульсы от кристалла.

[Andrey_B 0]

который позволяет часовой кварц прямо к ногам вешать,

 

Часовой кварц и так уже висит на ногах контроллера. Что касается другого мк, то тогда лучше поставить отдельный M41T56 например, или ds1337, и вообще голову не забивать, ни пересчетом даты, ни високосными годами, ни будильником.

[gretis 0]

Спасибо! В рамках конкретной задачи RTC необходимы в разрезе суток, поэтому забивания пересчетом дней, дат и годов не придется :)

[smac 0]

Часовой кварц и так уже висит на ногах контроллера ...

УПС, прошу прощения у Andrey_B и у aspID за свою невнимательность

Изменено 25 декабря, 2008 пользователем smac

[gretis 0]

Что ли здесь продолжить...

 

The interrupt execution response for all the enabled AVR interrupts is four clock cycles

minimum. After four clock cycles the program vector address for the actual interrupt

handling routine is executed. During this four clock cycle period, the Program Counter is

pushed onto the Stack. The vector is normally a jump to the interrupt routine, and this

jump takes three clock cycles. If an interrupt occurs during execution of a multi-cycle

instruction, this instruction is completed before the interrupt is served. If an interrupt

occurs when the MCU is in sleep mode, the interrupt execution response time is

increased by four clock cycles. This increase comes in addition to the start-up time from

the selected sleep mode.

A return from an interrupt handling routine takes four clock cycles. During these four

clock cycles, the Program Counter (two bytes) is popped back from the Stack, the Stack

Pointer is incremented by two, and the I-bit in SREG is set.

 

Означает ли это, что дабы точнее ходили мои ходики (RTC), надо учесть 4+4+4 = 12 "тиков" учитывая, что основное время устройство именно спит? Иными словами, нужно ли 224 увеличить на 12?

 

#pragma vector=RTC_OVFx_vect
__interrupt void RTC_one_second(void)
{
  if ( uc_RTC_SS == 59 )
  {
    if ( uc_RTC_MM == 59 )
    {
      if ( uc_RTC_HH == 23 )
      {
        uc_RTC_HH = 0;
      }
      else
      {
        uc_RTC_HH ++;
      }
      uc_RTC_MM = 0;
    }
    else
    {
      uc_RTC_MM ++;
    }
    uc_RTC_SS = 0;
  }
  else
  {
    uc_RTC_SS ++;
  }
};

void RTC_Init ( void )
{
  RTC_TCCR0B |= ( 5 << CS02 ); // Clk I/O / 1024 prescaling
  RTC_TCNT0 = 224;             // 224 = -32, 1 OVF = 1 second
  TIMSK |= ( 1 << TOIE0 );     // Enable timer OVF Interrupt
};

 

Пардон, понял что сказал глупость. На 12 поделенное на 1024 :) Сначала думал, этой погрешностью можно пренебречь. Но получается, каждую секунду будет "лишних" отсчитано 12 циклов, или 1/32768 * 12 = 37мкс. В минуту это почти 22мс, в час 1.3с а в сутки уже почти 32с. Ээээ, брат, эт жулики! Подскажите, на каком этапе правильнее учесть данную погрешность?

[xemul 0]

Вы правда хотите собственнолично собрать все шишки и понаступать на все грабли?

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

Я пару страниц назад позволил себе заметить:

На 32 кГц тактовой как-то разумно импульсить в гейт, имхо, будет сложно.

Попробуйте сначала этот кусочек прикинуть.

Когда не получится, Вы плавно придете к мысли, что неплохо бы поменять контроллер, так чтобы:

Часовой кварц имеет смысл использовать только под RTC, а работать на внутреннем RC.

А если не будете мешать контроллеру, то точность и стабильность RTC будут определяться точностью и стабильностью генератора с кварцем.

 

Ну и совсем на всякий случай (Вас, по-моему, забыли предупредить): в последнем варианте схемы элементы R4, D1, D2, C1 должны выдерживать импульсный ток не менее 3 А.

 

Да, забыл: для отладки возьмите транс с 10-30 В на вторичке, к нему однополупериодный выпрямитель. Придется уменьшить пропорционально R3 и заменить С2 на резистор (или просто повесить резистор параллельно C2). Когда/если все вылижете по потреблению, рассчитайте требуемое значение C2 (расчет, применявшийся выше, завышает C2 на четверть).

[rezident 0]

точность и стабильность RTC будут определяться точностью и стабильностью генератора с кварцем.

А также температурой окружающей среды и стабильностью величины напряжения питания. Т.е. если топикстартер получит точность хода его импровизированных часов лучше, чем ±3-5 сек/сутки, то можно считать, что ему очень сильно повезло.

[gretis 0]

стабильностью величины напряжения питания.

Этого не понЯл

 

если топикстартер получит точность хода его импровизированных часов лучше, чем ±3-5 сек/сутки

Данная точность вполне устроит. Это не полминуты

[xemul 0]

А также температурой окружающей среды и стабильностью величины напряжения питания.

Можно, конечно, углубиться в дебри и построить модель погрешности генератора АВР от ..., но основная мысль была: для RTC требуется чуть-чуть времени в прерывании и невмешательство в дела генераторно-таймерные.

Т.е. если топикстартер получит точность хода его импровизированных часов лучше, чем ±3-5 сек/сутки, то можно считать, что ему очень сильно повезло.

Без на/под-стройки вряд ли - ширпотребовские часовые кварцы от 100 ppm. Хотя и с 10-20 ppm сейчас вполне доступны.

 

2aspID Делитель zero-cross в последней схеме слишком хорошо делит - АВР будет чувствовать переключение при 60-70 В в линии. Оно, конечно, может быть учтено программно, если скорострельности хватит.