0
Не совсем понятно. Я и 5, и 15, и 42 минуты отмерял с небольшой ошибкой. Логика работы такая: просыпаемся, вычитаем 1 период сработки. Если нажата кнопка добавляем соответствующую задержку к уже имеющейся. Если ноль — пищим. Ваш исходник потом гляну.
Я бы просто привёл к следующему: при сработке — добавляем интервал заново. При нажитии обеих кнопок — обнуляем и интервал, и счётчик (верно, это отдельные переменные). Выдержки удобно вести в «разах» таймера, а для читаемости, через макросы привести к секундам.
ПыСы: Для тестов можно запустить без экономии энергии, таймер опрашивать по флагу и сбрасывать в петле. А когда будет всё хорошо с интервалами — тогда вернуться к экономному режиму работы.
  • avatar
  • Hoksmur
  • 10 октября 2017, 18:28
0
Если правильно вспомнил — чтобы переменная секунды хранила, для удобства. Опять же, дискретность подстройки меньше. Если уменьшите частоту пробуждений, то и батарейки на дольше хватать будет.
  • avatar
  • Hoksmur
  • 05 октября 2017, 20:18
0
Примерно так, я уже не помню подробности. По даташиту разброс сторожевого таймера довольно большой, подбирал опытным путём цифру «50». Можно попробовать поставить бОльший делитель, и тогда уже дефайн уменьшать.
  • avatar
  • Hoksmur
  • 05 октября 2017, 20:13
0
Конфигурация правильная. Контроллер именно ATTiny13? Или на что-то переносили? Первый макрос тоже не совпадает с моим.
Попробуйте прошить *.hex из архива — как себя вести будет?
  • avatar
  • Hoksmur
  • 05 октября 2017, 20:03
0
Фьюзы в исходнике указано, что должны стоять по умолчанию:
FUSES =
    {
        .low  = LFUSE_DEFAULT,
        .high = HFUSE_DEFAULT
    }; /* hfuse=0xff, lfuse=0x6A */

Выводы(пины):
#define T1PRESS 0b10
#define T5PRESS 0b01
//....
		buttons = PINB & 0x03;
		switch (buttons) {
		// ....
		}

Я шил AVRDUDE, он понимает «компилированные» фьюзы, да и как параметр можно задать.
Проверьте у себя этот макрос:
#define T5MIN (T1MIN*5)

А то я испугался, полез проверять… Или у вас здесь опечатка?
Написали бы каким инструментарием вы пользуетесь, тогда знающие подскажут, а так приходится гадать, «что же там» у вас.
  • avatar
  • Hoksmur
  • 05 октября 2017, 19:57
0
Молодец! У меня задач таких нет, но вряд ли я бы нашёл/применил эту файловую систему. Если будет описание процесса портирования — вообще красота!
  • avatar
  • Hoksmur
  • 29 августа 2017, 06:18
0
Не по феншую написано, зачем спорить? Из тестового проекта скопировал. Да и дефайны за функцию лучше бы вынести. Поправить?
  • avatar
  • Hoksmur
  • 11 апреля 2017, 12:13
0
Поправил, спасибо.
  • avatar
  • Hoksmur
  • 11 апреля 2017, 11:24
0
А транзисторы на что?
  • avatar
  • Hoksmur
  • 14 ноября 2016, 19:24
0
Спасибо за труд, podkassetnik . Без сарказма. Хороший материал для тех, кто не знал подобного способа или у кого проблемы с английским. Есть вот аппнот от Atmel-а документ, последняя ревизия 2005г, и даже контроллер AT90S1200 — музейный!
В общем, не ленитесь читать Application Notes. В том числе производителей контроллеров, которые вы не используете. По каким-то ARM-ама есть арифметика с фиксированной точкой; у NXP видел как сравнить разводки печаток для АЦП,…
  • avatar
  • Hoksmur
  • 14 ноября 2016, 19:16
0
Поясню, про что я писал, а то чувствую себя паникёром. Для 52(dec) и ограничимся 8 разрядами.
/*
52 dec to 16-bit bin
0000000000110100 - value
....****....****
00011010.0ooooo - [1...]
00001101.00oooo - [11..]
00000000.110100 - [11..] [1... ]
00000000.0110100 - [11..] [11.. ]
00100111 - summ , >>3
00000100 - result is 4!!!
*/

Как выясняется, последовательность действий важна, то есть нельзя насдвигать, а потом результаты сдвигов складывать, надо именно с накоплением на каждом сдвиге. Вроде как эквивалентны должны быть, к.м.к.
  • avatar
  • Hoksmur
  • 27 сентября 2016, 07:47
0
Хм… Оказывается, я с первого раза не совсем понял алгоритм: вы не тетрады (нииблы, 4 бита) копируете, а удваиваете каждый раз количество используемых битов с накоплением суммы. Хитро!
uint32_t out = n>>1; // first nibble
out += n>>2;
// [1100 ....] [.... ....] [.... ....] [.... ....]
out += out >> 4;
// [1100 1100] [.... ....] [.... ....] [.... ....]
out += out >> 8;
// [1100 1100] [1100 1100] [.... ....] [.... ....]
out += out >> 16;
// [1100 1100] [1100 1100] [1100 1100] [1100 1100]

Ошибку вы обходите автокоррекцией результата.
Добавив ещё один сдвиг на 32 и используя 64-битные значения получил тоже корректные значения. Похоже, ошибка округления компенсируется в результирующей сумме не вполне понятным для меня образом, потому как с отдельными тетрадами (здесь совпадает с периодом дроби (1100)bin), ошибка накапливается.
Спасибо большое за статью!
  • avatar
  • Hoksmur
  • 26 сентября 2016, 19:54
+1
Тема хоть и древняя, но понекрофильствую всё же. Способ #5 не даёт корректные результаты в том виде, в котором они здесь приведены. Кто сомневается — проверьте 21dec и 2971215073dec. И причина ошибки проста: при умножении двух чисел разрядность результата равна сумме разрядов исходных величин. И при сдвиге тоже надо их не просто выкидывать, а оставлять в дробной части, которая как раз накопит недостающую разницу. Вот после полной обработки уже можно дробную часть выкинуть.
Становится понятен и «трюк компилятора GCC» — это магическое число и есть не что иное, как «0.1», интерпретированное как целое число. Если я прав, то это 0x19999999.

Придумал ещё способ, основанный на дробях или на рядах, уж не знаю, как правильней сказать. Если доберусь — набросаю материал (надо или нет — высказывайте). Но предварительные результаты без сохранения дробной части хуже.
neiver , протестируете, как опишу, если вы ещё на сайте присутсвуете?
  • avatar
  • Hoksmur
  • 26 сентября 2016, 14:38
0
Хорошо, спасибо. К.м.к., лучше поменять на
[FileSize:uint32][FileNameSize:uint8][FileName:FileNameSize][FileData:FileSize]
или же
[FileNameSize:uint8][FileName:FileNameSize][FileSize:uint32][FileData:FileSize]
и выровнять на границу long-а. Тогда доступ на 32-х разрядной платформе будет проще. А 8-мибитникам без разницы. Согласны с аргументами?
  • avatar
  • Hoksmur
  • 23 августа 2016, 06:15
0
Vga , вы верно ответили. А как делали у себя? размер+имя(строка со счётчиком?)+тело? Или как? Я про это:
Самый простой из моих форматов имеет 5+namelen байт заголовка на файл и не использует заголовок архива вообще.
  • avatar
  • Hoksmur
  • 22 августа 2016, 11:38
0
Про 24 бита вы правы, там шаг 16 байт. Но не думаю, что это актуально. В конце концов, никто не мешает ни мне, ни вам создать образ и поковыряться в нём шестнадцатиричным редактором.
  • avatar
  • Hoksmur
  • 18 августа 2016, 19:01
0
Это даже не про размер написано. Перечитай еще раз, но внимательнее.
Не горячитесь. Формально вы правы, а по факту — размер файла не может быть больше, чем смещение до следующего заголовка, то есть приходим к тем же 24 битам.

Врядли тебе понадобятся linux-specific возможности, заложенные в FS.
Если мы говорим о romfs — то их там нет. Имя и размер. Всё. В cpio — да, есть.

Зато вполне вероятно потребуется что-то другое. Если не стоит задача взаимодействия с чем-то другим, либо задействования готовых инструментов, нужды использовать стандартное решение нет.
Всё верно. Вам "Блокнот:" в заголовке и публикация в личном разделе ни о чём не говорит?
  • avatar
  • Hoksmur
  • 18 августа 2016, 18:40
0
Ага, так и задумывалось. Самому чтобы не забыть, ну и другим вдруг полезно будет.
  • avatar
  • Hoksmur
  • 18 августа 2016, 18:08
0
Где это? По линнку указано 32 бита на размер файла.
Since the file headers begin always at a 16 byte boundary, the lowest
4 bits would be always zero in the next filehdr pointer. These four
bits are used for the mode information.
Контрольной суммы. CRC — это вполне конкретный алгоритм, и в ROMFS используется не он.
Согласен, что тут присутствует неоднозначность с термином. Но согласно текущей wiki CRC это
Циклический избыточный код (англ. Cyclic redundancy check, CRC[1]) — алгоритм нахождения контрольной суммы, предназначенный для проверки целостности данных[2].
Если бы подразумевался конкретный алгоритм, то было бы что-то вроде CRC+циферка. У автора так реализовано:
int romfs_checksum(void *data, int size)
{
        int32_t sum, word, *ptr;

        sum = 0; ptr = data;
        size>>=2;
        while (size>0) {
                word = *ptr++;
                sum += ntohl(word);
                size--;
        }
        return sum;
}

Есть еще вариант «сделать свою FS», реализовав только то, что нужно.
Самый разумный, в общем-то. Но есть такой момент: по функционалу очень быстро можно придти к romfs, а получить ещё один стандарт. Как на картинке.
  • avatar
  • Hoksmur
  • 18 августа 2016, 17:50
0
А в целом — неплохо! "+"