Раз в Common/ , то это не в порте, а в ОС, в ее общей части. Только это не опечатка, а багфикс.


Когда-то было как раз так, как Вы предлагаете.

Теперь берём процесор с 16-битным int (MSP430, AVR, STM8) и берём, например, 17 процессов (вместе с idle).
Сдвигаем 1-ку, которая без суффикосв имеет тип int, на 17 бит. Получаем 0. Вычитаем 1, получаем -1 (типа int).
Как оно теперь приведётся к 32-битному TProcessMap, как 0xFFFFFFFF или как 0x0000FFFF — не важно, ведь нужно было 0x0001FFFF

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

При портировании по Вашему сценарию авторам придет портировать не только аппаратно-зависимую часть, но и программно-зависимую от int, char и т.д.
Аппаратно-зависимая часть сейчас в соответвтующем порте для процессора (Ports: OS_Target.h OS_Target_asm.S OS_Target_cpp.cpp) уже сделана.
Осталась программная часть: (Common ) OS_Kernel.cpp OS_Kernel.h OS_Services.cpp OS_Services.h scmRTOS.h scmRTOS_310_compat.h scmRTOS_defs.h usrlib.cpp usrlib.h и (Extensions ) profiler.h . Вроде ничего не забыл.
То есть ВСЕ и с учетом компилятора! Все надо отдельно отладить и поддерживать.

Код непереносимый получится. Пожалейте авторов! Они сделали большую работу очень качественно и бесплатно для пользователей.

P.S. Всегда считал, что писать переносимый код это хороший тон .

(выделение моё)
Это Вы о stdint.h ? Ну тогда, к примеру, #include <stdio.h> — это "подключать какие-то свои функции"
Кстати, если я не ошибаюсь, stdint.h, существующий в С начиная с C99, наконец-то вошёл в C++11


Я не помню, почему сделали не приведение к TProcessMap, а просто 1ul. Тогда в рассылке проскочило, быстренько обсудили, было исправлено в pre-v400. А я как раз в те дни что-то у себя менял, ну заодно и это исправил в 3.10.

Добавлено:
Ха! Так я сначала и хотел (TProcessMap)1
Смотрим рассылку (там, правда, часть покоцана в кодировках), ближе к концу — обсуждаемое.
Почему не (TProcessMap)1:
Надо было вообще ULL с запсом, чтобы позже нарваться на ненужное предупреждение.
Пусть 7 процессов и IDLE, итого 8. TProcessMap 8-битный. Сдвигаем (TProcessMap)1 на 8 и выходим за границы типа TProcessMap.
Результат будет всё равно правильный, но компилятор ворчит, лишние предупреждения в выдаче маскируют нелишние и вообще подстрекают снизить уровень ворчливости компилятора.

Да, теперь все ясно.

Получается, что в текущем варианте можно использовать не более 31 задачи, включая Idle (т.к. 1UL) для платформ разрядностью 32 включительно.

Обработчик прерывания PendSV порта scmRTOS для Cortex-M3.

Да. Об этом написано в документации в самом начале главы 2.1. "Общие сведения":
и в комментариях исходников рядом со строкой задания количества процессов:

Зануда:
А в документации страницы с 115 по 118, 120, 122, 124, 126, 128, 130 и 132 не нумерованы (версия 29.03.2003 – 29.12.2011)

Тактов 300 с чем-то, но при полном запрете прерываний.
70 гораздо лучше.


Удобная штука. DWT только у M3 есть или у всех?

Получилось ~200 тактов от засыпания одной задачи до запуска другой.

Теперь уже 60

Насколько я смог понять, у M3 и M4(F). У остальных что-то не видно.

Да, это хорошо согласуется с моими измерениями (2.7мкс / 2.55 мкс).

Спасибо. Теперь сравните со времнем реакции задачи, если бы она синхронизировалась напрямую от прерываний периферии и ее exec() находился бы внутри ISR. По моему, небо и земля. А если учесть, что в современных МК периферия работает с памятью по DMA, то вообще- OS по старинке отдыхает.


Я испытываю глубочайшее и искреннее уважение к авторам scmRTOS. И прежде всего потому, что сваяли вещь на С++, в то время как остальные тянут С. Как прикладник, я очень понимаю, сколь хорошо и надежно один раз создать и отладить класс, а потом наплодить на его основе много однотипных обьектов. Только поэтому и обратил внимание на scmRTOS, думал- вот оно! Но оказалось, что авторы, сделав грандиозный скачок в программировании, одновременно сделали и два, не менее грандиозных шага назад, в прошлый век,- по хардверу. Работая на передовом C++, они ориентируются на мелкие, примитивные микроконтроллеры, которые сейчас и найти-то стало трудно на рынке. Используют темплейты языка C++ для отживших свой век АVR! Честно скажу - уму нерастяжимо. Давно прошло то время, когда надо было влезать в узкие ворота ограниченных ресурсов процессора. Сейчас за те же деньги и при тех же габаритах юзер имеет возможность использовать чипы, сравнимые с ПК. Но авторы по-прежнему считают доблестью сохранить совместимость с устаревшими моделями. Причем, в ущерб своему же творению, его тянет назад груз прошлого, тормозит развитие. Извините, я этого понять не в состоянии.

У меня сложилось впечатление, что вы влезли в эту радостную тему с единственной целью - попонтоваться. К сожалению, получилось не очень, уровень не тот. Претензии к stdint.h выглядят просто жалко, а остальное - вообще какой-то поток сознания. Вы уж извините меня за прямоту.
Я думаю, что вам придётся писать свою ось. С unsigned int вместо uint32_t, и чтоб "задачи синхронизировались напрямую от прерываний периферии". Потому что scmRTOS - не такая, и такой не будет.
Чтож, желаю вам успехов в этом деле.

Ну извините, не угодили использующим исключительно "профессинальные контроллеры" с переднего края полета мысли контроллеростроителей. Когда будем делать следующую ОСь, мы вас спросим, для каких контроллеров ее делать и главное, для каких ее делать не нужно.

Aprox, Вас ни кто не заставляет использовать эту ОС.
Если Вас не устраивает сделанное кем-то, то сделайте свое и выложите для всех. Можно будет сравнить результаты.
ОС имеется множество, как и задач. Авторы scmRTOS позиционировали сферу применения (см. документацию).


Просветите, пожалуйста, какие это чипы. Возможно, я отстал от жизни.

Спасибо за замечание! Слетел стиль страницы в конце раздела. Поправлено.



Этта пять!



+1.