[ReAl 0]

Найдена опечатка в порте AVR, Common/OS_Kernel.h

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

------------------------------------------------------------------------

r396 | avreal | 2011-04-27 20:09:07 +0300 (ср, 27 кві 2011) | 2 lines

 

v3.10: Common: fixed bug at ReadyProcessMap initializing.

------------------------------------------------------------------------

r389 | harry_zhurov | 2011-04-19 06:01:20 +0300 (вт, 19 кві 2011) | 1 line

 

Common: fixed bug at ReadyProcessMap initializing.

 

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

 

Должно быть:

public:
    INLINE TKernel() : CurProcPriority(pr0)
                     , ReadyProcessMap( (1 << (PROCESS_COUNT)) - 1)  // set all processes ready
                     , ISR_NestCount(0)
    {
    }

Теперь берём процесор с 16-битным int (MSP430, AVR, STM8) и берём, например, 17 процессов (вместе с idle).

Сдвигаем 1-ку, которая без суффикосв имеет тип int, на 17 бит. Получаем 0. Вычитаем 1, получаем -1 (типа int).

Как оно теперь приведётся к 32-битному TProcessMap, как 0xFFFFFFFF или как 0x0000FFFF — не важно, ведь нужно было 0x0001FFFF

[mdmitry 0]

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

Вот видите, сколько ненужных заморчек вы навешиваете на юзера вашей OS? И stdint.h подключи, и вызубри его обозначения, и нужный редактор текста найди...

 

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

 

При портировании по Вашему сценарию авторам придет портировать не только аппаратно-зависимую часть, но и программно-зависимую от 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. Всегда считал, что писать переносимый код это хороший тон :rolleyes: .

[ReAl 0]

Но ни разу в голову не пришло подменять стандартные ключевые слова языка C++ на какие-то свои обозначения.

(выделение моё)

Это Вы о stdint.h ? Ну тогда, к примеру, #include <stdio.h> — это "подключать какие-то свои функции"

Кстати, если я не ошибаюсь, stdint.h, существующий в С начиная с C99, наконец-то вошёл в C++11

 

 

наверное правильнее (красивее) будет

                     , ReadyProcessMap( ((TProcessMap)1 << (PROCESS_COUNT)) - 1)  // set all processes ready

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

 

Добавлено:

Ха! Так я сначала и хотел (TProcessMap)1

Смотрим рассылку (там, правда, часть покоцана в кодировках), ближе к концу — обсуждаемое.

Почему не (TProcessMap)1:

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

Пусть 7 процессов и IDLE, итого 8. TProcessMap 8-битный. Сдвигаем (TProcessMap)1 на 8 и выходим за границы типа TProcessMap.

Результат будет всё равно правильный, но компилятор ворчит, лишние предупреждения в выдаче маскируют нелишние и вообще подстрекают снизить уровень ворчливости компилятора.

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

Сдвигаем (TProcessMap)1 на 8 и выходим за границы типа TProcessMap

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

[mdmitry 0]

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

 

[AHTOXA 18]

Уточните пожалуйста, имеется в виду "обработчик" от scmRTOS со всеми его полингами или чистую реакцию процессора на прерывание по вектору SW?

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

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

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

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

ОС поддерживает до 32 процессов (включая системный процесс IdleProc, т.е. до 31 пользовательского процесса),

и в комментариях исходников рядом со строкой задания количества процессов:

//------------------------------------------------------------------------------
//
//    Specify scmRTOS Process Count. Must be less than 31
//
//
#define  scmRTOS_PROCESS_COUNT              3

 

[mdmitry 0]

Зануда:

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

[Артём__ 0]

Ну, у АВР всё подольше будет, да. У него обработчик PendSV выполняется ~70 тактов (менее микросекунды на 72 МГц).

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

70 гораздо лучше.

 

У кортексов я засекал при помощи DWT. (Обнаружил при этом способ сократить PendSV до 60 тактов:) )

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

 

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

 

[AHTOXA 18]

70 гораздо лучше.

Теперь уже 60 :08:

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

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

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

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

[aprox 0]

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

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

 

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

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

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

 

[AHTOXA 18]

OS по старинке отдыхает.

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

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

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

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

Работая на передовом C++, они ориентируются на мелкие, примитивные микроконтроллеры, которые сейчас и найти-то стало трудно на рынке. Используют темплейты языка C++ для отживших свой век АVR!

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

 

[mdmitry 0]

Aprox, Вас ни кто не заставляет использовать эту ОС.

Если Вас не устраивает сделанное кем-то, то сделайте свое и выложите для всех. Можно будет сравнить результаты.

ОС имеется множество, как и задач. Авторы scmRTOS позиционировали сферу применения (см. документацию).

 

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

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

[dxp 65]

Зануда:

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

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

 

 

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

Этта пять! :a14:

 

 

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

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

+1.