Здравствуйте!

scmRTOS v3 AVR/GCC.
Компилятор - WinAVR 20080610.
IDE - Code::Blocks 8.02.
Простую тестовую программу буду пробовать на ATmega88.

Приступил к изучению.
Читаю scmRTOS_v2.pdf, смотрю исходники примеров релиза.

Возникло несколько вопросов. Прошу помочь разобраться.
Буду очень благодарен за какие-нибудь шаблоны программ (без лишнего кода), практические рекомендации и ссылки!

Первые два вопроса - функции main примеров.
1. В примерах T0 - системный таймер. Почему инициализация и запуск системного таймера производится не средствами ОС (допустим, в Run), а пользователем ОС вручную?
2. Почему при использовании передачи управления на основе программного прерывания инициализация компаратора производится не средствами ОС, а пользователем ОС вручную?
3. Один тик системного таймера - одно его переполнение?
4. Рекомендуемое значение системного тика 1-10 мс. Т. е., мы должны настраивать системный таймер, на переполнение его в пределах этого времени?
5. Каковы будут дополнительные опции компилятора для моей связки ОС + компилятор + IDE?

Благодарю заранее!

Заработало оно потому, что принудительно отправляет активный процесс (Proc1) в спячку. То есть, вы таки заставили его отдать время другим. Пока не берусь судить о последствиях такого решения...
А планировщик и так вызывается по окончании прерывания от системного таймера. Именно благодаря этому более приоритерные задачи могут отбирать управление у менее приоритетных.

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

И получится виндоуз А нужен - реалтайм. То есть, детерминированное время реакции на событие.

Вместо того, чтоб с наскоку предлагать перекроить систему, подумайте лучше о том, как её правильно применить. Задействуйте прерывание от UART, и пропадёт надобность висеть в глухом опросе, ожидая прихода символа.
Или, более обобщённо: в подавляющем большинстве случаев встраиваемая программа представляет собой обработку внешних событий и периодических событий. Произошло внешнее событие - выполнили действия. Досчитал таймер до заданного значения - выполнили действия. Время реакции на событие - приоритет задачи. Практически никогда нет нужды в непрерывном выполнении какого-то куска кода. Возникновение внешнего события обычно определяется по прерыванию. Ну или путём опроса по таймеру, если нужного прерывания нет.

А почему сразу виндовс а не линукс?
Зато это будет удобно. Плюс можно дать выбор пользователю какой он хочет использовать планировщик. Время реакции ухудшится, но не всегда оно настолько кретично.
Щас делаю пишу прошивку в которой быстрая реакция не нужна. Зато есть множество датчиков которые нужно постоянно опрашивать.

О том как писать или не писать код то уже совсем другая тема.

Да без разницы. Ни то ни то не подходит для реалтайма.

Окей, не стану утомлять поучениями.

Извините, но я с поучениями . В Вашем случае, по крайней мере на данный момент, Вы, как пользователь, вообще не знаете, что хотите от системы. Хочу, чтобы работало все, чего-бы я не написал, даже если я не представляю, что я делаю, это не подход к делу . Тем более в мире компактных систем. Прадигма которой руководствовался Автор при создании scmRTOS изложена четко и внятно, не сочтите за труд для начала ознакомиться, понять, ну и уж потом принять, или отвергнуть.

Я знаю чего хочу.
Я хочу, чтоб код был очень простым. Он будет медленным зато надежным, быстро разрабатываться и отлаживаться, будет наглядным. Т.е. сторонний разработчик сможет быстро вникнуть и внести свои изменения в прошивку.
Я как пользователь знаю чего хочу. Я не хочу постоянно более приоритетные процессы отправлять в спячку, чтоб смогли отработать другие. Будут проблемы с таимингами, но это уже проблема выбора такого планировщика.

Мне все равно как это будет называться, RTOS или нет. Если устройство будет работать правильно то всем будет пофигу на то какая там корректная прошивка.

Думаю подобного многие хотят. Но чтоб это сделать придется изменить операционку.

Вы не кипятитесь. Почитайте лучше документацию на scmRTOS. В ней Журов во введении дает очень хорошее внятное описание RTOS вообще. Рассматривает различные типы планировщиков. То чего вы желаете - система с кооперативным планировщиком (пример Salvo - www.pumpkininc.com). scmRTOS использует приоритетное вытесняющее планирование процессов. То есть вам она просто не подходит.

Я не кипячусь.
В кооперативках ведь тоже нужно чтоб каждый процесс отдавал управление. Т.е. бесконечный цикл в одном процессе может повесить всю систему.
В scmRTOS бесконечный цикл в менее приоритетном процессе не вешает систему.

В моем примере:
Если первый процесс будет постоянно отправлять байт и засыпать. А второй в бесконечном цикле будет ждать байт то все будет работать.

Но так не интересно. Хочется чтоб и менее приоритетный процесс имел шанс получить управление. И это будет удобно.
А название, в таком случае, scmRTOS можно и модифицировать на scmRTOS/Вантуз. Хотя что то сомневаюсь, что реализацией такого планировщика кто то займется.

Почитав еще и этот опус, посмею повторить - НЕ знаете . Некие мысли сделать "красиво", но не более .
Ну а так, вообще, где-то у Вас в голове возможно что-то несколько похожее на задачи одного уровня приоритета мелькает. Их в этой системе нет. Пали жертвой прадигмы . Но обойтись в принципе можно. Возможно, наличие кооперативных задач помогло-бы более красиво решать определенный круг задач. Но их тоже нет в прадигме , но можно ручками сделать в одной из задач.

Вы будете, к сожалению, удивлены, но вешает, ибо есть процесс, который никогда не получит управления. Задание - узнать как его зовут.

Но в таком случае все отлично работает. Менее приоритетный процесс не вешает систему.

А зачем тогда в такой реализации заглушке передавать управление? Ведь первый процес будет стоять, стоять столько сколько ему положено. Заглушка актуальна когда оба процесса уснут и тогда на время спячки IdleProcess получит управление.

Сообщение отредактировал a9d - Apr 10 2010, 11:23

Ответ не верный. Жду ответа на ранее заданный вопрос.

Я уже ответил. В моем случае передавать управление IdleProcess особого смысла нет.
Тем более если посмотреть его иходник то можно увидеть, что это пустой цикл. А значит бесконечный цикл в менее приоритетном процессе не может повесить более приоритетный. Если это утверждение не верно то IdleProcess должен вешать операционку.

Этот процесс, в отличие от Вашего является частью ядра системы. Занимает ресурсы. Пустой он не всегда. Блокировать его пользовательским процессом нималейшего смысла нет. Как и без даже отдаленного знания системы начинать городить нечто ДОФАНТАЗИРУЯ нечто в меру своего кругозора. Ну прочитайте Вы, наконец, документацию. Поймите, что система имеет не только переключатель задач.

Я документацию читал.
Как я понял IdleProcess нужен для простоя операционки. Другого применения я не заметил(перехват не имеется ввиду).
В этом процессе явно не выполняется других действий необходимых операционке.

Сообщение отредактировал a9d - Apr 10 2010, 12:44