> [14] kilkennycat ©   (28.01.17 13:06)

Тоже хорошо, только нет возможности посчитать уже использованный ресурс, но на это можно забить.

И ещё не должно быть ноль в состоянии.

> чтение всего eeprom побайтно медленновато, несколько секунд.
это опытное значение или из описания на mcu ?

> ртс необходим лишь для гарантированного значения времени
я и не спорю  - просто дешёвый вариант для меги.

> [22] NoUser ©   (28.01.17 14:02)
> > чтение всего eeprom побайтно медленновато, несколько секунд.
> это опытное значение или из описания на mcu ?
>
> > ртс необходим лишь для гарантированного значения времени
> я и не спорю  - просто дешёвый вариант для меги.

ща схожу на почту за эмулятором монитора из Латвии и с делаю замер. Скетч с очисткой всего eeprom выполняется секунды 3-4. Может запись дольше сильно идет ченм чтение, специально не замерял. Попробую в микросекундах померять чтение.

> kilkennycat ©   (28.01.17 13:06) [14]
> Итого: имеем запись по кругу, возможность чтения истории за некий период.

и в два раза меньший срок службы устройства. (и какой это будет период?, если rtc-а нет) ;))

> с очисткой всего eeprom выполняется секунды 3-4. Может запись дольше сильно идет чем чтение

Ага.

> Попробую в микросекундах померять чтение.
В начале операции запрети прерывания, запусти какой-нибудь внутренний таймер - после останови, посмотри значение.

> Скетч ...
ах да, я то меги прямиком зашиваю, - а есть возможность видеть асм выхлоп?

> NoUser ©   (28.01.17 14:12) [24]
> и в два раза меньший срок службы устройства. (и какой это
> будет период?, если rtc-а нет) ;))

при чем здесь в два раза срок? как посчитал?
как периоды относятся к часам реального времени?

> NailMan ©   (28.01.17 14:06) [23]

не надо читать и писать всё постоянно. записываешь лишь свои данные и ноль на следующий адрес.
читаешь всё только после потери счетчика адреса для его восстановления.

> kilkennycat ©   (28.01.17 14:36) [26]
ох.

> при чем здесь в два раза срок? как посчитал?

Фраза "возможность чтения истории за некий период" говорит о том, что каждая новая запись происходит по новому указателю. А это значит, что к каждой записи прицеплен хвост, который, в данном случаи, увеличивает количество записываемых данных в два раза, пропорционально уменьшая ресурс носителя.

> как периоды относятся к часам реального времени?

по заданию видно, что период измерения/накопления также зависит от наличия основного питания.

> kilkennycat ©   (28.01.17 14:40) [27]
>записываешь лишь свои данные и ноль на следующий адрес. читаешь всё только после потери счетчика адреса для его восстановления

Если имеется ввиду отсутствие изменения адреса на каждую новую запись, то это уже другая редакция алгоритма.

> NoUser ©   (28.01.17 15:19) [28]

да, это я не подумал, запись маркера действительно уменьшает.

> Если имеется ввиду отсутствие изменения адреса на каждую
> новую запись, то это уже другая редакция алгоритма.

нет, почему, адрес меняется. алгоритм один и тот же. хранение адреса позволяет лишь избежать постоянного поиска адреса.

> по заданию видно, что период измерения/накопления также
> зависит от наличия основного питания.
>

хм.. не вижу. я вижу лишь "каждые 10 секунд". но даже если и от наличия питания какое-то условие, то всё равно не видно требования сохранения определенной даты.

> [28] NoUser ©   (28.01.17 15:19)
> к каждой записи прицеплен хвост, который, в данном случаи,
> увеличивает количество записываемых данных в два раза

А при записи счётчика в одну ячейку во сколько раз?

Ну и, может кто забыл, что можно писать байтами, но уложить в них инфу и ещё что-то в свободные биты.

да. и еще, тз как всегда неполное. если счетчик адреса теряется редко, то его хранением вполне можно пренебречь.

> [32] kilkennycat ©   (28.01.17 16:00)
> да. и еще, тз как всегда неполное. если счетчик адреса теряется
> редко, то его хранением вполне можно пренебречь.

Устройство будет эксплуатироваться так - в начале дня приезжаем на поле где будем летать, включаю модель, девайс включается. Я захожу в интерактивное меню(с помощью единственного органа управления) и там делаю сброс счетчика потребленных мА. Устройство сразу начинает считать энергию (мА/час) с нуля(предполагаем что АКб заряжена)  и дампить каждые 10 сек в eeprom съеденные мА. Полетав и выключив модель, обесточив девайс и включив снова при следующем полете девайс считывает сохраненное значение съеденных мА и продолжает считать прибавляя к нему расход за следующую сессию пока девайс запитан.

Пока девайс работает он все шлет в последовательный порт и на БТ-модуль где я с мабилы могу посмотреть все нужное в реальном времени.

Чуть попозжа я еще вопросик задам - есть какой то глюк-мутант в счетчиках и вычислении среднего арифметического. Я не могу никак понять в чем косяк. Надо видео записать с демонстрацией.

Вот проект собственной персоной если интересно
https://github.com/NailAlex/KillSwitchDuino

Это сам скетч
https://github.com/NailAlex/KillSwitchDuino/blob/master/KillSwitchduino/KillSwitchduino.ino

> [30] А при записи счётчика в одну ячейку во сколько раз?

>> Если запись-чтение не идентичны - меняешь адрес счётчика

Можно совместить алгоритмы и не хранить адрес счётчика а искать его при старте по хвостовому маркеру (например, 0xFFFFFFFF, так как при первичной инициализации на подготовку 'базы'  нужна будет ~одна команда и ~10ms)

> NailMan ©   (28.01.17 16:13) [33]

ресурсов еепром гарантированно хватит на 11 суток непрерывной работы если писать в одно место.
при батарейном питании сбои маловероятны. никакого маркера записывать необходимости нет. если 11 суток непрерывной работы мало, то при включении счетчик адреса устанавливается в ноль, абсолютно пофиг, если до этого он уже десять раз подряд всегда был ноль (то есть девайс включался менее чем на 10 секунд) и всё пишется по кругу.

если подвесищь внешнюю еепром, то можешь круглосуточно писать полгода в одно место. соответственно, если летать 2 часа ежедневно, то на 5 лет хватит.

Ща напишу скетч с замером скорости чтения и записи в eeprom. А вот еще один вопросец с видеодемонстрацией
https://www.youtube.com/watch?v=8ZyyDDmC0bE

Девайс получает на пин с аппаратным прерыванием PPM-сигнал(разновидность PWM), который имеет прямой импульс определенной длины(1000-2000мкс) кодирующий положение стика(или тумблера) от 0-100%. Количество импульсов(пакетов) за секунду ВСЕГДА 50 при нормальном приеме. В скетче сделал обработчик прерывания на этом пину(any change) и вычисляется длительность импульса в мкс(точность 4мкс) и определяется тумблер вверх или вниз опущен, плюс считается количество нажатий и самое главное - количество пакетов. Так как счетчик быстрый, там же в обработчике прерывания я определяю максимальное значение счетчика пакетов и потом я в обработчике программного таймера(отрабатывается раз в 250мс) я раз в секунду его обнуляю. Также я суммирую это значение пакетов за одну секунду и вычисляю среднее арифметическое количества пакетов за прошедшую секунду, если качество приема хреновое, то оно будет отличаться от 50, если меньше 1 то сигнал пропал и появляется алерт.

В течение работы какое то время все считается нормально, потом среднее значение за секунду становится 32 и нарастает до 50 потом все повторяется(на видео показано).

Вот как считаю каждые 250мс(4 раза в сек)




Выясняя почему происходит такой сброс я уже мозг сломал раза 2. Переписывал раза 4 счетоводство - все время такая байда получается. Причем в порт вывожу   LastMaxMainSWPacketsCounter и LastMainSWPacketsAverage, чтобы сами счетчики не трогать.

Никак не пойму в чем косяк.

на мой взгляд, невозможно определить косяк, не видя всей картины. хрен знает, что у тебя там с прерываниями, кто кого успевает обработать, а кого нет.

* ~одна команда => стирание всего eeprom

> глюк-мутант

При чтении/записи 16-битных регистров  в/в используется один на весь кристалл скрытый временный регистр. Но перенос в память этих 16-битных регистров не атомарный (два 8-битных mov). А значит может возникнуть ситуация, когда в момент чтения регистров АЦП  происходит прерывание, в обработчике которого, например, есть чтение 16-битного таймера с затиранием этого временного регистра.

И, кажется, при смени канала АЦП рекомендуют делать одно холостое преобразования для верности.

P.S.


и вселенной не грозит тепловая смерть )))