Почти ОС реального времени — 2

[kaoz]

писал что-то подобное для мп3 плеера на микроконтроллере атмел, где-то код у меня завалялся. но евент-дривен система совсем не осрв, потому что ваше произведение, как вы писали в первой части статьи, не соответствует определению ОСРВ ru.wikipedia.org/wiki/%D0%9E%D0%A1%D0%A0%D0%92

[torin2k]

По определению POSIX: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времен».

Если события жестко детерминированы по таймеру, то где не соответствие?

[gadub]

события детерминированы, а время их обработки — нет

[torin2k]

почему? сброс обработчика тоже по таймеру.

[bashmish]

Занятно и главное для меня как промэлектронщика весьма полезно.
Жду продолжения.

[denim]

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

[steel_ne]

Ходит как утка и крякает как утка — значит это утка :)

Я реализовал диспетчер задач и таймеры, но не реализовал приоритетное принудительное вытеснение процессов. Где граница, после которой «просто прошивка» становится rtos?

[HounD]

Такой способ реализации таймера даст большую погрешность, чем вы ожидаете. Задумайтесь, как и зачем реализованы аппаратные таймеры на меге, их там целых четыре, должно хватить ;) и на сейчас и на будущее.

[steel_ne]

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

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

—

[HounD]

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

[steel_ne]

Задача обработчика прерывания — или положить событие в очередь или уменьшить максимум 64 таймера. Все легко уложится в 200 мкс, то есть до прихода следующего прерывания.

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

[HounD]

Забыл еще одно :) Избегайте «магических» чисел вроде 41 в вашем коде. Заведите себе хотя бы
#define F_OSC 4096
#define TICK_COUNT (F_OSC/100)
А то прям мистика какая-то.

[steel_ne]

Согласен. Отголоски «быстрого-и-грязного».

[cod]

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

#define F_OSC 4096
// TICK_COUNT = F_OSC/100
#define TICK_COUNT 41

[HounD]

Ну вставиться везде формула, все равно ее компилятор посчитает и заменит константой. Можно и const понаписать, смысл не в этом, а что бы не забыть как считали.

[steel_ne]

В delay.h даже обязательное условие — использование оптимизации. Поскольку там такие же константные вычисления. Так что не страшно :)

[elgoog]

Я сталкивался с тем, что часы через какое-то время перестают генерить прерывание наружу.

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

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