Ну, тут, имхо, вообще тогда не стоит с этим шаблоном связываться. Какие преимущества он дает? Инкапсуляция грубо попрана, абстракции никакой не осталось - по сути работаете с потрохами объекта напрямую, минуя его интерфейс. Ну, и зачем тогда вообще объект? Заводите себе буфер в памяти и спокойно работаете с ним. А может удобнее было бы завести пару буферов - в один пишете, другой по DMA отдаете (если условия задачи позволяют обойтись двумя буферами). Или, например, если буфера небольшие, то завести некий пул буферов - один, который отдает данные, передать DMA, остальные в работе с источниками данных, буфера переключать... И т.д. Подход, конечно, низкоуровневый, и имеет хорошее только частное решение, но он, имхо, ничем не хуже, чем потрошить объект кольцевого буфера, сам смысл которого - скрыть от пользователя реализацию и только предоставить удобный и безопасный интерфейс.

Затем, что в нем уже реализовано 90% того, что мне надо - работа с кольцевым буфером, запись внего... Я лишь добавил один метод, который возвращает мне адрес для DMA.
Ну собственно говоря ладно тогда, коль не убедил Придумаю более удачный пример расширения наследованием, надеюсь, убедю.
Спасибо.

Ну, например, я хочу сделать отладочный вариант кольцевого буфера. С выдачей дампа его содержимого. Да мало ли чего ещё
Тут, имхо, вопрос надо ставить так: а чем может повредиить применение protected вместо private? Моё мнение здесь такое - ничем. Если человек наследует какой-то объект, то он либо знает что делает, либо сам себе злобный буратино. Запрещать всем наследоваться из-за нескольких потенциальных буратин? Имхо, это неправильно
ЗЫ. Хочу витруальный Exec()!

Есть в вашем предложении интересное зерно. Будем подумать.


Оно исходно шло (и идет) как библиотека поддержки. Никакого расширения тут просто не предполагалось. А если так рассуждать, что вообще долой private, даешь везде protected - мало ли кому что может захотеться.


Это ты про процесс, что-ли? И как ты его собрался вызывать?

Ну а почему нет? Зачем заранее рубить возможные расширения? Это ж не винда Да и винду расковыряли, несмотря ни на что.



Дык, элементарно:

1. Делаем TBaseProcess.Exec() виртуальной (пустой или чисто виртуальной - неважно);
2. Добавляем в OS_Kernel.cpp новую функцию - трамплин:
   
   Код
   void OS::start_process(void)
   {
       TBaseProcess* proc = Kernel.ProcessTable[Kernel.CurProcPriority];
       proc->Exec();
   }
3. Добавляем эту функцию в друзья классам TKernel и TBaseProcess (если Exec - protected);
4. Убираем третий параметр у конструктора TBaseProcess:
   
   Код
   TBaseProcess::TBaseProcess(TStackItem* Stack, TPriority pr)
   {
       Kernel.RegisterProcess(this);
   ...
       *(--StackPointer)  = reinterpret_cast<dword>(start_process);
5. И телемаркет! ©

Имхо, весьма элегантно. Может даже и выигрыш есть... Завтра попробую в работе

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


Э-э... А запускать ты их откуда собрался? А как тут все это вяжется со стековым кадром? И самое главное - зачем все это? Какие преимущества это дает? Зачему тут динамический полиморфизм, когда все механизмы исходно статические?


Давай. Расскажешь потом.

Ура


Вроде я всё написал. В конструкторе TBaseProcess вместо адреса статического Exec() используется адрес глобальной функции start_process(). А она уже определяет текущий процесс и запускает его функцию Exec(). Вся эта возня происходит всего один раз при старте процесса, то есть, на скорость работы не влияет абсолютно.

А всё это ради того, чтоб функция Exec была не статической. Тогда она сможет обращаться с членами класса-процесса. И можно будет сделать нормальную инкапсуляцию. Например, процесс LcdProcess будет иметь приватный член Lcd, и все остальные процессы будут писать в Lcd только посредством вызова методов класса LcdProcess.
Сейчас для этого приходится заводить класс-посредник, типа LcdProxy. У меня практически все методы Exec выглядят как

Я понимаю, что это мелочи, но напрягает. Наверняка есть ещё плюсы моего подхода, но я их пока не придумал



Проверил, всё замечательно работает Причём даже без изменения проектов.

Вот мне в свое время тоже этого не хватало. Я хотел создать свой тип процесса, который работал бы с портом. То есть все остальные процессы лишь вызывают функцию передачи сообщения, а упаковкой данных в мой протокол, отправкой и приемом данных по UART занимается процесс. Прелесть в том, что я могу создать несколько таких однотиповых процессов, которые будут работать принципиально одинаково с разными портами, например. Это невозможно из-за статичности Exec() (из нее нельзя обращаться к нестатическим членам класса inher_process - наследника process).

Во-первых, зачем функцию делать виртуальной? Обычная (просто в шаблоне объявить функцию-член, не в предке) не сойдет? Виртуальная функция потащит накладняки в виде vptr в каждом объекте + vtbl на каждый тип (т.е. тоже на каждый объект). Это мелочи, конечно. Но зачем?

Во-вторых, вызов функции из start_process будет сохранять в стеке адрес возврата (и еще всякую служебную инфу в зависимости от платформы). С этим тоже можно с разным успехом побороться с помощью расширений типа __task (у IAR), но зачем?

Ну, и в-третьих (см ниже)...


Тот вариант (который ты предложил) по сути является эквивалентным этому. Только там вызов terminal.loop() упрятан в недра. Это лучше? Сомневаюсь.

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

А статическая функция как раз очень хорошо согласуется с принципом - у процесса (объекта) может быть только одна единственная исполняемая функция, реализующая поток выполнения этого процесса.

И следует четко осознать - функция-поток не является никаким пользовательским кодом. Это код ОС, которая предоставляет пользователю организовать свой код в псевдопараллельном виде и управляемый по событиям (event-driven). И поэтому надо четко отделять представление объекта-процесса от пользовательского кода, запускаемого из этого процесса. Т.ч. все логично.


Не понял, чего вам не хватило. Не понял, зачем городить несколько однотипных процессов, ведь процесс - довольно ресурсоемкая штука, впору наоборот задуматься, как бы в один процесс упаковать несколько задач (если они выполняются в одном темпе). И самое главное, не понял, что бы вам дало, если бы Exec была бы нестатической? Ну, получили бы вы непосредственный доступ к преставлению объекта-процесса:



И что вам это дает?

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



Это да, накладных расходов довольно много. Это меня немножко смущает. Но тут надо ещё поковыряться, я ведь просто демонстрировал концепцию, наверное можно проще.



Ну, мне кажется, что так - стройнее, что ли. Есть процесс, есть его поля и методы. А не так, что есть процесс, а всё остальное (поля и методы) - в отдельном, другом объекте.



Так с этого и началось Хотел добавить отладочные функции (размер стека, плюс (может быть) время активного состояния процесса, то, сё...). Без правки кода ОС. Вот и возникла мысль.
Хотя конечно, при более внимательном рассмотрении видно, что это несколько противоречит идеологии ОС



Как это? А если она вызовет другую? Ну и вообще, что статическая, что обычная функция при условии единственного экземпляра объекта - разницы практически никакой. (кроме возможности обращения к полям объекта)



А вот тут - ни слова не понял

Стройнее оно было бы, если бы пользовательский код реально имел бы потребность в доступе к представлению (закрытой части) объекта-процесса. А такой потребности нет.



Отладочный функционал надо разрабатывать и включать отдельно. Кстати, можно попробовать отнаследоваться от OS::process<> и там уже добавлять все, что душе угодно.



Идеологически уже неверно. Рутовая функция должна быть одна. И статическая функция это обеспечивает в силу правил языка. В отличие от.


template<> TTerminalProcess::Exec() - это часть ОС, это код, обеспечиваемый осью особой функциональностью. Это не пользовательский код.

Terminal.Loop() - это пользовательский код, написанный в соответствии с потребностями задачи.

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

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

А отладка?



Не выйдет. Ибо Exec() - не виртуальная. А именно её конструктор OS::process<> передаёт в конструктор TBaseProcess.
Вернее, у меня получилось, но лишь путём полной замены OS::process<> на OS::debugprocess<> с переписыванием всего функционала



Объект всё равно тоже должен быть один, это всяко нужно контролировать. Так что не суть.



Не согласен. И то и то - пользовательский код. Я - пользователь, я завёл процесс TTerminalProcess, это мой, пользовательский процесс. И моё, пользователя, дело - писать весь код прямо в TTerminalProcess::Exec() или вынести его в отдельную функцию. От этого он не становится системным/пользовательским. А функция ОС - вызвать этот код и обеспечивать ему процессорные ресурсы.



Это-то я прекрасно понял Но ведь не вредно иногда порассуждать в ту или иную сторону от исходной идеологии? Может что-то придумается дельное

Про отладку писал выше - это надо функционал закладывать сразу в сорцы оси. И формализовать интерфейс управления этим делом. Остальное - костыли.


Да, точно. И дело не в виртуальности, а в статичности.


Ну, тогда вся ос - тоже пользовательский код. Критерий простой - Exec вызывается осью, значит это ее ресурс. А пользовательская функция вызывается пользователем - это его ресурс. И связи смысловой (чтобы нужно было обмениваться данными) меж ними нет.

У меня мысль "процесс как часть пользовательского кода" вытекает приблизительно из следующего:
Ну вот есть "драйверный" класс для работы с аппаратурой. Есть у него функция-оработчик ISR, есть запрятанные внутрь мьютексы и, возможно, события, клиенты дргают за открытые функции. При этом они могут уснуть по мьютксу или по ожидаию события завершения работы, могут просто в очередь что-то поставить - не важно, реализация спрятана внутри. За .do() дёрнули и всё.
Теперь что-то посложнее, или сам этот класс разросся, добавил функционала и теперь в модель "несколько функций + ISR" не укладывается, хочет процесс. Зачем менять модель работы других с этим делом? Ну стал тот же упомянутый lcd обслуживаться процессом - какое кому дело?
Конечно, можно этому классу lcd в друзья прописать класс "его" процеса, чтобы тот мог использовать недоступные остальным поля да функции, скажем, все могут писать в очередь, а читать - только этот процесс. Или вообще использовать процесс всего лишь как обёртку над функцией выполнения реальной работы из класса, как у Антона. Но какой смысл в двух сущностях, когда она, вообще говоря, одна?
Есть процесс, у него есть "системная" часть, есть связанная с его реальной работой. Всем, кроме системы, видна его "профессиональная деятельность", они к ней обращаются.

Ну вот что-то такое (процессы как наследники базового процесса и нестатическая функция процесса) и я пытался обсуждать.
Хотел причесать думалки и что-то родить для более предметного обсуждения, но заглох - сейчас сам не могу понять, чем занимаюсь, а о сферических конях не хотелось говорить.
Можно ведь и конструктор процесса так организовать, чтобы он в подготавливаемый для первого "вызова" стековый кадр затолкал и саму функцию Exec(), и необходимый для неё this.
В результате, как минимум, обращения к "системным" и "пользовательским" полям процесса смогут идти относительно одного указателя. Что где ещё вылезет - надо смотреть.
Я хотел сначала вникнуть в ту зависшую переделку с TService, потом об этом подумать предметнее, но так и завис :-(

+1
И, возможно, начать с ( {от|в}ключаемого defin-ом или параметром шаблона ) контроля стека - опять таки, пришлось скоприровать шаблон процесса под другим именем и добавить в него такой контроль.

Ага. Не помню уже - с тобой это в аське пару лет назад обсуждал, или на ком-то другом потренировалася, а потом решил не трясти воздух недодуманными мыслями.

Похоже, таки с тобой :-)
Да, взывается осью, и эта Exec() как-то очень похожа на isr() из "класса-драйвера", вызывающуюся аппаратурой.
Но ведь остальные функции класса-драйвера находятся в нём же.
И мне эти вещи (класс-"драйвер" и процесс) кажутся подобными, хоть и на разнх уровнях.

---------------
Тьху, вспомнил - с заталкиванием в образ стекового кадра this и указателя на нестатическую функцию проблема - указатель на функцию-член это не просто указатель на функцию, там и размер другой.
Ох уж этот склероз...



Но всё равно лишний расход стека будет. А вот сразу Exec сюда - увы...

Аналогия, все же, другая. ISR - сам по себе просто функция, которая целиком отдана на откуп пользователю. У нее нет никакого внутреннего представления. Сделать ее частью пользовательского класса имеет смысл потому, что она может "хотеть" иметь доступ к представлению (закрытой части класса) своего класса. Это и является критерием, почему ISR - это часть пользовательского кода. А процесс - это часть ОС, в доступе к его представлению пользовательский код нужды не имеет. И сам процесс не имеет никакой нужды в доступе к потрохам пользовательского кода (классам). Поэтому это сущности ортогональные.

Другая аналогия. Системная функция main - она системный код или пользовательский? Именно сама функция, а не ее потроха. Функция - системная, ее система вызывает, и пользовательский код никак не управляет ее вызовом. Хотя использует ее в своих нуждах. Ровно так же и наши процессы.

Если уж хочется держать процесс вместе с кодом, который его использует, то можно попробовать объект-процесс заводить не в глобальной области видимости, а как член пользовательского класса. Главное, чтобы этот класс был сам в global scope и имел глобальное же время жизни. Ну, и не забыть конструктор процесса вызвать при вызове конструктора объемлющего класса. Я так не делал еще, но на вскидку не вижу препятствий. Это, имхо, будет примерно то, что ты хочешь.

Дык! Давайте займёмся. Я так понимаю, почти у каждого уже есть свой вариант. Осталось только выбрать самый-самый



Опять не согласен. Все функции в конечном счёте вызываются осью. Критерий - кто написал функцию. Пользователь написал - пользовательская функция.
А к чему мы это вообще?



Да, так красивше И - да, дополнительный расход стека всё равно есть.

Постепенно сделаем. Для начала надо определить, что именно нужно мониторить при отладке. Перечень. Второе - канал для мониторинга (терминалка или что еще). Можно в группе тему поднять.

Канал может быть абстрактным классом. Пользователь сам допишет.
А вот мониторить нужно, мне кажется:
а) расход процессорного времени по процессам
б) в ожидании какого сервиса уснул процесс
в) расход стека.
Кому надо что-то еще - дописываем.
Причем надо иметь возможность подключать/отключать каждый из пунктов на этапе компиляции.
пункт б) я использую (правда без вывода, смотрю отладчиком), очень помогает при выяснении "какого черта этот процесс повис".
пункта а) очень не хватает.

Да как-то кисло там. Сообщения то доходят на почту, то теряются. И тут людей больше.

Канал вообще не нужен, имхо. Нужны функции для получения требуемых данных, типа
TBaseProcess.GetFreeStack(), TBaseProcess.GetTimes()... етц. А уж как их вызовет пользователь - его дело.



+1. Ещё и с русскими сообщениями стала какая-то ерунда происходить.

В чем измерять? В тиках системного таймера?


Да, пожалуй надо только сами внутренние средства приделать и интерфейс к ним, а там уж видно будет, как лучше. Можно хоть по отдельности юзать, хоть какой-нить класс монитора написать и подключать к любому доступному каналу.

Возможно. Как вариант - что-то поточнее. Вплоть до тиков таймера, на прерывании которого висит системный таймер. Ибо частенько процесс работает меньше тика системного таймера. Пользователя чаще интересует отношение загрузки между процессами, поэтому размерность не важна.
Самый простой вариант (применялся на моей предыдущей работе в другой операционке) - в прерывании системного таймера инкрементируется счетчик в активном процессе. Раз в несколько сотен прерываний накопленные значения переносятся в результат, счетчики обнуляются. Такой подход не учитывает время, потраченное на прерывания. Для его учета надо вклиниваться в точку переключения процессов и обертку прерываний.

Если какой-то процесс работает малое количество времени, то он вообще может не пересекаться с прерыванием системного таймера, и тогда он будет вообще казаться полностью неактивным. Наверное правильнее всего делать отсечки при переключении контекста - прямо в тактах, которыми тактируется системный таймер (реализация должна быть простой - через считывание значения таймера. Хотя тут есть трудности на некоторых платформах - например, у MSP430 системным таймером удобно взять сторожевого барбоса, а из него значения взять, насколько помню, нельзя ). Для каждой платформы тут должна быть своя функция (в порте), которая возвращает количество тактов (не тиков) частоты, тактирующей системный таймер. Иначе, имхо, смысла мало в таком сервисе.

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

Ну и пусть себе кажется неактивным, счётчик переключений контекста процесса покажет, что это не так. Тут, имхо, важно не переборщить. Размер стека нужно вычислять точно. А количество процессорного времени - всё равно получится приблизительным. Хотя, если в порте доставать тики таймера не накладно, то можно и их конечно

А можно как нибудь код процессов разнести по разным файлам?
У меня файл main.cpp на APM раздулся нешуточно. Уже надоедает его по полчаса листать в поисках процесса.

А что мешает?
Например, выносим процесс TProc1:
Создаём файл proc1.h:

И затем proc1.cpp:

Везде, где надо обращаться к Proc1 - пишем сначала
#include "proc1.h"

Или же, чтобы не запутаться в приоритетах, вынести все объявления процессов в один файл, типа procs.h:


Как-то так.

Спасибо. То, что доктор прописал.

Я пробовал разнести по разным файлам, но у меня компилятор вечно матерился.

ЗЫ: Закоментил в main.cpp namespace OS и все процессы. Вместо этого вставил инклуд #include "process/process.h".

В #include "process/process.h" описания процессов. И дальше в каждом отдельном файле код процесса.
Все компилится но компилятор никак не реагирует на ошибки в коде процесса и не включает этот код в прошивку. Т.е он собирает прошивку без процессов.

Ну, эта проблема уже не связана scmRTOS. Нужно добавить новые *.cpp файлы к проекту, то есть указать компилятору, что их надо тоже компилировать. Способ зависит от компилятора (и IDE).

Подскажите пожалуйста:

Исходные данные. Ядро CortexM3.
scmRTOS_CONTEXT_SWITCH_SCHEME 1

Как передать управление другому процессу без использования SetSleep ?
Получается что процесс с высоким приоритетом не отдает управление
процессу с низким приоритетом.

Вставка SchedISR() в обработчик сис. таймера не помогает.

И правильно. На то у него и более высокий приоритет.

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

жалко что нельзя два и более процесса сделать с одинаковым приоритетом.
Хотелось бы писать допустим чисто интерфейсные процессы, не думая где отдавать управление

При использовании вытесняющей ОС нужно программу строить как управляемую по событиям (event-driven). И интерфейсные процессы отлично ложатся под эту идеологию.

В привычке думать, где отдавать управление, чувствуется опыт работы с кооперативными ОС.
Ломайте привычки, меняйте идеологию.

У меня состоит задача в том, чтобы по запросу возвращать самые актуальные данные. У меня два процесса один постоянно опрашивает датчики, обрабатывает показания записывает их в структуру и отсылает меседж. Второй процесс опрашивает трансивер и если пришел запрос, то проверяет is_non_empty() меседжа, и если там что-то есть, то отправляет данные.

1) Это нормально многократно перезаписывать сообщение не получая его?
2) Процесс может отправить сам себе сообщение? Иногда такое, тоже требуется.
3) Используя is_non_empty(), нужно ли потом вручную вызывать reset()?
4) При использовании wait() флаг наличия сообщения сбрасывается сам?

Можно, только прежние тела сообщения будут затёрты. Насколько это вас устраивает, я не знаю.


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


Можно. Почему нельзя?


А в исходник посмотреть?
Если на момент посылки уже были ожидающие процессы, то флаг наличия и не будет установлен, ибо незачем.

Мне не нужны старые данные. Поэтому вариант с затиранием подходит. Интересовало насколько это корректно.

Отсылать самому себе сигнал очень удобно в следующей ситуации.
Есть два процесса. Процесс 1 производит опрос, Процесс 2 управляющий.
При старте системы Процесс 1 в начале цикла ожидает флаг, Процесс 2 устанавливает флаг тем самым разрешая опрос. После успешного опроса Процесс 1 выставляет сам для себя флаг, если опрос был не успешен то он отправляет месседж с ошибкой и не выставляет флаг. Тем самым Процесс 1 в случае ошибке уснет, пока Процесс 2 не решит, что с ним делать.
Интересовало насколько это корректно.

Насчет месседжей я спрашивал другое. Если я использую is_non_empty(), то при получении сообщения я не нашел места где флаг сбрасывается. А значит нужно вызывать сброс вручную?

А в случае с wait() как я понимаю флаг будет сброшен сам и вызове reset() нет необходимости? В документации не написано в каких ситуациях флаг сбрасывается. На этот вопрос уже нашел ответ. Флаг сбрасывается.

Не очень понял, какой флаг имеется в виду. Флаг события (TEventFlag) или внутренняя переменная message NonEmpty? Лучше такие вещи пояснять на примере псевдокода.


Получение сообщения производится в функции wait(). Там же и обрабатывается внутренняя переменная (NonEmpty). Эта переменная устанавливается при передаче только если в этот момент никто не ждёт сообщения (тогда при первой попытке встать на ожидание процесс "увидит", что сообщение уже лежит, и его можно использовать). Если же есть ожидающие процессы, то NonEmpty не устанавливается, т.к. в этом нет необходимости - просто процесс, который находился в ожидании, будет переведён в готовые к выполнению.

Следует иметь в виду, что внутренняя переменная NonEmpty - это не флаг-признак наличия сообщения. Это именно внутренняя переменная, используемая потрохами сервиса для своих служебных целей, поэтому ориентироваться на неё не следует. Работать нужно с интерфейсом - открытыми функциями-членами. Если приём сообщения осуществляется с помощью is_non_empty() (что правильнее назвать не приёмом, а проверкой наличия), то, конечно, и сброс состояния тоже придётся делать вручную.


В документации описано функционирование с точки зрения интерфейса сервиса. А работа с NonEmpty - это уже детали реализации, они, конечно, как обычно, не являются предметом документирования. Детали реализации вообще могут меняться вполне произвольно, при сохранении интерфейса класса и логики его работы работы, поэтому ориентироваться на них не надо.

Если требуется конечный автомат, то можно флаг заменить на месседж.


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

Это получается более корректно и правильно написать так


Чем так

Я бы сделал так.




Конечно. Это и есть штатный и основной способ использования. Ждём сообщения, дождались - обрабатываем. А is_non_empty(), reset() - это вспомогательные фукнции

Этот код получше. До такого я не додумался))

Через неделю планирую начать проект на STM32W
Под STM32 есть порт версии 3.10. А как обстоят дела с версией 4.0 ? Порт по идее есть, но он стабилен? Имеет смысл его использовать в проекте?

scmRTOS версии 4 и порт для Cortex-M3 (без разницы какой конкретно контроллер) под нее вполне стабильны.
Здесь можно скачать scmRTOS и порт версии 4.
Здесь и здесь документация.

За доку на кортексы спасибо. О ее существовании даже не знал.

Заметил, что в 4 версии для cortex-m3 есть файлик startup.c. Хотя в тоже время имеется "\STM32\STM32F10x_StdPeriph_Lib_V3.5.0\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x\startup\arm" тоже самое только на ассемблере.
Почему не используется ассемблерная версия?

Также в примерах содержаться файлы core_cm3.h и stm32f10x.h которые тоже содержаться STM32F10x_StdPeriph_Lib_V3.5.0.
Зачем их добавлять в примеры?

Настроил отладчик ST-Link (использую дисковери) как написано в статье http://we.easyelectronics.ru/STM32/otladka...eclipsegcc.html .
В проектах без ОС отладка работает.
А вот с ОС неработает. Зависает здесь


или



Хотя проект рабочий и я вижу как плата мигает диодами.

Где "имеется"?
Дело в том, что в то время, когда создавался порт, в составе CMSIS не было ассемблерных стартапов. Да и нынешние - не будут работать с C++.
К тому же, версии библиотек от ST имеют нехорошую тенденцию меняться в самый неподходящий момент. Поэтому в состав примеров были включены нужные для работы примеров файлы. Обратите внимание, для собственно ОС эти файлы не нужны, порт - универсален для любых Cortex-M3.

Про отладку не подскажу, - не знаю.

Ну почему-же, будет работать. Там немного нужно поправить названия функций.

С вашей версией выходит


с версией от STM


Но один фиг отладчик не работает.

Компилируется != работает
В том варианте startup_stm32f10x_xx.s, что есть у меня (V3.3.0), не вызываются конструкторы глобальных объектов. Хотя может сейчас уже поправили...

Уже вышла версия 3.5.

Также нашел объяснение с отладкой


Сделал так но результата не дало.
#define OS_INTERRUPT extern "C"

Начал копаться в sysinit.cpp. Читабельность оставляет желать лучшего.



От таких конструкций мозг закипает. Такое намного проще и удобней разбить на несколько команд. При этом возрастет читабельность.

Также в этом файле нашел следующее


Но в ACR есть всего один бит и эта конструкция его никак не трогает.
Нажмите для просмотра прикрепленного файла

Также у value line потолок 24 Mhz. Отсюда вопрос. Что это такое?

И? Есть там вызов конструкторов?

Попробуйте просто написать extern "C" перед функцией обработчика прерывания.

Так разбейте, какие проблемы? Примеры - это же не догма, а лишь руководство к действию

Видите первую строчку? Эта часть - не для value line.