Arduino.ru

void ticker(){
    unsigned long _millis=millis();
    if ((msStart==0) and (msCurrent==0)){
      msStart=(HH*3600+MM*60+Secs)*1000;
      if (msStart>_millis) msStart=msStart-_millis;
      msCurrent=msStart+_millis;
    }
    if ((msStart==0) and (msCurrent>0)) {
      msCurrent=(HH*3600+MM*60+Secs)*1000;
      while (1){
        if (msCurrent>_millis){
          msStart=msCurrent-_millis;
          break;
        } else msCurrent+=86400000;
      }
    }
    msCurrent=(msStart+_millis) % 86400000 ;
    current_sec=msCurrent/1000;
  if (_millis>current_ms+999){
    current_ms=_millis;
  }
}

Выкинь, нафик. Купи http://www.ebay.com/itm/310727159819?

Ходят очень точно. Запусти в апреле. Ушли от интернетовских "атомных" на 2 секунды.

И в них миллисекунды есть?

А вообще, не догнать. Что-то купив, тебе зразу советуют купить что то еще и покруче. Нужно работать с тем, что уже есть. И я не думаю, что то, что у меня очень плохое устройство.

Прости, если обидел. Не знаю, есть ли там миллисекунды...но точно знаю, что если секунды умножить на 1000, то получатся миллисекунды.....точно знаю, что там есть память, точно знаю что там есть температурный датчик, который температуру окружающей среды показывает и корректирует ход кварца, точно знаю, что идут очень точно. Когда купил и пощупал первые часики, сразу заказал еще двое, цена смешная -65 рублей. Зачем заказал..пока не знаю...пусть будут.

Что-ты! Ты никого не обидел! )))

Просто вопрос был о миллисекундах, а не в помощи выбора RTC-модуля.

И ты прав, что секунду умножить на 1000 получу миллисекунду. Но после этого умножения я все равно получу дискретность в секунду. А мне нужна дискретность в миллисекундах, ну или в десятках миллисекунд. От сюда и вопрос. 

Там кварц стоит, и с него вроде бы возможно получить импульсы с ноги (не кварца, а платы), если сильно не ошибаюсь, от 1 до 32768 гц. Тут даже покруче миллисекунд получается. А на 1307 такой ноги нет.

тысячу секунд ты получишь - совсем уже из реальности выпали оба(два), путаете умножение и деление

Описка. Имелось в виду цифра в миллисекундах. Т.Е. 1 секунда Х 1000 = 1000 миллисекунд.

Но мы поняли друг друга :).

Нога есть, но можно только четыре значения: 1, 4096, 8192, 32768.

Друзья, я вижу решение данного вопроса не в аппаратной, а в программной части. И прошу помощи у Гуру!

Шатными средствами я из DS1307 могу получить колличество секунд с начала суток. Значение будет крупным, но тем не менее. А у Ардуино есть функция millis(), которая возвращает время в миллисекундах с начала запуска Ардуино. Имея все это, сейчас и думаю над кодом функции, которая возвращала бы миллисекунды с начала дня. И надеялся на Вашу помощь. 

> А на 1307 такой ноги нет.

На DS1307 такая нога есть и работает она точно так же. Но у DS3231 её работа настраивается по другим адресам.

Милисекунд в часах нет. Даташит на 11 странице

Извините, что встрял (на звание гуру не претендую)

Мне не понятна задача. Нафига нужно время в миллисекундах с начала дня, если еще и привинтить часы реального времени. Нафига такая точность такого большого промежутка времени?

Спасибо. Не знал.

Тогда совсем посто - считай сигналы с ноги с начала дня :)

Вы опять не в ту степь полезли.

Народ вашей проблемы не знает и поэтому советует не то.

Вам нужен примерно такой алгоритм.

1. Почасам реального времени вычисляете когда вам нужноначать рассвет/закат. 

2. В этот момент ФИКСИРУЕТЕ с какую-нибуть переменную millis()

3. И уже от этого значения миллисекун пляшите как хотите.

А вы пытаетесь ежа с ужом скрестить.

Вам Иван Сусанин не родственник? Кто мешает взять за отсчет значение часов для события, затем ваш интервал, привести к миллисекунды и поделить на количество градаций. Получаем количество миллисекунд на градацию.

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

RTC-модуль уже прикручен. Нужно какая-то лонгинт в миллисекундах с начала дня.

Такая точность нужна, я тут про нее писал уже тут. Она нужна для рассвета и заказа светодиодного светильника при использовании 12-битного шима. Контроллер Ардуино Нано + TLC5940. При этом у TLC5940 не корректно работает функция fade при больших периодах действия. Поэтому пришлось отказаться от fade  и вернуться к самостоятельному вычислению уровней ШИМ. Но для этого нужны миллисекунды, т.к дискретность в секунду выдает "скачек" освещенности, что не есть хорошо.

2. В этот момент ФИКСИРУЕТЕ с какую-нибуть переменную millis()

3. И уже от этого значения миллисекун пляшите как хотите.

Как вариант...

Зачем рассвет-закат с точностью до 1/1000 секунды?!

Вас этим ТС всех и путает.

Не нужна ему для этого такая точность, такая точность ему нужна для управления ШИМом.

Я уже все описал для реализации его алгоритма.

Мне ШИМ нужен с точность до миллисекунды

Все равно ни чего не понял........часы....шим

Вот откуда ноги растут

http://arduino.ru/forum/apparatnye-voprosy/kontroller-svetodiodnogo-svetilnika-dlya-morskogo-akvariuma-tlc5940-arduino

А зачем светодиодам 12-ти битный шим? Зачем все так сложно?

Он по ссылке в 27 посте описал

ты можешь получать количество миллисекунд с момента начала любого события - примерно так:

void loop() {
static const unsigned long время_начала_события = 0;
static const unsigned long время_запроса_продолжительности_события = 0;
static const unsigned long время_продолжительности_события = 0;

if (булевый признак начала события) {время_начала_события = millis();}
if (булевый признак запроса продолжительности события) {
время_запроса_продолжительности_события = millis();
время_продолжительности_события = время_начала_события - время_запроса_продолжительности_события;
}
}

переменные переведи в латиницу.

Понял

"Что касается 12бит, то тут я не завод, поэтому приходится делать с запасом. Например, если я в два раза перестараюсь с мощностью диодов, то мне придется сделать общую мощность в 50%, а это при 8 битах уже 125. А 125 уже существенно заметные рывки освещенности. При 12битах эта проблема исчезает как таковая, при том, что стоимость на сегодняшний день этому всего 70 рублей."

но с автором не согласен. Мне кажется, что для рассвета-заката хватит вполне 8 бит. Просто нужно правильно применить.

А у моих рыб рассвет-закат занимает долю секунды. Ничего....живы пока :)

Это для красоты, а не для рыб/кораллов.

:)

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

А вот это

"Например, если я в два раза перестараюсь с мощностью диодов, то мне придется сделать общую мощность в 50%, а это при 8 битах уже 125. "

Это не исправимо?

и, нахрена миллисекунды в аквариуме.

*это риторический вопрос - можно не отвечать.

Еще раз: Рассвет 10 минут = 600000мС, 600000/4096 = 146,5мС на градацию. Каждые 146 или 147мС увеличиваем значение ШИМ на 1 пока не достигли максимума и наоборот.

Потому что например 10 минут это 600 секунд, а ШИМ 4095. Вот для этого и нужно им управлять более, чем раз в секунду.

Ну лови тики с RTC прерыванием и дергай в нем ШИМ. В либе для DS1307 (RTClib) всё есть для установки частоты тиков.

600 секунд это 600000 миллисекунд - я не понимаю, в чём проблема запустить что-то по событию RTC, затем юзать функцию millis() ?

А зачем пользоваться событиями RTC?

Лично я в этом смысла не вижу.

Это из разряда кому как нравиться.

ок - так, в чём проблема с секундами, если RTC не приделах?

Ни в чем. :)

Это ТС нужно. Пусть он и думает.

Спасибо за участие! )))

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

В спорах рождается истина. )))

Что касается аппаратной части, то кому то это кажется легче, но не для меня )

Спасибо всем за участие.

Это - неправильное видение с точки зрения данной архитектуры. Дело еще и в том, что счетчик millis() обнуляется при своем переполнении совсем не на границе суток, а где получится. Соответственно, может получиться в середине Вашего "интервала от начала суток".

Более правильный вариант Вам bwm уже озвучил: событие наступило по RTC, и от него формируем ШИМ с нужной скоростью/скважностью. И проверяем millis() на переход через ноль.

По идее и это лишнее. При самом плохом раскладе, одна градация раз в 50 суток затянется не на 140мС а на 280.

Мое видение было в том, чтоб брать из millis() только миллисекунды. Обнуляется он один раз в 50 дней. Но можно же и просто ночью делать резет Ардуино и этой проблемы не будет.

И, спасибо, я согласился с принципом работы от RTC, а уже потом с миллисекундами.

Всем добрый день.

Ну вот дошли наконец то руки до программы. И нифига не просто все это получается.

Внешний цикл до событий у меня идет в секуднах. При наступлении события все остальные вычисления начинаются в миллисекундах. И если программа отрабатывает это событие с самого начала и до конца - все работает классно. Но так как события длятся от десяти минут до часа, я начала проверять "вход в программу" в середине цикла события. И вот тут прихренел )))

Для вычисления точки начала события в миллисекундах у меня получается отрицательное значение и полная жопа. )))

Думаю дальше.

Переполнений нигде нет?

Не надо думать

http://arduino.ru/forum/programmirovanie/taimer-i-shim?page=1#comment-139269

Там все уже работает. Спишитесь с ним. Кинет он скетч.

Вы опять в смоленские болота забираетесь. У вас есть событие, которое наступило согласно RTC. Подняли флаг и забыли про свои часы. Далее есть функции приращения-уменьшения ШИМ, в них и манипулируете своим ШИМом и интервалами из миллисекунд. Когда достигли требуемого значения флаг сбросили и ждете следующего события по RTC.
 

Вы все правильно пишите. Все верно.

Это описание само собой прописалось, а вот:

Но если, после сброса или сбоя, я вхожу в программу. А событие уже наступило десять минут назад. А при таком входе как флаг поднимать, раз оно уже прошло? Как расчитать значения ШИМ? При входе в программу millis() равно нолю, а флаг надбыло поднимать " - 600000 миллисекунд назад".

В общем нужно просто подумать и решить задачку. Не так сразу просто придумалось )

куда ты входишь после сбоя - ты умер, твоё место на кладбище, лежи и не рыпайся.

следующая копия тебя не будет скорбеть, что ты не успел трахнуть соседку потому, что умер.

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

Тогда наверно лучше цикл начать сначала. Или произвести обратный расчет от начала события. Хотя сбой питания и его последующее включение в течении минут, скорее исключение, чем правило.
Как вариант, если интервал события еще не закончен - начинаем сначала, если уже закончился - на максимум. Для заката лучше ничего и не делать, выключилось, значит выключилось.

я в принципе не понимаю сути проблемы:

если требуется что-то сделать после 08:45, но не позже 19:00, то каким боком тут грёбаные минуты?

Проблема высосана из пальца :)