Во, нормально. 4 - х байт на 136 лет хватит :-) («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; 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, пустое, ссылка)