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

вчера собрал arm-none-eabi 4.7.2. проект 1-EVENT собирается без шаманств с линкер скриптом и раьотает.
собрал свой рабочий проект - вылетел в HardFault.
поставил на закачку CodeBench Lite. посмотрим как он себя поведёт.

Сообщение отредактировал dezna - Jan 24 2013, 09:12

Вопрос больше касается С++. Делаю первый проект на scmRTOS и на С++ еще никогда не писал.
Накидал 3 процесса в одном мейн файле. Все работают как надо.
Начал раскидывать процесессы по отдельным файлам.
Я привык раскидывать процессы по своим c и h файлам.
Тут произошло что-то странное. Начал обрабатываться только один процесс и девайс как будто перезагружается раз в секунду.
Хотя у меня watchdog даже не задействован.

файл thread_lcd.cpp


файл thread_lcd.h


Снова перетащил теже исходники в один файл и работает как надо.

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

Ещё. Код исполняемой функции процесса я не помещаю в пространство имён OS - ведь это уже код приложения, ему нечего делать в OS. Вообще, при написании прикладного кода ничего не нужно помещать в OS, это не "территория" проекта.

GCC на такое ругается:

А, это не тот ли самый косяк застарелый?

Не, то было другое. Там GCC давал предупреждение "redundant redeclaration".
А тут, как мне кажется, всё верно. Если прототип функции объявлен в пространстве имён OS, то и реализация должна быть там же. Иначе это будет реализация какой-то другой функции.

ЗЫ. Кстати, баг тот уже давно исправлен, можно вычистить этот кусочек.

Хм. В пространстве имен OS был объявлен OS::process, а TProc3 объявлен уже в глобальном пространстве имен. И специализацию exec мы пишем не для OS::process<тра-та-та>, а для TProc3, разве не так?

Так TProc3 - это просто typedef для OS::process<тра-та-та>. Алиас, так сказать.
По сути мы имеем

OS::process<тра-та-та> в том случае - это уже инстанцирование шаблона, т.е. рожается конкретный тип из параметрического, и этот конкретный тип уже объявлен не в OS, а в глобальном. И это правильно. Иначе получалось бы, что все производные типы гвоздями были бы прибиты к пространству имён базового типа.

GCC с тобой не согласен

Ты не путай наследование и инстанцирование. Если бы мы написали
class SuperProcess : public OS::process<тра-та-та> - тогда да, это производный тип, и он уже не в пространстве имён OS. А в обсуждаемом случае мы всего лишь реализуем объявленную ранее функцию шаблона. И объявлена она в пространстве имён OS.

Я и не путаю. Это ты путаешь инстанцирование и псевдонимы (typedef). OS::process<тра-та-та> - это уже другой тип, чем OS::process. И его функция exec - это полная специализация этого нового типа. Обе эти новые сущности могут жить в любом пространстве имён, в т.ч. и в глобальном.

Между тем у меня появились некоторые подробности по поводу моей неудачной попытки разбить процессы по файлам.
Проблема вовсе не в С++. Что-то новое пугает и сразу валишь на это.

Я не уточнял что это контроллер STM8L152. C scmRTOS не пошло, решил запустить операционку OSA.
В обоих операционках три задачи: дисплей, rf модуль и пока просто мигание светодиодом.
И увидел ту же самую периодическую перезагрузку. Я был очень удивлен.
При включении добавил вывод на дисплей регистра источника сброса.
Причиной сброса оказался WWDG (window watchdog). Удивился еще больше. WWDG никогда не использую, даже не понимаю как его применить.
Ограничиваюсь обычным watchdog, но в этом проекте даже он еще не был задействован.
Причина проблем оказалась в связке ADC+DMA+TIM. DMA складывает три канала АЦП в буфер. В прерывании по завершении заполнения буфера проводит рассчет. Прерывание происходит пару раз в секунду. Запрет прерываний не устраняет проблему. Как-будто DMA пишет туда куда не надо.

Дальше сделал вывод на дисплей переменной равной нулю при старте с инкрементом раз в секунду. При отключенном ADC+DMA+TIM переменная обновляется на дисплее, rf модуль принимает валидные данные, светодиод мигает.
Включаю ADC+DMA+TIM. Переменная на дисплее по прежнему обновляется раз в секунду. Но она уже принимает случайные значения, обмен с rf модулем нарушен, а контроллер больше не перезагружается.
Во всех экспериментах в буфере АЦП всегда складывались ожидаемые значения.

В случае с scmRTOS похоже просто повезло что проблема не вылезла сразу когда все задачи были в одном файле.
Разбираться с этим пока не стал, пишу остальную часть кода.

Начнём с того, что типа OS::process не существует. Существует шаблонный класс (class template) OS::process. При его инстанцировании с конкретными параметрами появляется тип OS::process<конкретные параметры>. Он точно также находится в пространстве имён OS. (Смотри на его имя). Для удобства мы дали этому типу псевдоним TProc3.
Думаю, что GCC делает правильно. Думаю также, что твой компилятор просто удовлетворяется префиксом OS:: в имени класса, и считает, что этого достаточно для того, чтобы реализация функции была в пространстве имён OS. Но наверняка по стандарту это не так (gcc довольно ревностно относится к соблюдению стандартов).

Как это не существует? Это параметризованный тип. И OS:: в OS::process - это просто квалификация пути к этому типу. А конкретный тип, который от него рожается путём подстановки параметра шаблона, уже возникает в том пространстве имён, в котором он объявлен.

По твоей логике получается, что в

std::vector<int> my_vector;

my_vector тоже находится в пространстве имён std. Так?


Т.е. подозреваете банальный (и подлый) memory overwrite при пересылке данных?