Я это видел, и это называется неэффективное использование памяти. Когда все функции уже даны и даже прописаны в ANSI - пользуйся сколько влезет. И чухаться с годами и секундами будет ANSI C Library а не программист. («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

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

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

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

Я это видел, и это называется неэффективное использование памяти. Когда все функции уже даны и даже прописаны в ANSI - пользуйся сколько влезет. И чухаться с годами и секундами будет ANSI C Library а не программист.

Отправлено SM 11 апреля 2007 г. 16:22
В ответ на: Это геморрой. Никаких преобразований не надо, если просто все свести в битовую структуру и хранить АБСОЛЮТНОЕ время, а не чухаться с високосными годами, астрономическими/технологическими секундами и т.д. --> отправлено =AVR= 11 апреля 2007 г. 16:20

Составить ответ | Вернуться на конференцию

Ответы

Во-первых, чухаться будет не 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, пустое)