ReAl 0 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Найдена опечатка в порте 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 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба А юзеру -просто почитать мануал на компилятор для своей платформы. В целом, задача сделать универсальную 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 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Но ни разу в голову не пришло подменять стандартные ключевые слова языка 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. Результат будет всё равно правильный, но компилятор ворчит, лишние предупреждения в выдаче маскируют нелишние и вообще подстрекают снизить уровень ворчливости компилятора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Сдвигаем (TProcessMap)1 на 8 и выходим за границы типа TProcessMapДа, теперь все ясно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Получается, что в текущем варианте можно использовать не более 31 задачи, включая Idle (т.к. 1UL) для платформ разрядностью 32 включительно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Уточните пожалуйста, имеется в виду "обработчик" от scmRTOS со всеми его полингами или чистую реакцию процессора на прерывание по вектору SW? Обработчик прерывания PendSV порта scmRTOS для Cortex-M3. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Получается, что в текущем варианте можно использовать не более 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 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Зануда: А в документации страницы с 115 по 118, 120, 122, 124, 126, 128, 130 и 132 не нумерованы (версия 29.03.2003 – 29.12.2011) :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Артём__ 0 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Ну, у АВР всё подольше будет, да. У него обработчик PendSV выполняется ~70 тактов (менее микросекунды на 72 МГц). Тактов 300 с чем-то, но при полном запрете прерываний. 70 гораздо лучше. У кортексов я засекал при помощи DWT. (Обнаружил при этом способ сократить PendSV до 60 тактов:) ) Удобная штука. DWT только у M3 есть или у всех? Получилось ~200 тактов от засыпания одной задачи до запуска другой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба 70 гораздо лучше. Теперь уже 60 :08: Удобная штука. DWT только у M3 есть или у всех? Насколько я смог понять, у M3 и M4(F). У остальных что-то не видно. Получилось ~200 тактов от засыпания одной задачи до запуска другой. Да, это хорошо согласуется с моими измерениями (2.7мкс / 2.55 мкс). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aprox 0 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Обработчик прерывания PendSV порта scmRTOS для Cortex-M3. Спасибо. Теперь сравните со времнем реакции задачи, если бы она синхронизировалась напрямую от прерываний периферии и ее exec() находился бы внутри ISR. По моему, небо и земля. А если учесть, что в современных МК периферия работает с памятью по DMA, то вообще- OS по старинке отдыхает. .. Пожалейте авторов! Они сделали большую работу очень качественно и бесплатно для пользователей. P.S. Всегда считал, что писать переносимый код это хороший тон :rolleyes: . Я испытываю глубочайшее и искреннее уважение к авторам scmRTOS. И прежде всего потому, что сваяли вещь на С++, в то время как остальные тянут С. Как прикладник, я очень понимаю, сколь хорошо и надежно один раз создать и отладить класс, а потом наплодить на его основе много однотипных обьектов. Только поэтому и обратил внимание на scmRTOS, думал- вот оно! Но оказалось, что авторы, сделав грандиозный скачок в программировании, одновременно сделали и два, не менее грандиозных шага назад, в прошлый век,- по хардверу. Работая на передовом C++, они ориентируются на мелкие, примитивные микроконтроллеры, которые сейчас и найти-то стало трудно на рынке. Используют темплейты языка C++ для отживших свой век АVR! Честно скажу - уму нерастяжимо. Давно прошло то время, когда надо было влезать в узкие ворота ограниченных ресурсов процессора. Сейчас за те же деньги и при тех же габаритах юзер имеет возможность использовать чипы, сравнимые с ПК. Но авторы по-прежнему считают доблестью сохранить совместимость с устаревшими моделями. Причем, в ущерб своему же творению, его тянет назад груз прошлого, тормозит развитие. Извините, я этого понять не в состоянии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба OS по старинке отдыхает. У меня сложилось впечатление, что вы влезли в эту радостную тему с единственной целью - попонтоваться. К сожалению, получилось не очень, уровень не тот. Претензии к stdint.h выглядят просто жалко, а остальное - вообще какой-то поток сознания. Вы уж извините меня за прямоту. Я думаю, что вам придётся писать свою ось. С unsigned int вместо uint32_t, и чтоб "задачи синхронизировались напрямую от прерываний периферии". Потому что scmRTOS - не такая, и такой не будет. Чтож, желаю вам успехов в этом деле. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Работая на передовом C++, они ориентируются на мелкие, примитивные микроконтроллеры, которые сейчас и найти-то стало трудно на рынке. Используют темплейты языка C++ для отживших свой век АVR!Ну извините, не угодили использующим исключительно "профессинальные контроллеры" с переднего края полета мысли контроллеростроителей. Когда будем делать следующую ОСь, мы вас спросим, для каких контроллеров ее делать и главное, для каких ее делать не нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 11 апреля, 2012 Опубликовано 11 апреля, 2012 · Жалоба Aprox, Вас ни кто не заставляет использовать эту ОС. Если Вас не устраивает сделанное кем-то, то сделайте свое и выложите для всех. Можно будет сравнить результаты. ОС имеется множество, как и задач. Авторы scmRTOS позиционировали сферу применения (см. документацию). Сейчас за те же деньги и при тех же габаритах юзер имеет возможность использовать чипы, сравнимые с ПК. Но авторы по-прежнему считают доблестью сохранить совместимость с устаревшими моделями. Причем, в ущерб своему же творению, его тянет назад груз прошлого, тормозит развитие. Извините, я этого понять не в состоянии. Просветите, пожалуйста, какие это чипы. Возможно, я отстал от жизни. :crying: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 12 апреля, 2012 Опубликовано 12 апреля, 2012 · Жалоба Зануда: А в документации страницы с 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться