Вы понимаете, надеюсь, что на место параметра exec в дальнейшем при переключении процессов будет писаться адрес возврата в прерванный процесс? Соответственно, this->(адрес чего-то там) никак не укладывается в размерность "чего-то там". А exec за счет своего static - укладывается, да еще и существует в единственном виде.

Про автоматическое присвоение приоритетам по мере объявления. Это могло бы автоматически решить проблему "бездырности" приоритетов в переменной, где устанавливаются/сбрасываются единички активных процессов. Одна из видимых проблем - pridle - намертво зашитый в enum. Понятно, что можно все тексты scmRTOS таскать вместе с проектом, но вы же исходники Windows/Linus и прочего в таком виде не используете? Вот и мне также хотелось бы иметь только библиотеки от scmRTOS, ну за вычетом inline и template, которые ну просто никак по-другому (пока, по крайней мере).

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

Это другое дело, тут я не прав
(::*)() имеет более сложную структуру, чем (*)(), там наворочено на случай наследования/виртуальных и эта гадость не приводится ни к void* и к чему другому и просто так вызвать не получится.
Так что если хочется сделать реальную функцию процесса нестатической, то нужно просто статический exec сделать принимающим указатель на объект класса (записывать в стековый кадр на нужное место this) и в самом exec() так

Если сделать execute() ещё в TBaseProcess и сделать её виртуальной, то тогда можно прямо TBaseProcess* сделать аргументом Exec. Но это лишние расходы.
А вот сделать Exec принимающим void*, добавить аргумент void *pросdata=0 в конструктор TBaseProcess и в шаблон процесса - практически ничего не требует дополнительного и, пожалуй, будет совместимо с уже написанным кодом. И иногда может быть удобным, по крайней мере если захочется из TBaseProcess вывести свой тип процесса и создать два экземпляра процесса. Но то же самое и со столь же небольшими расходами (хотя по ОЗУ вопрос - надо смотреть) можно сделать, создав два разных процесса "как оно сейчас" и сделав

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

Со сравнением с тасканием исходников "больших" ОС не согласен - эти ОС запускают отдельно скомпилированные процессы, долинковывая их к себе при запуске. И такая универсальность тянет за собой дополнительные расходы.
От scmRTOS пока такого (к примеру, загрузки процесса по каналу связи или из воткнутой флешки) никто не требует, а если потребует, то она станет гораздо менее "scm-ной".
Она в существенной мере инлайнится в пользовательское приложений - ну положите Вы объектные модули, по .cpp и .S от scmRTOS уже "никто не потопчется" ценой роста размера таблиц. Но существенная часть кода ОС всё равно находистя в .h-файлах и с "нетоптанием" по ним всё равно придётся работать "административно" а не "языково".
"За что боролись?"

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

Помогите, пожалуйста, побороть ошибки (на первой странице)!
У вас тут такие разговоры пошли... я ничего не понимаю...

Про счетчик команд процесса. Может вы просто неудачно это называете. Это ведь просто значение регистра адреса команд. Правильнее было бы говорить про стартовый адрес процесса в начале, и текущий (прерванный) адрес процесса.

Что-то мне казалось, что с включением текущей папки проекта в пути поиска все эти undefined reference должны были уйти.

Но не ушли...
А чтобы ушли, надо было в мой проект Code::Blocks добавить файлы ОС OS_Target_cpp.cpp, OS_Target_asm.S, OS_Kernel.cpp, OS_Services.cpp, usrlib.cpp.

Я их не включил в проект, наивно полагая, что C::B или компилятор их сами включат...

Вы должны раз и навсегда запомнить. Вы пишете программу, а не IDE и всякие там С::B и прочие. Что вы в проект сами включите, то и получите.

Вот по поводу этого объясните, ещё пожалуйста:



Зачем namespace, template?
На страницах 21, 27, 103-104 руководства процесс оформлен более просто... почему?

Сообщение отредактировал n_bogoyavlensky - May 17 2009, 11:57

На 21 стр. - "скелет" функции. Собственно вызов (имя) и иллюстрация того, что процесс, как минимум, бесконечный цикл.

На 103-104 стр. - реальный пример.

Да я это-то понял давно!
Я не понял почему в этом примере (стр. 103-104) "namespace OS" и "template<>" перед функциями процессов не поставлены, а в примерах из дистрибутива ОС - поставлены.
Почему?

Текущая верия scmRTOS? - 3.05

А документация писалась под 2.хх. C тех пор много воды утекло.

Потому что gcc 4.x несколько строже к этому всему относится и требует, чтобы Exec() определялся в том же namespace, в котором он был объявлен (в файлах ОС). С template<> аналогичная петрушка - все параметры шаблона уже "специализированы", свободных не осталось, но Exec() - часть шаблона, поэтому gcc просит template<>
IAR обходится без этого, а документация писалась автором оси по итогам IAR-вского варианта.

Не вникал дотошно в стандарт - толи IAR даёт тут некоторое послабление относительно стандарта, толи gcc относится несколько прямолинейнее, чем нужно, но это в конечном итоге и неважно.
А в стандарте в примерах такие же template<> с пустыми уголками.

По поводу включения осевых .cpp в проект - ни среда ни компилятор действительно от себя ничего не включают.
Так или иначе это нужно указать, в примерах к варианту avr-gcc просто в makefile сделаны правила "включать всё, что есть в указанных каталогах - проекта (текущий) и scmRTOS/Common scmRTOS/AVR". И make находит нужное и включает в команды для компилятора.

ReAl

Понятно.
Вот спасибо
И за avreal32.exe спасибо (если я не ошибаюсь)

А ссылочку на стандарт можно?

Сообщение отредактировал n_bogoyavlensky - May 17 2009, 15:15

Google-> "c++ standard". Первая же ссылка.

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


Ну, а про автоматическое присваивание приоритетов - а если процессы объявлены в разных файлах? Тут зависимость от порядка объявления возникнет. 

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