scmRTOS (v3) blackfin, переключение контекста + IMASK Опции

[yes]

вообще, кто-нибудь пользует этот порт?

в переключалке задач

.....
[--sp] = lb1;

//--------------------------------------------------------------------------
//
// Switch stack pointers and manage interrupt enable status
//
p5.l = lo(IMASK); // save IMASK value
p5.h = hi(IMASK); // (global interrupts enable state)
r7 = [p5]; //
[--sp] = r7; //
r0 = sp;

call _OS_ContextSwitchHook;

......

на верхушку стека кладется содержимое IMASK и вызывается С-шная функция

TStackItem* OS_ContextSwitchHook(TStackItem* sp) { return OS::Kernel.ContextSwitchHook(sp); }

// "..\..\scmRTOS\Common\OS_Kernel.cpp" line 87 col 50
link 12;

._P2L2147483646:
[FP+ 8] = R0;
.LN12:
// "..\..\scmRTOS\Common\OS_Kernel.cpp" line 87 col 87
R1 = R0 ;
R0.L = _Kernel__2OS; R0.H = _Kernel__2OS;
CALL.X _ContextSwitchHook__Q2_2OS7TKernelFPUl;

.........

при этом link 12 и [FP+8] затирают значение IMASK на стеке

стек в блэкфине предекрементный, ну и вообще вроде бы соответствует соглашениям о вызовах (стр 1-255 40_ccblkfin_man.pdf) - там должно быть место для сохранения аргументов

--------------------------------

я вставил декремент стека

[--sp] = sp; //dummy stack decrement to prevent IMASK overwrite
call _OS_ContextSwitchHook;

после чего мои примерчики заработали

==============================

но не совсем понятно использование разных масок (то есть может эта сохранненная маска потом не нужна и я просто глючу) ?
но без этого исправления вообще нифига не работало...

------------------------------------------------------

собственно, кто-нибудь пользуется scmRTOS для blackfin-а?

==============================

у меня был некий проектик (BF532 без внешней памяти), на котором использовалась scmRTOS v2
в результате разгильдяйства были частично утеряны исходники - при переделывании взял версию 3, но не выходит каменный цветок...

[dxp]

вообще, кто-нибудь пользует этот порт?

Я использую. С самого начала.

в переключалке задач

.....

TStackItem* OS_ContextSwitchHook(TStackItem* sp) { return OS::Kernel.ContextSwitchHook(sp); }

// "..\..\scmRTOS\Common\OS_Kernel.cpp" line 87 col 50
link 12;

._P2L2147483646:
[FP+ 8] = R0;
.LN12:
// "..\..\scmRTOS\Common\OS_Kernel.cpp" line 87 col 87
R1 = R0 ;
R0.L = _Kernel__2OS; R0.H = _Kernel__2OS;
CALL.X _ContextSwitchHook__Q2_2OS7TKernelFPUl;

.........

при этом link 12 и [FP+8] затирают значение IMASK на стеке

стек в блэкфине предекрементный, ну и вообще вроде бы соответствует соглашениям о вызовах (стр 1-255 40_ccblkfin_man.pdf) - там должно быть место для сохранения аргументов

Вообще, функция OS_ContextSwitchHook является не более, чем оберткой для функции OS::TKernel::ContextSwitchHook и последняя объявлена как встраиваемая, т.е. ее тело подставляется в внутрь OS_ContextSwitchHook. В норме она и должна встраиваться и я не сталкивался с ситуацией, когда этого бы не происходило. Более того, это обстоятельство является таковым по замыслу - не нужен совершенно еще один лишний вызов и весь связанный с этим оверхед.

Очевидно, у вас какие-то другие опции оптимизации, что не происходит встраивания инлайновой функции. У меня оптимизация чаще всего -Ov 80 (но и при -Ov 20 поведение аналогичное - все встраивается).

--------------------------------

я вставил декремент стека

[--sp] = sp; //dummy stack decrement to prevent IMASK overwrite
call _OS_ContextSwitchHook;

после чего мои примерчики заработали

Наверное, более правильно было бы

SP += -12;

В любом случае спасибо за правильное и ценное замечание.

но не совсем понятно использование разных масок (то есть может эта сохранненная маска потом не нужна и я просто глючу) ?
но без этого исправления вообще нифига не работало...

Вы про IMASK, который сохраняется в стеке? Если про него, то тут все просто - с помощью этого запоминается состояние прерываний для каждого процесса.

у меня был некий проектик (BF532 без внешней памяти), на котором использовалась scmRTOS v2
в результате разгильдяйства были частично утеряны исходники - при переделывании взял версию 3, но не выходит каменный цветок...

v2 тоже не пропала - до нее можно добраться через сайт проекта, там где-то есть ссылка на Old, по которой лежит целиком весь старый (v2) сайт.

[yes]

Спасибо.

при включенной оптимизации (скорее всего interprocedural или как там она называется) не сохраняет аргументы в стек
но хочется и подебажить

судя по примерам, включена еще "элиминация" в смысле выбрасывание неиспользуемых меток - в скрипте линкера если не объявлять и элиминация выключена - требует эти метки для линковки libc
ldf_heap_length
ldf_heap_space
даже при условии, что кучей не пользоваться...

==========

пропажа v2 - пропали мои исходники - у Вас все в порядке
но если переписывать, то лучше на v3

в работе RTOS никаких непонятностей не заметил.

------------------

а с использованием Scratch памяти в качестве стека задач, какие-нибудь проблемы возможны?
по DMA доступ не нужен, байтовый доступ ... можно сделать чтобы не было
а я почему-то не встречал использования Scratch
ни в каких примерах ldf, а тут проект без внешней памяти - каждый килобайт на счету ...

вот описание аномалии:
Reads from the scratchpad memory may return incorrect data under some conditions. The problem occurs when reads of scratchpad
memory are immediately followed by another read (of any location, including non-scratchpad locations), where the addresses being
accessed do not have the same least significant address bit. This means that one of the transfers has to be a byte access. The other access
has to be either a byte, 16-bit or 32-bit access on a different byte boundary than the first access. In addition, the instruction immediately
before the Scratchpad memory read has to generate a memory stall due to either a dual DAG bank collision, a non-L1 memory data fetch,
or a cache-line fill.
If an instruction does not perform a read immediately after the scratchpad read, no problems occur. Also, back to back non-byte reads
function properly.
WORKAROUND:
The simplest workaround for assembly programmers is to place any non-read instruction after each scratchpad read. For C programmers,
one solution is not to map any data to the scratchpad.
Alternatively the VisualDSP++ Blackfin compiler includes a workaround for this hardware anomaly. The compiler will automatically enable
the workaround for the appropriate silicon revisions and part numbers, or the workaround can be enabled manually by specifying the
compiler flag -workaround scratchpad-read' With the workaround enabled, when a sequence of three load instructions occurs (or occur
as parts of a multi-issue instruction), where at least one of (2) and (3) is a byte load, a nop will be inserted between (1) and (2) or (2) and (3):
A load instruction (1);
A load instruction (2);
A load instruction (3);

[bmf]

..
а с использованием Scratch памяти в качестве стека задач, какие-нибудь проблемы возможны?
по DMA доступ не нужен, байтовый доступ ... можно сделать чтобы не было
а я почему-то не встречал использования Scratch
ни в каких примерах ldf, а тут проект без внешней памяти - каждый килобайт на счету ...

Используется, посмотрите исходники ROM загрузчиков от analog.
Еще используется для сохранения стека при прерываниях - порт bfin для RTEMS (cpu_asm.S).

[yes]

Используется, посмотрите исходники ROM загрузчиков от analog.
Еще используется для сохранения стека при прерываниях - порт bfin для RTEMS (cpu_asm.S).

спасибо за информацию

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

есть вопрос по С++ применительно к scmRTOS:

как правильнее вызывать Sleep из некоторой иерархии сишных функций внутри проекта?
TProc1::Exec() -> foo() -> boo() -> moo()

и внутри moo() я хочу передать управление
могу написать
TProc1::Sleep(10);
или
Proc1.Sleep(3);

как правильнее? я что-то смутно помню про статические члены и т.п. но С++ не настолько мне родной язык, чтобы такие тонкости различать

-------------------------------------------

видимо я понял "танцы с бубном" для прерываний BF - при сохранении контекста [--sp] = reti; разрешаются вложенные прерывания (GLBLDIS в IPEND очищается)
поэтому нужно замаскировать все прерывания выше 14
так?

вроде бы если изменить порядок регистров в контексте
[--sp] = r0;
r0=reti;
[--sp] = r0;
то прерывания разрешаться не будут

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

------------------------------------

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

и наверно, "вращения приоритетов" тоже
дедлочится у меня код изредка... вроде стандартная конструкция - работало в VDSP и eCOS
пока не могу понять почему - решил вот отвлечься - пописать в форум

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

как правильнее вызывать Sleep из некоторой иерархии сишных функций внутри проекта?
TProc1::Exec() -> foo() -> boo() -> moo()

и внутри moo() я хочу передать управление
могу написать
TProc1::Sleep(10);
или
Proc1.Sleep(3);

Поскольку moo() может вызываться из любого процесса, вызывать в ней Proc1.Sleep(3) как-то некрасиво, хотя работать скорее всего будет. Посколько Sleep() - статическая функция-член, ее можно вызывать не указывая конкретный объект: OS::TBaseProcess::Sleep();