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



Ну значит надо вызывать какую-то другую, неблокирующую функцию, типа MyUart.rx_count(). Тут уж вам виднее.
И кстати, если вы работаете с MyUart из разных потоков, то надо обернуть обращения к нему блокировками. Например, завести мьютекс MyUartMutex, и при начале работы его захватывать, а по окончании - отдавать.

А покажите код MyUart.receiveByte(). Пока он ожидает прихода байта он должен отдать управление.

Мда. Не удобно.

Модифицировал


И все заработало. Но походу это очень плохая идея.

Вот код получения байта.

Вы четко должны понять, в RTOS реализуется "псевдопараллельное" выполнение задач, ведь процессор то один. Если вы в своей функции, которая вызывается из самого приоритетного процесса, висите в while(), то никогда этот процесс не передаст управление другим процессам. Вставлять Sleep в функцию, вызываемую по прерыванию, на мой взгляд, тоже не лучший вариант. Не очень понятно, как оно у вас заработало

Заработало он из за того, что в Sleep вызывается Kernel.Scheduler().

Но ведь почему бы не создать прерывание по таймеру. В котором бы вызывался планировщик процессов. Который бы и определял на основе приоритетов кому вернуть управление.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Осталось только реализовать диспечер)))

Вопросы:
IdleProcess что точно он делает и зачем он нужен?
В документации так и ненашол, понятного обьяснения, по поводу использования прерывания компоратора. Как это использовать?
Существует ли более подробная документация? В операционке заметил функции и параметры которые нигде не описаны.

Я обычно в этом процессе повергаю контроллер в спячку.

Возникла проблемка. А как из одного усыпить другой процесс?

Итак(слитно). А смысл? Вы пока еще не поняли основных принципов вытесняющей многозадачности, но уже пишете свой планировщик. В вашем случае достаточно организовать в прерывании UART запись в канал, а в функции receiveByte() читать из этого канала. Передачу управления сделает сама ОС внутри функций канала. Вы же, образно говоря, пытаетесь запрячь лошадь в автомобиль и возмущаетесь, что и лошади тяжело и автомобиль движется медленно.Он работает, когда все остальные процессы спят. Часто используется для перевода ядра в спящий режим для снижения энергопотребления. А что в обычной программе делает процессор когда ему нечего делать полезного?не<пробел>нашел, компаратора, перебор с запятыми. Объяснение в документации есть - для переключения контекста нужно генерить какое-либо прерывание программно. Один из способов получения такого прерывания - дергать ногой, к которой внутри подключен вход компаратора. Второй возможный вариант - прерывание SPM, тоже есть в примерах.Что использовать? Что вы не нашли объяснения?Нет. Более подробной нет. Все функции, которые предназначены для использования пользователем - описаны. Неописанные функции используются внутри реализации ОС. Они нужны разработчикам самой ОС для реализации ее внутренностей, снабжены комментариями или самодокументированы своим кодом. Не предназначены для использования "снаружи" ОС.Никак.

В случае с UART использовать канал удобно. Но это частный случай.
Основная идея это чтоб бесконечный цикл в приоритетном процессе не вешал менее приоритетные процессы и менее приоритетный мог получить управление.

Функцию отправки другой процесс в спячку реализовал. Пришлось написать свою функцию Sleep.

А вот документация устарела.
Например где описано:
#define scmRTOS_ISRW_TYPE TISRW //_SS
#define scmRTOS_IDLE_PROCESS_STACK_SIZE 90 -- Почему 90 байт?
#define scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE 1 -- Это и так понятно.

TMutex t;
t.UnlockISR(); -- Это что за анлок?

Да, полный мрак . Действительно 100% совпадение с ситуацией из анекдота:

А это очередная иллюстрация такого "нового" подхода к жизни. Все вокруг ..., а я умнее всех и сейчас все быстренько наваяю. При этом не удосуживаются ни книг толковых почитать, ни к мнению коллег прислушаться. Такая вот c'est la vie.

scmRTOS простая операционка. В ней можно быстро разобраться.

Но мне нужен немного другой планировщик процессов. Я не говорил что он лучше, хуже и т.п.
Если после небольших изменений операционка перестанет соответствовать RTOS, то мне это пофигу.

Главное это рабочая прошивка. Не важно на сколько она будет корректной или нет. Главное это простота и работоспособность.

1)Большая программа складывается из частных случаев.
2)В программе не должно быть циклических опросов - ожиданий.
НапИшите более новую?
А попробуйте немного подумать. Если TEventFlag::SendISR() взводит флаг из прерывания, message::sendISR() посылает сообщение из прерывания, то что, исходя из своего названия, должен делать TMutex::UnlockISR()?

Я не разработчик scmRTOS поэтому не мне писать.
Если вносите поправки и дополнения в операционку то и где нибудь об этом сообщайте. А не зативайте игр "Угадай мелодию".

ЗЫ: Тема топика "Вопросы по scmRTOS".

Беда в том, что Вы совсем совсем не разобрались, причем не scmRTOS, а вообще, как системами-то пользуются. И похоже не собираетесь, поскольку, опять цитирую:

Это отвал башки какой-то. Если в системе есть приоритеты, то они ДОЛЖНЫ РАБОТАТЬ и никакой процесс с высоким приоритетом не может быть прерван процессом с низким приоритетом (только равным, или в результате инверсии приоритетов при разруливании доступа к ресурсам, но этого в scmRTOS нет ), ибо обратное ПЕРЕЧЕРКИВАЕТ ВСЮ систему. Как только, Вам в голову пришла вышеотцитированная "концепция", следует СРАЗУ забыть о вытесняющей многозадачности, слове приоритеты и взяв "чистый лист бумаги" ваять что в голову придет абы работало. Что собственно Вы и делаете, только зачем-то всуе поминая scmRTOS.




Только Ваши "идеи" к теме топика отношения не имеют , как и лошадь к трактору.
To:Сергей Борщ - Вынести этот разговор куда-нибудь подальше?

Та не волнуйтесь вы так. Я scmRTOS взял за основу. Потому что в ней было проще разобраться.

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

Я не говорил, что имею большой опыт работы с операционкой. Да и вообще с ООП не так часто общаюсь как хотелось.

У меня задача разработать прошивку которая будет очень простой. Ее будут модифицировать и дорабатывать другие люди. У меня нет никакого желания писать очень подробную документацию к прошивке и общаться с каждым новым разработчиком.
scmRTOS позволяет красиво оформить код.

Почему-то вы решили, что другие люди сходу разберутся в "красиво оформленном" коде под scmRTOS, если сами не понимаете и не хотите понять, как она работает?

P.S Самая красивая прошивка - n-байт 0xFF! Изумительное чудо.

Основы использования я уже понял. Для этого достаточно почитать документацию и посмотреть примеры.
А никому не нужно будет лезть в изучение scmRTOS.

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

Ведь когда пишут документацию к проекту под Win никто не описывает как работает ОС.

Есть один процесс. Во время выполнения был вызван Sleep(1).
Управление передастся IdleProcess до конца этого тика или до конца этого+1 следующих тик?

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

IAR AVR 5.30, scmRTOS.3.10

Использую п/п OS::SystemTimerUserHook() в качестве RTC для синхронизации процессов (таймеры в большом дефиците). В ней вызываю флаги событий TEventFlag. Для вызова использую SignalISR(), хотя вариант Signal() тоже работает и имеет более компактный код.
Понимаю, что SystemTimerUserHook() вызывается в прерывании и поэтому надо использовать SignalISR(). Но все же...
Может я что-то не учитываю? Каким способом лучше "сигналить" в моем случае?

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

Из прерываний лучше вызывать функции xxxISR(). Они легче и быстрее, оптимизированы для прерываний. Обычные тоже работают, но в них производятся "лишние" действия.

Большое спасибо

Помогите, пожалуйста, разрулить такую ситуацию.
Есть модуль на ассемблере, который включен в проект IAR AVR и вызывает ф-цию С++:

NAME boot
EXTERN BootLoader

ORG 0x7C00 // booloader address
boot:

CALL BootLoader
JMP 0x0000
END boot

сама ф-ция имеет вид:

void BootLoader (void) @ "BOOTSEG"
{
........
}

Линкер не видит ф-цию BootLoader и ругается:
Error[e46]: Undefined external "BootLoader" referred in boot ( D:\Work\AVR\scmRTOS.3.10\Counter\Obj\Boot.r90 )

Раньше, когда писал на С не было никаких проблем, а как перешел на С++ вот такая фигня.

Многократно уже писалось на эту тему. Ассемблер не понимает С++ -ные имена. Функция должна быть объявлена как:




Стандартный вариант для .h файлов:

спасибо за помощь!

Есть ли у когонить порт для sam7s под IAR 5.5 ?