[IgorKossak 0]

А LTO что - нет? Только что скачанное:

Или я что-то не так делаю?

Нету, забыл сказать, потому что не использую.

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

[dezna 0]

ЗЫ. Если уж совсем не пойдёт, и вы боитесь самодельных сборок, то есть Sourcery CodeBench Lite, бывшая sourcery g++ lite. (качать ARM EABI Release).

вчера собрал arm-none-eabi 4.7.2. проект 1-EVENT собирается без шаманств с линкер скриптом и раьотает.

собрал свой рабочий проект - вылетел в HardFault.

поставил на закачку CodeBench Lite. посмотрим как он себя поведёт.

Edited January 24, 2013 by dezna

[uriy 5]

Вопрос больше касается С++. Делаю первый проект на scmRTOS и на С++ еще никогда не писал.

Накидал 3 процесса в одном мейн файле. Все работают как надо.

Начал раскидывать процесессы по отдельным файлам.

Я привык раскидывать процессы по своим c и h файлам.

Тут произошло что-то странное. Начал обрабатываться только один процесс и девайс как будто перезагружается раз в секунду.

Хотя у меня watchdog даже не задействован.

 

файл thread_lcd.cpp

#include "thread_lcd.h"

template<> void TProc3::exec();
TProc3 Proc3;
//---------------------------------------------------------------------------
namespace OS {

template<> void TProc3::exec()
{
    uint8_t i;
    sleep(1000);
    lcd_clear();
    lcd_goto(1,0);
    for(;;)
    {
        lcd_goto(1,0);
        xprintf("hello %d", i++);
        sleep(1000);
    }
} // TProc3::exec()

} // namespace OS

 

файл thread_lcd.h

#ifndef _THREAD_LCD_H_
#define _THREAD_LCD_H_
#include <scmRTOS.h>
#include "hardware/hardware.h"
typedef OS::process<OS::pr2, 120> TProc3;
#endif

 

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

[dxp 58]

Вопрос больше касается С++. Делаю первый проект на scmRTOS и на С++ еще никогда не писал.

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

 

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

[AHTOXA 18]

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

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

error: specialization of 'template  in different namespace [-fpermissive]

[dxp 58]

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

error: specialization of 'template  in different namespace [-fpermissive]

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

 

namespace OS
{
#ifndef __GNUC__  // avoid GCC bug ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15867 )
    template<> void TIdleProc::exec();
#endif

    TIdleProc IdleProc;
}

[AHTOXA 18]

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

Не, то было другое. Там GCC давал предупреждение "redundant redeclaration".

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

 

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

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

Если прототип функции объявлен в пространстве имён OS, то и реализация должна быть там же.

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

 

[AHTOXA 18]

И специализацию exec мы пишем не для OS::process<тра-та-та>, а для TProc3, разве не так?

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

По сути мы имеем

namespace OS
{
    template <>
    void OS::process<OS::pr0, 3600>::exec()
    {
...

[dxp 58]

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

По сути мы имеем

namespace OS
{
    template <>
    void OS::process<OS::pr0, 3600>::exec()
    {
...

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

[AHTOXA 18]

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

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

И это правильно. Иначе получалось бы, что все производные типы гвоздями были бы прибиты к пространству имён базового типа.

Ты не путай наследование и инстанцирование. Если бы мы написали

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

[dxp 58]

Ты не путай наследование и инстанцирование. Если бы мы написали

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

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

[uriy 5]

Между тем у меня появились некоторые подробности по поводу моей неудачной попытки разбить процессы по файлам.

Проблема вовсе не в С++. Что-то новое пугает и сразу валишь на это.

 

Я не уточнял что это контроллер STM8L152. C scmRTOS не пошло, решил запустить операционку OSA.

В обоих операционках три задачи: дисплей, rf модуль и пока просто мигание светодиодом.

И увидел ту же самую периодическую перезагрузку. Я был очень удивлен.

При включении добавил вывод на дисплей регистра источника сброса.

Причиной сброса оказался WWDG (window watchdog). Удивился еще больше. WWDG никогда не использую, даже не понимаю как его применить.

Ограничиваюсь обычным watchdog, но в этом проекте даже он еще не был задействован.

Причина проблем оказалась в связке ADC+DMA+TIM. DMA складывает три канала АЦП в буфер. В прерывании по завершении заполнения буфера проводит рассчет. Прерывание происходит пару раз в секунду. Запрет прерываний не устраняет проблему. Как-будто DMA пишет туда куда не надо.

 

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

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

Во всех экспериментах в буфере АЦП всегда складывались ожидаемые значения.

 

В случае с scmRTOS похоже просто повезло что проблема не вылезла сразу когда все задачи были в одном файле.

Разбираться с этим пока не стал, пишу остальную часть кода.

[AHTOXA 18]

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

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

Думаю, что GCC делает правильно. Думаю также, что твой компилятор просто удовлетворяется префиксом OS:: в имени класса, и считает, что этого достаточно для того, чтобы реализация функции была в пространстве имён OS. Но наверняка по стандарту это не так (gcc довольно ревностно относится к соблюдению стандартов).

[dxp 58]

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

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

 

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

 

std::vector<int> my_vector;

 

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

 

Прерывание происходит пару раз в секунду. Запрет прерываний не устраняет проблему. Как-будто DMA пишет туда куда не надо.

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