Разработка, производство и продажа радиоэлектронной аппаратуры
|
Карта сайта
|
Пишите нам
|
В избранное
Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:
jobsmp@pochta.ru
Телесистемы
|
Электроника
|
Конференция «Микроконтроллеры и их применение»
Во, нормально. 4 - х байт на 136 лет хватит :-)
Отправлено
Samsony
11 апреля 2007 г. 15:49
В ответ на:
Пиши время в сек. относительно базиса, часто используют 00:00:00 01.01.1970 и алгоритмы перевода в сети есть, но можно и другой базис юзать.
отправлено Щ.C. 11 апреля 2007 г. 15:41
Составить ответ
|
Вернуться на конференцию
Ответы
Правильный подход. Это "unix time" - стандарт. И преобразование есть в либе С-компилера. mktime, gmtime и localtime
—
SM
(11.04.2007 16:08:55
85.21.249.17
,
пустое
)
Кстати микрософт еще дальше пошел. Cчитают 100-наносекундные интервалы с 1 января 1601 года :) Интересно, что это за такая знаменательная дата?
—
SM
(11.04.2007 16:20:26
85.21.249.17
,
пустое
)
Это геморрой. Никаких преобразований не надо, если просто все свести в битовую структуру и хранить АБСОЛЮТНОЕ время, а не чухаться с високосными годами, астрономическими/технологическими секундами и т.д. -->
—
=AVR=
(11.04.2007 16:20:15
80.92.96.19
,
пустое
,
ссылка
)
Спасибо, так и сделаю. Самое красивое решенние....
—
Samsony
(11.04.2007 16:22:33
85.93.35.221
,
пустое
)
Я это видел, и это называется неэффективное использование памяти. Когда все функции уже даны и даже прописаны в ANSI - пользуйся сколько влезет. И чухаться с годами и секундами будет ANSI C Library а не программист.
—
SM
(11.04.2007 16:22:33
85.21.249.17
,
пустое
)
Во-первых, чухаться будет не ANSI C Library, а какая-нибудь несчастная восьминогая Тинька. А в-НУЛЕВЫХ, эффективность использования памяти АБСОЛЮТНО ОДИНАКОВАЯ - 32-битная структура, работающая до 2063 года, и UNIX Time, работающий до 2098 года в масштабах конкретного цикла жизни логгера равноценны вечным, но существенно разноГЕМОРРОЙНЫ. И обе они одинаково причастны и к Millenium Bug, и к GPS Week Number Rollover, и если этого потребуется избежать - к обеим придется добавлять по байту
—
=AVR=
(11.04.2007 16:35:43
80.92.96.19
,
пустое
)
Нука поподробнее, каким образом unix time причасно к обоим проблемам? week number там отнюдь не по модулю 1024, его там просто нет. Проблемы 2000-го года там не было изначально по определению. А эффективность использования памяти ВЫШЕ. За счет того, что вместо 32 бит можно использовать 31 бит, чтобы до того же 63-го года хватило.
—
SM
(11.04.2007 16:49:57
85.21.249.17
,
пустое
)
Это образно - не обе они, а такой же подход - ЧРЕЗМЕРНАЯ ограниченность битового пространства, как в них обеих - сэкономили копеечный байт, получили многомиллиардный геморрой. А 31 бит супротив 32 - это да, крутая экономия - неважно, что UNIX Time Library сожрет в сто раз больше наэкономленного :) :) :))
—
=AVR=
(11.04.2007 16:55:57
80.92.96.19
,
пустое
)
Сожрет, но не в EEPROM :)
—
SM
(11.04.2007 16:57:39
85.21.249.17
,
пустое
)
Не надоело?
—
=AVR=
(11.04.2007 17:00:17
80.92.96.19
,
пустое
)
А мне тут как раз делать нефига :) Пока жду результаты моделирования.
—
SM
(11.04.2007 17:01:13
85.21.249.17
,
пустое
)
Ну тогда смоделируй (скомпилируй) и сравни работу структуры с работой UNIX Time для какого-нибудь 8-битника. Результаты - в студию :))
—
=AVR=
(11.04.2007 17:04:24
80.92.96.19
,
пустое
)
Зачем? Что-то я не видел, чтобы кто-то говорил, что эти операции нужно делать в жестком реалтайме с немеренной частотой :)
—
SM
(11.04.2007 17:16:22
85.21.249.17
,
пустое
)
:) Функция "DateTime_toLong" : PIC18 (HW Mult), ASM: 20us @40Mhz. Распаковка уже на компе.
—
ы
(11.04.2007 17:15:20
80.92.98.211
,
пустое
)
То есть 400 байт одна упаковка. Круто, ради экономии 3% EEPROM :))
—
=AVR=
(11.04.2007 17:20:35
80.92.96.19
,
пустое
)
а дошло, не...с таблицами поболее (некоторые аримф действия (деление) с известными диапазонами аргументов сведены в табличку)
—
ы
(11.04.2007 17:38:58
80.92.98.211
,
пустое
)
а что такое 400 байт ? а вообще я не по теме (автор видимо сам не знает что ему надо), а про формат представления времени
—
ы
(11.04.2007 17:33:10
80.92.98.211
, 797 байт)
Это оценка длины инлайн-кода - 2 байта на команду * (20 мкс/0.1мкс) = 400 байт
—
=AVR=
(11.04.2007 17:37:39
80.92.96.19
,
пустое
)
И еще плюс ко всему - если у него суперумный внешний RTC, это одно. А если увеличение счетчика секунд в прерывании - это второе. И если есть это второе, то gmtime самое то, чтобы не думать.
—
SM
(11.04.2007 16:52:57
85.21.249.17
,
пустое
)
Бланманже -->
—
=AVR=
(11.04.2007 16:56:52
80.92.96.19
,
пустое
,
ссылка
)
Блин, что они есть, это и так ясно. Вопрос в каком виде они есть :)
—
SM
(11.04.2007 16:58:36
85.21.249.17
,
пустое
)
В виде, озвученном в корневом посте - YY/MM/DD/hh/mm/ss, как у подавляющего большинства RTC
—
=AVR=
(11.04.2007 17:01:51
80.92.96.19
,
пустое
)
У автора поста, видимо, в таком виде и есть. Насчет "подавляющего" - сомневаюсь. Счетчик секунд (и их долей) тож часто используется.
—
Щ.C.
(11.04.2007 17:12:26
144.206.186.102
,
пустое
)
Которые тоже занимают память и время....
—
Samsony
(11.04.2007 16:23:19
85.93.35.221
,
пустое
)
Ну они занимают другую память :) Это само собой, если не пролезает по скорости или объему кода - то увы.
—
SM
(11.04.2007 16:25:10
85.21.249.17
,
пустое
)
Херня это и геморрой. Делай так -->
—
=AVR=
(11.04.2007 16:01:56
80.92.96.19
,
пустое
,
ссылка
)
Отправка ответа
Имя*:
Пароль:
E-mail:
Тема*:
Сообщение:
Ссылка на URL:
URL изображения:
если вы незарегистрированный на форуме пользователь, то
для успешного добавления сообщения заполните поле, как указано ниже:
введите число 63:
Перейти к списку ответов
|
Конференция
|
Раздел "Электроника"
|
Главная страница
|
Карта сайта
Web
telesys.ru