Начало работы with scmRTOS, Несколько вопросиков Опции

[URANst]

Хочется научиться работать с этой штукой - scmRTOS & AVR(Atmega8) & IAR 4.30A ! Почитал темы которые есть на форуме, почитал User's Manual v2. Возникло некторое количество вопросов:
1. Какая последовательность создания проекта: мои предположения - создаем в IAR новый проект, тискаем добавить файлы в проект и добавляем OS_Kernel.cpp , OS_Services.cpp , OS_Target_asm.s90 , OS_Target_cpp.cpp , usrlib.cpp. В maim.cpp пишем

Код

#include <scmRTOS.h>

. Затем каким то образом нужно создать самому как я понял scmRTOS_TARGET_CFG.h и scmRTOS_CONFIG.h, но как не ясно или их нужно тупо скопировать из примера автора и если что нада то менять.
2. Почему в примерах автор добавляет

Код

void OS::SystemTimerUserHook() { }
void OS::IdleProcessUserHook() { }

Так нужно делать всегда ?
3. Дальше >> понятно что для AVR передачу управления можно осуществить сгенерировав прерывание например от компоратора как описано в документации, но непонятно как нужно оформить функцию обработки этого прерывания, и чем она будет отличаться от функции обработки других прерываний.

О взаимодействии между потоками пока вроде понятно.

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

Мог написать что - нибудь глупое, потому как в круг моих понятий scmRTOS пока входит очень туманно или вообще не входит.

[alux]

При включении моих исходников проекта на Си в проект smcRTOS (пример 1-EventFlag)возникла проблема.

Код

Error[e18]: Range error,  
PC offset out of range. Valid range is -4096 (-0x1000) to 4094 (0x0FFE).
File: D:\...\scmRTOS\AVR\OS_Target_asm.s90, Line: 234  
Source:      xjmp ContextSwitcher_ISR
  Where $ = #no label found# + 0x5C  [0x5C]
            in module "scmRTOS_Asm" (D:\...\1-EventFlag\Release\Obj\OS_Target_asm.r90),
            offset 0x5C in segment part 1, segment INTVEC
  What: #no label found# - ($ + 2) [0x1388]
  Allowed range: 0xFFFFF000 - 0xFFF
  Operand: #no label found# [0x13e6]
           in module scmRTOS_Asm (D:\...\1-EventFlag\Release\Obj\OS_Target_asm.r90),
           Offset 0x0 in segment part 2, segment CODE

Мой проект пока состоит из последовательного вызовов функций инициализации различной переферии. Ошибка возникает при подключении lcd_Init(); Отдельно мой проект отлажен под Мега324P. Занимал около 20кБ ROM и около 500 байт RAM. Пробовал изменить на Мега 644P и изменить размеры CSTACK, RSTACK. Не помогло. Как решить эту проблему?

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

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

Каким-то образом обработчик прерывания переключения контекста оказывается в месте, куда не "дотягивается" xjmp из области векторов. Судя по ограничению +/- 4К вместо макроса xjmp подставляется RJMP, хотя нужен JMP. Глянул в исходники:

Код

#if (A90_PROC_OPTION == 0) || (A90_PROC_OPTION == 1)
#define xcall   rcall
#define xjmp    rjmp
#else
#define xcall   call
#define xjmp    jmp
#endif

Где определяется A90_PROC_OPTION я не нашел - ни в исходниках, ни в описании ассемблера. Неопределенный символ считается равным нулю. Можно предположить, что перед этим должна быть (утерянная) строка

Код

#define A90_PROC_OPTION   ((__TID__ >> 4) & 0x0F)

dxp завтра разберется, откуда вылезла эта бага.

[dxp]

Где определяется A90_PROC_OPTION я не нашел - ни в исходниках, ни в описании ассемблера. Неопределенный символ считается равным нулю. Можно предположить, что перед этим должна быть (утерянная) строка

Код

#define A90_PROC_OPTION   ((__TID__ >> 4) & 0x0F)

Действительно, косяк. Как он вкрался, не помню хоть убей. Пофиксено.

P.S. Лишний раз "порадовался" "красоте" иаровского подхода - поменял имя МК и началось... Регистра TIMSK там уже нет, вместо него есть TIMSK0 и т.д. Я понимаю, что одного регистра не хватает, но зачем было имя-то менять? Пусть бы для совместимости осталось. То же самое касается TCCR0, которого уже тоже нет, а есть два с буквами на конце. Почему бы было не оставить для совместимости старое имя? Не понимаю. И уж зачем вообще было менять имя вектора ANA_COMP_vect на ANALOG_COMP_vect? А если заменили, то и вставили бы код для совместимости. И такие косяки у них с незапамятных времен. Такое впечатление, что о портировании кода даже внутри семейства они вообще не думают, а заголовки для разных процов лабают разные люди, которые никак свои действия друг с другом не координируют.

Про упомянутое

/* SREG */
#define I 7
#define T 6
#define H 5
#define S 4
#define V 3
#define N 2
#define Z 1
#define C 0

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

iom164.h
iom324.h
iom644.h
iom644p.h
iopwm2.h
iopwm3.h

Т.е. больше похоже на чью-то личную инициативу, нежели на общий подход. Бардак, короче.

[alux]

Регистра TIMSK там уже нет, вместо него есть TIMSK0. Бардак, короче.

Вот только мне не понятно для чего добавили 0 в имена битов SPI ?

/* SPSR */
#define SPIF0 7
#define WCOL0 6
#define SPI2X0 0

/* SPCR */
#define SPIE0 7
#define SPE0 6
#define DORD0 5
#define MSTR0 4
#define CPOL0 3
#define CPHA0 2
#define SPR01 1
#define SPR00 0

Не может же быть несколько SPI-интерфейсов на борту... Или может? Мне кажется, что это они скорее сделали по привычке... Хотя в даташите указаны "правильные" имена. По поводу регистра TIMSK0... Почему не исправлено? Добавить то всего три строчки.

#ifndef TIMSK0
#define TIMSK TIMSK0
#endif

Если гора не идет к Магомету, то Магомет идет к горе

Действительно, косяк. Как он вкрался, не помню хоть убей.

Еще не начал работать с OS, а уже отлавливаю косяки. То ли еще будет

Сдаётся мне, что если откроете overview завтра, то там окажется завтрашнее число.

Точно

Имеет ли значение уровень оптимизации компилятора для smcRTOS ?

Дело в том, что у jacOS есть примечание для IAR C/EC++ for AVR 4.11A/W32 :

Вероятны проблемы при установке опций оптимизации Code motion (?) Cross Call (?)

И последнее. Рискну задать глупый вопрос. Если в проекте используется прерывание, но оно не является источником события для процессов, обязательно ли обработчик прерывания должен иметь тип OS_INTERRUPT и на входе ISR создавать объект OS::TISRW_SS ISRW ? И можно ли разрешать глобальные прерывания до OS::Run() ?

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

Вот только мне не понятно для чего добавили 0 в имена битов SPI ?
Не может же быть несколько SPI-интерфейсов на борту... Или может?

Я думаю что может. И скорее всего добавление 0 вызвано тем, что они начали таки движение в сторону унификации. Для новых кристаллов биты и регистры будут "пронумерованы" а старые потихоньку вымрут. Процесс перехода всегда сложный, но что поделать...

Еще не начал работать с OS, а уже отлавливаю косяки. То ли еще будет

Вы же понимаете, что мы не можем проверить наши исходники на всех возможных процессорах Мы можем только предполагать, что раз программа работает на ATmegaX (LPC2xxx, BFxxx и т.д.), то она будет работать и на ATmegaY (LPC2yyy, BFyyy и т.д.), потому что все AVR (LPC2, BF и т.д.) похожи. К сожалению, они похожи не во всем, отсюда и такие косяки. Чем больше их найдете вы - тем меньше их останется тем, кто будет использовать ее после вас. Кроме того, я, например, уже не работаю с ADuC70xx и STR71x, порты для которых написал. Для STR71x у меня не осталось железа, на котором я мог бы проверить вносимые изменения. Поэтому исправления найденных в других портах багов или улучшения переносятся в этот порт без проверки. Вы бы что предпочли - старую версию, в которой есть известные глюки или новую, в которой они исправлены, но, возможно, внесены новые?

Рискну задать глупый вопрос. Если в проекте используется прерывание, но оно не является источником события для процессов, обязательно ли обработчик прерывания должен иметь тип OS_INTERRUPT и на входе ISR создавать объект OS::TISRW_SS ISRW ?

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

И можно ли разрешать глобальные прерывания до OS::Run() ?

Если в разрешаемых прерываниях не используются сервисы ОС, их обработчики не имеют OS::TISRW(__SS), то можно, но зачем?

[Сергей С.]

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

Как узнать максимальное потребление стека задачами? Можно ли проинициализировать все стеки каким-либо значением вроде 0xA5, как в FreeRTOS, и главное, как сделать это проще всего в scmRTOS? Или например в бутлоадере забить всю память байтами 0xA5, а затем прыгать на начало основной программы?

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

Как узнать максимальное потребление стека задачами? Можно ли проинициализировать все стеки каким-либо значением вроде 0xA5, как в FreeRTOS, и главное, как сделать это проще всего в scmRTOS?

Память стеков уже по умолчанию проинициализирована значением, только не 0xA5 а 0. В портах для ARM на верхушке контекста лежит содержимое CPSR, который не может быть равен нулю (конструкция у него такая). Поэтому я смотрю визуально (отладчиком или через терминал), где первый "не-ноль" - там было занято. Если есть желание забить каким-то своим значением - допишите memset в конструктор TProcess.

Или например в бутлоадере забить всю память байтами 0xA5, а затем прыгать на начало основной программы?

Не пройдет - стеки попадают в область глобальных неинициализированных переменных и cstartup обнуляет эту область.

[Сергей С.]

Если есть желание забить каким-то своим значением - допишите memset в конструктор TProcess.

Всего одна строчка кода - а сколько пользы! Вся память как на ладони. Спасибо.