Нужен оптимальный алгоритм RTC

Вопросы настройки, программирования, прошивки микроконтроллеров и микросхем программируемой логики
Закрыто
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Нужен оптимальный алгоритм RTC

Сообщение ploop »

Доброго времени суток.
Делаю устройство, в котором помимо всего должен быть учет времени с календарём. Алгоритм не сложен, выдернул его из своего старого проекта часов, но есть одна проблема: должен он выполняться в прерывании (1 сек по таймеру), при этом должен выполняться как можно быстрее, т.к. блокирует другие прерывания, которые очень не желательно прозевать.

Этот велосипед изобрёл сам, поэтому может кто подскажет более эффективный алгоритм? Собственно код:
Буферы памяти:

Код: Выделить всё

  ; Буферы часов
  clk_hh:      .byte 1            ; Часы            
  clk_mm:      .byte 1            ; Минуты
  clk_ss:      .byte 1            ; Секунды
  clk_yyyy:    .byte 2            ; Год
  clk_mnt:     .byte 1            ; Месяц
  clk_dd:      .byte 1            ; День
  clk_dw:      .byte 1            ; День недели

Массив количества дней в месяце

Код: Выделить всё

;-------------------------------------------------------------------------------
;  Число дней в месяце
;-------------------------------------------------------------------------------
cnt_day: .db 0,31,28,31,30,31,30,31,31,30,31,30,31
Основной алгоритм

Код: Выделить всё

run_clock:

  lds r16,clk_ss                  ; Крутим секунды
  inc r16
  cpi r16,60
  brcc rc_min
  sts clk_ss,r16
  ret

  rc_min:                         ; Крутим минуты
  clr r16
  sts clk_ss,r16
  lds r16,clk_mm
  inc r16
  cpi r16,60
  brcc rc_hh
  sts clk_mm,r16
  ret

  rc_hh:                          ; Крутим часы
  clr r16
  sts clk_mm,r16
  lds r16,clk_hh
  inc r16
  cpi r16,24
  brcc rc_dd
  sts clk_hh,r16
  ret

  rc_dd:                          ; Крутим день и день недели
  clr r16
  sts clk_hh,r16
  lds r16,clk_dw
  inc r16                         ; День недели
  cpi r16,8
  brcs rc_dd2
    ldi r16,1
  rc_dd2:
  sts clk_dw,r16

  lds r16,clk_dd
  lds r17,clk_mnt                 ; День с учетом количества дней в месяце
  ldi2Z cnt_day
  add16Z r17
  lpm r19,Z
  lds r18,clk_yyyy                ; Проверим на високосный год
  andi r18,0b00000011             ; У него будет два младших бита в нулях
  brne rc_dd3
    cpi r17,2                     ; Если февраль
    brne rc_dd3                  
    inc r19                       ; Увеличиваем кол-во дней
  rc_dd3:
  inc r16
  cp r19,r16
  brcs rc_mnt
  sts clk_dd,r16
  ret
  
  rc_mnt:                         ; Крутим месяц
  ldi r16,1                       ; Он у нас уже есть в r17
  sts clk_dd,r16
  inc r17
  cpi r17,13
  brcc rc_yy
  sts clk_mnt,r17
  ret
  
  rc_yy:                          ; Крутим год
  ldi r17,1
  sts clk_mnt,r17  
  lds r24,clk_yyyy
  lds r25,clk_yyyy+1
  adiw r24,1
  sts clk_yyyy,r24
  sts clk_yyyy+1,r25

 ret
Реклама
Мастер Ломастер
Поставщик валерьянки для Кота
Сообщения: 1995
Зарегистрирован: Ср май 11, 2011 21:37:45
Откуда: Цветочный город
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение Мастер Ломастер »

во-первых, я верно понял, что вы привели "исходный" алгоритм, ибо всюду у вас ret-ы, а не reti ?
во-вторых, если вам нельзя прозевать другие прерывания, просто разрешите прерывания в самом начале "часового" обработчика, да и все - получится очень хорошо, ничего блокироваться не будет и голову ломать над "оптимизайией" не потребуется
битва с дураками проиграна, победители торжествуют. слава победителям!
Реклама
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

во-первых, я верно понял, что вы привели "исходный" алгоритм, ибо всюду у вас ret-ы, а не reti ?
Пока просто вызывал его из обработчика прерывания как rcall. Переделать, в принципе, не сложно.
во-вторых, если вам нельзя прозевать другие прерывания, просто разрешите прерывания в самом начале "часового" обработчика, да и все - получится очень хорошо, ничего блокироваться не будет и голову ломать над "оптимизайией"
Думал об этом. Но, ИМХО, вложенные прерывания - крайний случай.

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

В принципе и в таком виде всё работает, но когда начал тестировать в экстремальных условиях - данные отовсюду (UART тоже на прерываниях) и очень частые внешние прерывания (именно те, которые нельзя прозевать) - иногда случаются косяки.
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

Хм... может оптимизировать главный цикл... Там вызывается подпрограмма опроса кучи датчиков за раз - она больше всего времени отнимает. Если опрашивать по одному в каждом проходе - явно быстрее получится.

Но алгоритм часов всё равно интересен, поделитесь, если у кого есть :)
Реклама
Эиком - электронные компоненты и радиодетали
Мастер Ломастер
Поставщик валерьянки для Кота
Сообщения: 1995
Зарегистрирован: Ср май 11, 2011 21:37:45
Откуда: Цветочный город
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение Мастер Ломастер »

ploop писал(а):Думал об этом. Но, ИМХО, вложенные прерывания - крайний случай.
это у вас религиозное? почему такое подозрительное отношение к вложенным прерываниям?
битва с дураками проиграна, победители торжествуют. слава победителям!
Реклама
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

Нет, просто боюсь на неприятности нарваться. Хотя всё решаемо, если продумать.
Реклама
Мастер Ломастер
Поставщик валерьянки для Кота
Сообщения: 1995
Зарегистрирован: Ср май 11, 2011 21:37:45
Откуда: Цветочный город
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение Мастер Ломастер »

да, если подумать, то прерывание часов происходит раз в секнду, а алгоритм обрабатывается явно не секунду - даже если он ОООООЧЕНЬ неоптимальный - так ведь? значит, повторный вход в этот самый обработчик НЕВОЗМОЖЕН в принципе, т.е. переполнение стека нереально.
ну а другие СРОЧНЫЕ обработчики пусть работают, как им надо.
битва с дураками проиграна, победители торжествуют. слава победителям!
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

Да, вы правы. Если вложение будет одно - не страшно. Кроме других прерываний туда ничего не залезет, а они очень шустрые (максимум 10мс). Наверное так и сделаю.
clawham
Поставщик валерьянки для Кота
Сообщения: 1957
Зарегистрирован: Пт окт 31, 2008 09:38:55
Откуда: Одесса
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение clawham »

а вы случаем не делаете термологгер на дс18б20 средствами библиотеки встроенной в cvavr ? очень на то похоже....
странно...не представляю что может занимать секунду сплошных вычислений?

у меня вот в ваттметре например на частоте 8 килогерц прерывания одного и ещё остальных таймерных и т.д. - основной цикл пролетает 3-4 раза в миллисекунду!!!

а там очень много вычислений с плавающей запятой, вывод на экран 44780 и распихивание данных по массивам....

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

я вот дорабатываю проект теплосчетчика многоканального....на данный момент организовано сколько хватит памяти теплосчетчиков (56 байт за один теплосчетчик) и сколько угодно водомеров(сколько хватит внешних прерываний) мега 8 уже на пределе - перехожу на 103-ю....

на текущий момент тестируемый прототип - 8 тепловых точек и два расходомера-водомера....
показания температур снимаются каждую секунду со всех термодатчиков одновременно...паралельно с частотой 10-20 герц клацают прерывания водомеров , часов реального времени, внутренних таймеров...всё на самопальной операционке и естественно вывод на компьютер....кнопочки...менюшечки....

основной цикл проходится по 80-100 раз в миллисекунду!!! с учетом вывода на экрна и на уарт....всё по прерываниям всё буферизировано....

думаю стоит ли писать статью на данном этапе?
Что нас не убило сделало нас осторожней
Не доверяйте русским лужам - это может быть вход в метро.
Аватара пользователя
GP1
Поставщик валерьянки для Кота
Сообщения: 2401
Зарегистрирован: Пт май 23, 2008 19:32:22
Откуда: Россия, Волгоград
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение GP1 »

Мяу, всем отметившимся в теме
Мои 5коп:
я бы в прерывании считал секунды, а все остальное в основном цикле, при переходе 59-00 сек ставим флаг, на обработку которого у нас будет целая минута (!!!) уж точно ничего не пропустишь.
ИМХО.
Чем дальше, тем больше становлюсь занудой...
Изображение
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

а вы случаем не делаете термологгер на дс18б20 средствами библиотеки встроенной в cvavr
Похоже на то, у меня 6 датчиков 18b20, только пишу всё с нуля без каких-либо библиотек. Мега48. Её ресурсов по памяти и ногам хватает с запасом, а вот по скорости - надо просто обмозговать всё, похоже изначально неправильный подход выбрал. Она на 20МГц тактовой черта лысого обсчитает.
Благо саму структуру алгоритма изменить не сложно, всё сделал отдельными короткими подпрограммами.
думаю стоит ли писать статью на данном этапе?
Однозначно! :)
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

GP1, интересный мысль! :))
Мастер Ломастер
Поставщик валерьянки для Кота
Сообщения: 1995
Зарегистрирован: Ср май 11, 2011 21:37:45
Откуда: Цветочный город
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение Мастер Ломастер »

ploop писал(а):GP1, интересный мысль! :))
не соглашусь. имхо, считать время в прерывании полностью - более логично, нежели разбивать на обработку в двух местах, логически не связанных. ваши опасения надуманы. тот код, что вы привели в самом начале, имхо, проскочит за 200 тактов: при тактовой частоте 1 МГц (!!!) это будет всего-навсего 200-300 МИКРОсекунд!!!! чего вы опасаетесь?! вы пишите на ассемблере и при этом у вас такая странная боязнь...

ранее вы писали про "очень быстрые прерывания - максимум 10 мс". так вот, эти слова меня лично повергают в ужас: 10 МИЛЛИсекунд - это КАТАСТРОФИЧЕСКИ МНОГО для прерывания!!! при упомянутой мною тактовой (кто-нибудь работает на такой низкой частоте?!) это будет порядка 8-10 ТЫСЯЧ КОМАНД! откуда у вас такие "быстрые" алгоритмы?! может, вы просто подсчитываете свои длительности неверно?
битва с дураками проиграна, победители торжествуют. слава победителям!
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

Упс, микросекунд конечно :)
Опечатка.

Там всего по несколько команд. Большинство - установка флагов (флаговый автомат)Тогда самое длительное будет именно это (учёт времени).
clawham
Поставщик валерьянки для Кота
Сообщения: 1957
Зарегистрирован: Пт окт 31, 2008 09:38:55
Откуда: Одесса
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение clawham »

реально не вижу причины вообще в прерывании РТЦ выносить !
считайте там только секунды а их разбивку уже в одсновном цикле

по поводу датчиков....ну так у датчика есть две фазы...первая - начало преобразования - это 3 комманды на 1wire выдать подряд без задержек а потом только через секунду - уже считать готовые показания...столь же быстро....разбивайте...это очень помогает....

хотя Вам наверное это будет сложно..вы на асме пишите...я вот например миллисекундный счет веду в лонгинте - 64 бита....а дальше уже разбиваю на секунды-минуты-часы-дни....так проще....а в основном цикле ставите метки - время следующего запуска - не дошли - пропускаем....пришли или переждали - запускаем
Что нас не убило сделало нас осторожней
Не доверяйте русским лужам - это может быть вход в метро.
Мастер Ломастер
Поставщик валерьянки для Кота
Сообщения: 1995
Зарегистрирован: Ср май 11, 2011 21:37:45
Откуда: Цветочный город
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение Мастер Ломастер »

ага, разобались. ну, а раз счет времени - самый длительный процесс из прерываний, то можно прикинуть его длительность. по моим оценкам она составит, как я уже говорил, не больше 2-3 сотен микросекунд. это вполне нормально, не должно создать никаких проблем, задумываться о какой-то сверхоптимизации смысла не вижу.
битва с дураками проиграна, победители торжествуют. слава победителям!
Мастер Ломастер
Поставщик валерьянки для Кота
Сообщения: 1995
Зарегистрирован: Ср май 11, 2011 21:37:45
Откуда: Цветочный город
Контактная информация:

Re: Нужен оптимальный алгоритм RTC

Сообщение Мастер Ломастер »

clawham писал(а):я вот например миллисекундный счет веду в лонгинте - 64 бита....
64 бита - это лонг-лонг-инт... а каким компилятром пользуетесь? WinAVR с 64-битными числами очень криво работает - порождает весьма неоптимальный код. мне кажется, обычный инкремент лонг-лонга получится хуже, чем полный счет времени сразу с разбивкой по секундам и т.п.
битва с дураками проиграна, победители торжествуют. слава победителям!
Аватара пользователя
МитяРа
Модератор
Сообщения: 11492
Зарегистрирован: Чт дек 11, 2008 14:52:26
Откуда: град Нижний

Re: Нужен оптимальный алгоритм RTC

Сообщение МитяРа »

ploop писал(а):у меня 6 датчиков 18b20, только пишу всё с нуля без каких-либо библиотек.
Пушистый, если пишешь с нуля, не проще-ли обрабатывать все 6-ть датчиков одновременно по 6-ти линиям порта..
Кучу времени съэкономишь.. :roll:
[img]http://radiokot.ru/forum/download/file.php?id=93376[/img][i][color=#000080][size=85]Между людьми возникает напряжение, если у них разный потенциал...[/size][/color][/i]
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

по поводу датчиков....ну так у датчика есть две фазы...первая - начало преобразования - это 3 комманды на 1wire выдать подряд без задержек а потом только через секунду - уже считать готовые показания...столь же быстро....разбивайте...это очень помогает....
Тоже по секундному флагу в главнои цикле, сначала чтение + отсылка команды на преобразование. После ресета первое показание считывается неверно, остальные уже нормально. Устройство должно работать без выключений, так что тут всё правильно.
хотя Вам наверное это будет сложно..вы на асме пишите...я вот например миллисекундный счет веду в лонгинте - 64 бита....а дальше уже разбиваю на секунды-минуты-часы-дни....так проще....
Сложнее не асм, а сам алгоритм. Я думал над этим, организовать что-то типа unix-time, т.е. большой секундный буфер, а реальное время вычислять из него. Но как-то наворочено мне показалось. В моей реализации всё просто разделено на поля, бери готовое время и пользуйся.
по моим оценкам она составит, как я уже говорил, не больше 2-3 сотен микросекунд.
И то - раз в год, когда прогоняется весь код. Видите там ret'ы по частям? При счете секунд он затратит тактов 10 (на глаз), минут - еще 10-15 и т.д.
Да нормально получается, для пущей подстраховки разрешу внутри неё вложенные прерывания.
задумываться о какой-то сверхоптимизации смысла не вижу.
Можно немного оптимизировать на количестве используемых РОН, это избавит от лишних сохранений в стек при входе в прерывание.
Аватара пользователя
ploop
Модератор
Сообщения: 13490
Зарегистрирован: Ср ноя 26, 2008 16:34:25
Откуда: Тамбовская обл.

Re: Нужен оптимальный алгоритм RTC

Сообщение ploop »

МитяРа писал(а):
ploop писал(а):у меня 6 датчиков 18b20, только пишу всё с нуля без каких-либо библиотек.
Пушистый, если пишешь с нуля, не проще-ли обрабатывать все 6-ть датчиков одновременно по 6-ти линиям порта..
Кучу времени съэкономишь.. :roll:
Это как? 6 1-wire линий? Во-первых ног не хватит, во-вторых надобности нет. Они и так отлично работают, а время на опрос не критично, пусть хоть минуту опрашиваются. Опрос в главном цикле, в за секунду успевает проскочить легко.
Закрыто

Вернуться в «Микроконтроллеры и ПЛИС»