[aprox 0]

У меня сложилось впечатление, что вы влезли в эту радостную тему с единственной целью - попонтоваться. К сожалению, получилось не очень, уровень не тот. Претензии к stdint.h выглядят просто жалко, а остальное - вообще какой-то поток сознания. Вы уж извините меня за прямоту.

Я думаю, что вам придётся писать свою ось. С unsigned int вместо uint32_t, и чтоб "задачи синхронизировались напрямую от прерываний периферии". Потому что scmRTOS - не такая, и такой не будет.

Чтож, желаю вам успехов в этом деле.

Дело закончилось обидами. А ведь я хотел как лучше! Чтобы отличная задумка авторов не отставала бы от времени, от прогресса в хардвере микроконтроллеров. Но раз обиделись, зачит чувствуете свою неправоту. Что же касается "придется писать собственную OS"- нет не придется. Ибо не вижу жгучей необходимости.

 

[lotor 0]

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

Остается искренне порадоваться, что вы идете в ногу "с прогрессом в хардвере микроконтроллеров". %)

[MrYuran 34]

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

ScmRTOS изначально задумывалась как легковесная ось для "тонких" контроллеров с 512Б ОЗУ.

Для "переднего края хардверного фронта" есть другие.

А авторы, прежде всего, разрушили два расхожих мифа: что операционкам, и тем более на с++, в мелкоте типа AVR и MSP430 не место.

За что им заслуженный респект.

[viterra 0]

Дело в том, что с типами данных действительно БЕДА.. Нестандартные размерности char, int как правило, действительно бесят, вынуждая программистов вытворять финты ушами. С этим ничего не сделаешь. Обижаться или придираться по этому поводу - бессмысленно. Приходится приспосабливаться к тому что есть.

[aprox 0]

ScmRTOS изначально задумывалась как легковесная ось для "тонких" контроллеров с 512Б ОЗУ.

Для "переднего края хардверного фронта" есть другие.

Да, наверное есть, но программирование в системе реального времени на С++ я лично не встречал.

А авторы, прежде всего, разрушили два расхожих мифа: что операционкам, и тем более на с++, в мелкоте типа AVR и MSP430 не место. За что им заслуженный респект.

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

 

[IgorKossak 1]

Хочется надеяться, что на том и порешили.

Дальше, если можно, по делу.

[Nixon 7]

Хотелось бы в рантайме иметь возможность определения типа контроллера на котором работает scmRTOS (хотя бы один байт). Чтобы не плодить плагины для IAR под разные типы контроллеров.

[mdmitry 0]

Хотелось бы в рантайме иметь возможность определения типа контроллера на котором работает scmRTOS (хотя бы один байт). Чтобы не плодить плагины для IAR под разные типы контроллеров.

Тип контроллера задается при сборке (или его можно как define задать) и использовать в коде. Задать статическую переменную и её использовать по своему усмотрению (иногда надо было). Это же не связано с RTOS.

Или я вопроса не понял?

[Сергей Борщ 186]

Хотелось бы в рантайме иметь возможность определения типа контроллера на котором работает scmRTOS (хотя бы один байт). Чтобы не плодить плагины для IAR под разные типы контроллеров.

Что мешает этот байт вставить в прошивку в виде константы и считывать ее из памяти контроллера плагином?

 

[Nixon 7]

Все правильно, но из плагина я читаю переменную или по имени или по адресу. Второе делать постоянным (для плагина) нет возможности, а первое делать постоянным лучше внутри OS.

[Артём__ 1]

Все правильно, но из плагина я читаю переменную или по имени или по адресу. Второе делать постоянным (для плагина) нет возможности, а первое делать постоянным лучше внутри OS.

А о каких плагинах речь?

[aprox 0]

Дальше, если можно, по делу.

А по делу, - хочется видеть в составе scmRTOS класс задач, которые умеют ожидать настоящие прерывания от периферии. Безумный вариант через SW не предлагать. Еще хочется видеть эти прерывания вложенными по приоритету, т.е никаких запретов на время исполнения ISR. Видите, как просто -хочется, чтобы C++ наконец-то заработал на современных чипах.

 

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

[IgorKossak 1]

А по делу, - хочется видеть в составе scmRTOS класс задач, которые умеют ожидать настоящие прерывания от периферии. Безумный вариант через SW не предлагать. Еще хочется видеть эти прерывания вложенными по приоритету, т.е никаких запретов на время исполнения ISR.

Один из моих бывших коллег, мельком взглянув на эту ОС сразу же от неё отказался, т. к. у неё, видите ли, количество процессов всего 32, а ему надо было больше сотни. То, что он просто не умеет грамотно спланировать программу в расчёт не принималось. Этакий вариант "перепланирование не предлагать".

У меня к Вам встречный вопрос - а на фейхуа оно надо? За более чем шестилетний срок работы с этой ос с первой её версии и реализованную массу проектов у меня такого пожелания не возникло.

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

Видите, как просто -хочется, чтобы C++ наконец-то заработал на современных чипах.

Я вижу то, что Ваше пожелание никоим образом C++ не касается.

[MrYuran 34]

А по делу, - хочется видеть в составе scmRTOS класс задач, которые умеют ожидать настоящие прерывания от периферии. Безумный вариант через SW не предлагать.

А вы сами как это себе представляете?

Задача, целиком размещенная в обработчике прерывания?

По-моему, это будет уже совершенно другая система со своей идеологией.

[ReAl 0]

А вы сами как это себе представляете?

Я думаю — никак. Иначе уже хотя бы какой-то конструктив проскочил. В виде «высокоуровневого» (на человеческом языке) описания происходящих процессов.

 

Задача, целиком размещенная в обработчике прерывания?

Не, это будет то, что тут сказано — задача, спрятанная в обработчик целиком. А не ожидающая "настоящие прерывания".

Если я правильно понял многократно повторенное желание — то-то в духе того, что можно сейчас сделать путём:

 

OS::TEventFlag ef;

template<> void TProc1::exec()
{
    ...
    ef.wait();
    ...
}

OS_INTERRUPT void SomeISR()
{
    OS::TISRW isrw;
    ef.signal_isr(); // и больше тут ничего, к аппаратуре будет обращаться сама задача
}

Но только чтобы это было без этой SomeISR(). Вот как только аппаратное прерывание возникло, так с точки за ef.wait() и продолжить. А как в другом месте поднимется флаг прерывания, кторого ждёт более приоритетный процесс, так чтобы так же без отдельного обработчика и флага сразу туда. А если менее приоритетный, то чтобы «оно» ждало.

Я не могу понять

• Причём к этой хотелке фраза "C++ наконец-то заработал на современных чипах" (если бы такое можно было сделать, то это можно было бы и на С)
• Чем так кардинально отличается Cortex-M3 или там ARM9 от AVR или MSP430, что в нём уже можно это сделать. На мой взгляд, такая хотелка подразумевает аппаратную реализацию планировщика ОС и переключения контекста, всё остальное по реально происходящим действиям (вход в ISR, отмашка конкретного события и отметка задачи как готовой к исполнению, перепланирование и переключение консткста) и временам (отрабатываемым инструкциям процессора) практически не будет отличаться от приведенного выше примера с вырожденным обработчиком прерывания, даже если при помощи каких-то языковых или внеязыковых средств визуально оно будет выглядеть без такого вырожденного обработчика и с каким-то OS::Wait(TIMER1_IRQ); в коде процесса.

Повторюсь — с точки зрения хотелки, если я её правильно понял, все используемые нами микроконтроллеры одинаковые (ну некоторые не имеют приоритетной системы прерываний). Это где-то в районе могилы iAPX 432 копать надо.