Мой вопрос: ссылка
Переношу приложение написанное для v310 в 400. В ходе процесса возникают вопросы и тп.


Я думал, что если использовать режим совместимости с 310 (scmRTOS_OBSOLETE_NAMES 1), то в 4-й версии также должен быть определёны TBaseProcess::Exec, RaiseContextSwitch и тп (появляющиеся если scmRTOS_OBSOLETE_NAMES=1). Но они не определены...
Вот мне и непонятно - это неточности/ошибки/недоделки или что.

Да, я не обратил внимания на предысторию вопроса.

Скорее всего - всё вместе.
Когда у меня встала задача переносить проект на четвёртую версию, то я просто сделал рефакторинг имён по всему проекту (благо в Eclipse это просто, заняло несколько минут) и не заморачивался с OBSOLETE_NAMES.

+ещё мое слабое знание scmrtos.


Рефакторинг - тоже вариант. Но я лучше с OBSOLETE_NAMES помучаюсь.

Спасибо.

Это так и задумано. Там, где возможно - старые места определены. К сожалению, определение имен Exec потребовало бы щедро усыпать код различными #ifdef. Поэтому было принято решение возложить на пользователя обязанность переименовать в своем коде Exec в exec.

Ясно. Спасибо.
Буду менять E на е.



А об этом где-то написано?
Может есть кaкой-то Migration tutorial?

Пока полз до компьютера, объяснение уже дал Сергей. Более развёрнуто:
Режим совместимости включает генерацию inline-функций-переходников в две стороны:
Со старых имён функций классов ОС на новые — чтобы пользовательский код мог продолжать вызывать, например, .Wait()
С новых имён задаваемых пользователем функций (хуки, тот же raise_context_switch()) на старые — чтобы ОС увидела эти функции в старых текстах.

Благодаря переходникам работают и старые, и новые имена, можно потихоньку редактироввть текст и после каждого изменения все будет собираться.

В случае с exec() добавлением inline-переходника не обойтись, нужно «честное имя» (адрес).
В итоге два варианта - ifdef-ить эти места в ОС либо пользователю отредактировать эти имена.
Решили остановиться на втором — этих Exec() немного в каждом проекте и автору точно известно где их искать.

Где почитать — ну можно там же, в main.cpp, ссылку Вы тут сами дали:

Конечно, какой-нибуть мигратинг-гад.pdf не помешал бы...
Ну вот если бы к проекту присоединился кто-то, кто сам ничего в оси и не берется менять, но разбирается в ней (в том числе отслеживает обсуждения в рассылке) и выполняет функции «технического писателя» по таким вот пунктам...

p.s. примеры AVR переехали каталогом ниже
http://scmrtos.svn.sourceforge.net/viewvc/...s/AVR/GCC/MEGA/

Понятно. Спасибо.


P.S. Примеры для Мега АВР переехали в папку ../MEGA и в описании примеров появился комментарий: "samples for all non-xmega". К чему бы это? Скоро появится папка /xmega. Или нет?

Добрый день!
Осваиваю потихоньку scmRTOS порт для М3, одолевает праздное любопытство: почему класс TCritSect вынесен из пространства имен OS?
Вроде бы как единообразие нарушается при его использовании, всегда хочется по аналогии с
OS::TEventFlag ef;
написать
OS::TCritSect cs;

или тут была какая-то задумка изначально?

Хороший вопрос. Наверное потому, что он сам по себе несёт самостоятельную нагрузку, не "завязываясь" на потроха ОС. Такую штуку можно (и полезно) использовать и без всяких вытесняющих осей в случаях, когда возможен асинхронный доступ к глобальным объектам (например, из основной программы и из прерывания).