<time.h>
Как перенастроить, если это в принципе возможно, таймер 1-сек, к которому обращается ф-я clock_t clock(void).
Возможно ли задать тактирование таймера для clock() в IAR от вектора аппаратного прерывания внешнего таймера,
например PCF8563 ? ( В <time.h> определены макрос CLOCKS_PER_SEC )

Откуда возник вопрос.
Переход на зимнее-летнее время, будь он неладен. Аппаратные RTC это не поддерживают.
Даты-время-правило перехода определяются законодательно каждым государством.
Как достаточно просто реализовать часы RTC на базе UTC с поддержкой таймзоны и перехода зима-лето ?
( MSP430 )

Из часов берёте время, преобразуете его в секунды, выделяете текущее смещение относительно начала года, сравниваете с точками перехода, если находится в летнем интервале -
прибавляете величину смещения летнего времени.
Таким образом - при переходе зима<->лето часы в RTC не модифицируются (readonly).
У меня так в наших счётчиках сделано - так служба времени работает. Главная идея - время в RTC-часах - read only, не записывается
не при переходе зима<->лето, ни даже при корректировках (корректируется всегда дельта, которая потом прибавляется ко времени считанному из RTC).
Так можно безопасно и просто работать с RTC.

PS: Имхо - не в тот раздел написали - к IAR эта тема перпендикулярна.
PPS: В Незалэжной есть летнее время?

Да, я предполагаю запустить внешний RTC в режиме UTC. Он выдает аппаратно прерывание на процессор, где в обработчике можно и (или) вести счет секунд и преобразовывать из HHMMYYYY ... в секунды с 1970 или 1900 (прием из RTC по I2C). А "локальное" время получаем корректировкой на выдачу для экрана-отчета в зависимости от временной зоны и зима-лето-daylight.
А в IAR вопрос - тк. именно специфика IAR - прикрутить свой секундный обработчик для подсистемы времени, к которой обращается time();
(извиняюсь, перепутал с clock() ).

pps обовязково !!! мыж в эвропе, а по ихним стандартам без DST низзя никак. IMHO

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

Согласен. Я тоже делаю нечто подобное, есть внутренний таймер 2с. Можно перенастроить на 1с, а 2с получать программно.
-----
Вы использовали в IAR ф-ю getzone() ?
В версии для MSP430 она должна возвращать строку-правило коррекции зима-лето.
Вроде этой.
":GMT+10:GMT+11:0900:(1990)010100-0:040102-0:100102-0"
Но в ф-ии возврат дает только ":". Я так понял, ее нужно перекомпилировать для каждой таймзоны (или нескольких зон)
Эту ф-ю в дальнейшем использует localtime();
Не хотелось бы "изобретать лисапет". Может подскажете, есть ли поддержка зима-лето (daylight) коррекции в IAR ?
Может тема уже обсуждалась, но я не нашел.
Спасибо за ответ

Собственно это IAR не касается.
Зимне-летние "страдания" http://electronix.ru/forum/index.php?showt...amp;hl=Daylight

Нет. Всё сам.

Понятно. респект.

Вот нашел по IAR аналогичный моему вопрос - но без ответов
http://stackoverflow.com/questions/2352993...ench-for-msp430

Вот что пишется в док (EWRX_CompilerReference.ENU.pdf) на IAR
----------------
Time: (для MSP430)
To make the __time32, __time64, and date functions work,
you must implement the functions:
clock,
__time32,
__time64, and
__getzone.
Whether you use __time32 or __time64 depends on which interface you use for time_t, see time.h, page 304.
To implement these functions does not require that you rebuild the library. You can find
source templates in the files clock.c, time.c, time64.c, and getzone.c in the
430\src\lib directory. For information about overriding default library modules, see
Overriding library modules, page 90.
If you decide to rebuild the library, you can find source templates in the library project
template. For more information, see Building and using a customized library, page 91.
The default implementation of __getzone specifies UTC (Coordinated Universal
Time) as the time zone.
Note: If you link your application with support for I/O debugging, the functions clock
and time are replaced by C-SPY variants that return the host clock and time
respectively. For more information, see Application debug support, page 87.
------------------

Это замечательно, где бы найти пример реализаций и методику перекомпоновки библиотек ?

Чукча писатель?

Все есть и все работает. Как - будем тестировать.
Надо внимательно читать ф. ctime.c ctime64.c gmtime.c gmtime_i.c gmtime64.c localtim.c localtim_i.c localtim64.c
mktime.c mktime64.c setlocale.c xgetdst.c xisdst.c xisdst64.c xisdstData.c xthreads.c xtime.h.
------
Вопрос. В IAR неДоДокументирована работа с временем, касаемо daylight, timezone ?

Тема увлекательная, только библиотека IAR так писана, что вроде как строка TZ парсится только первый раз, а потом только через танцы с бубном. И это не переносимо. Так что лучше самому реализовать...