Как стать автором
Обновить

Комментарии 18

НЛО прилетело и опубликовало эту надпись здесь
писал что-то подобное для мп3 плеера на микроконтроллере атмел, где-то код у меня завалялся. но евент-дривен система совсем не осрв, потому что ваше произведение, как вы писали в первой части статьи, не соответствует определению ОСРВ ru.wikipedia.org/wiki/%D0%9E%D0%A1%D0%A0%D0%92
По определению POSIX: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времен».

Если события жестко детерминированы по таймеру, то где не соответствие?
события детерминированы, а время их обработки — нет
почему? сброс обработчика тоже по таймеру.
Занятно и главное для меня как промэлектронщика весьма полезно.
Жду продолжения.
то что вам не нужно, исходя из прошлого поста, автоматически деградировало задание до уровня обычной прошивки. rtos тут и не пахнет
Ходит как утка и крякает как утка — значит это утка :)

Я реализовал диспетчер задач и таймеры, но не реализовал приоритетное принудительное вытеснение процессов. Где граница, после которой «просто прошивка» становится rtos?
Такой способ реализации таймера даст большую погрешность, чем вы ожидаете. Задумайтесь, как и зачем реализованы аппаратные таймеры на меге, их там целых четыре, должно хватить ;) и на сейчас и на будущее.
Конечно. А за счет чего? Только за счет того, что в некоторых участках кода могут быть заблокированы прерывания на время, большее чем 200 мксек. И то ошибка не составит больше, чем единицы процентов. Тик таймера — 41 прерывание.
Да, сработал таймер и событие ждет обработки в очереди. Но до следующего тика таймера оно будет гарантировано обработано. Задачи некритичны к задержкам менее тика таймера.

По поводу аппаратных таймеров — разработчики набора задействовали все таймеры на такую фигню:
— управление яркостью и контрастностью экранчика (аппаратный ШИМ. Или правильно писать «аппаратная ШИМ»?)
— бипер (опять ШИМ)

За счет того, что ваш таймер стоит пока вы находитесь в обработчике прерывания. Т.е. погрешность к погрешности 4096/100 ~ 41 добавьте еще время работы вашего обработчика. Но это важно если вы будете использовать таймер как часы реального времени. Ну и на одном таймере вполне возможно реализовать 3,4,5+ ШИМ если подумать.
Задача обработчика прерывания — или положить событие в очередь или уменьшить максимум 64 таймера. Все легко уложится в 200 мкс, то есть до прихода следующего прерывания.

Проверял на работу как часы реального времени — визуально за час не разбежалось на секунду. Плюс к этому у меня есть отдельно аппаратные часы реального времени — синхронизироваться раз в час не проблема совсем.
Забыл еще одно :) Избегайте «магических» чисел вроде 41 в вашем коде. Заведите себе хотя бы
#define F_OSC 4096
#define TICK_COUNT (F_OSC/100)
А то прям мистика какая-то.
Согласен. Отголоски «быстрого-и-грязного».
В дефайнах нехорошо использовать формулы, ведь они будут кадый раз пересчитываться в местах использования.

#define F_OSC 4096
// TICK_COUNT = F_OSC/100
#define TICK_COUNT 41
Ну вставиться везде формула, все равно ее компилятор посчитает и заменит константой. Можно и const понаписать, смысл не в этом, а что бы не забыть как считали.
В delay.h даже обязательное условие — использование оптимизации. Поскольку там такие же константные вычисления. Так что не страшно :)
Я сталкивался с тем, что часы через какое-то время перестают генерить прерывание наружу.

Именно даллас1307. проходят месяцы безпроблемной работы и фигакс- все останавливается.
Батарейка исправна, часы ходят (не сбиваются). Это совсем небольшой процент их сотен инсталляций.

А если на прерывании, которое создают часы, висит что-то полезное — типа — подключиться к интернет
и отдать статистику, то становится печально.

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