Написал порт scmRTOS под ARM, интересны отзывы Опции

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

Написал порт scmRTOS (http://scmrtos.narod.ru/) для ARM. Отлаживал на AT91SAM7S64. Поскольку опыта в ARMах пока маловато (второй проект на ARM и первый с асмом), то перед тем как связываться с автором хотелось бы чтобы кто-то более опытный глянул. Порт лежит тут: http://upload.caxapa.ru/scmRTOS_arm.zip
Спасибо всем.

[Pat]

чтобы кто-то более опытный глянул. Порт лежит тут:

Я не шибко опытный, но что то компилер не находит идентификатор AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE.

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

>Я не шибко опытный, но что то компилер не находит идентификатор AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE.

Виноват, ставил патч от ИАРа.
#ifndef AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE
#define AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE AT91C_AIC_SRCTYPE_INT_EDGE_TRIGGERED
#endif

[Pat]

Скомпилир все ОК.
Запускаю отладку в симуляторе.
После выполнения подпрограммы в файле OS_Target_asm.s79

Код

ContextRestore
        MOV        LR, R0            ; use LR_svc as stack pointer

        LDMFD    LR!, {R0}        ; pop saved CPSR
        MSR        SPSR_cxsf, R0    ;
        LDMFD    LR, {R0-LR}^    ; restore all regs and reti
        NOP
        ADD        LR, LR, #15*4
        LDMFD    LR, {PC}^        ; reti

Улетает в неизвесном направлении.

Еще не хочет компилироваться в режиме ARM пишет
Internal Error: [symbol_lookup_M31]: symbol not found for mode 1 (backend generating) (P0: 0, P1: 0)

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

Скомпилир все ОК.
Запускаю отладку в симуляторе.
После выполнения подпрограммы в файле OS_Target_asm.s79
Улетает в неизвесном направлении.

Действительно. Хотя в железе работает. Завтра попробую найти где разница и кто же работает правильно - ядро или симулятор :-). Кстати, в симуляторе не будут вызываться прерывания таймера со всеми вытекающими.

Еще не хочет компилироваться в режиме ARM пишет
Internal Error: [symbol_lookup_M31]: symbol not found for mode 1 (backend generating) (P0: 0, P1: 0)

компилятор падает от конструкции

Код

    if(SysTickCount == 146)
        __no_operation();

в void OS::TKernel::SystemTimer(). Это рудимент - я ошибку искал. Но почему такая безобидная конструкция выбивает компилятор - наверное вопрос к его разработчикам. Причем __no_operation() без условия или другое действие в условии компилится нормально. В общем выкинуть этот кусок кода.

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

Запускаю отладку в симуляторе.
После выполнения подпрограммы в файле OS_Target_asm.s79
Улетает в неизвесном направлении.

Проблема в команде

Код

    LDMFD    LR, {R0-LR}^    ; restore all regs and reti

(коментарий в ней конечно неправильный)
согласно документу ARM DDI 0029E:
LDM with R15 in transfer list and S bit set (Mode changes)
If the instruction is a LDM then SPSR_<mode> is transferred to CPSR at the same time as R15 is loaded.

R15 not in list and S bit set (User bank transfer)
For both LDM and STM instructions, the User bank registers are transferred rather than the register bank corresponding to the current mode.

В данной же ситуации симулятор загружает SPSR_irq в CPSR хотя R15 отсутствует в списке регистров.

Получается это ошибка симулятора. Или я где-то недопонял?

[GetSmart]

В данной же ситуации симулятор загружает SPSR_irq в CPSR хотя R15 отсутствует в списке регистров.

Данная команда в любом случае должна перегрузить CPSR. Если в списке будет R15, то они обновятся одновременно. Это делается в обработчиках прерываний. Если R15 в списке нету, то выполнение продолжится дальше, но CPSR будет перегружен, при этом сменится режим привилегий и банк регистров на тот, который был указан в SPSR.

Вы вообще сами написали этот ASM-файл или сильно переделали чужой? Каким-то очень страшным он мне показался.

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

В данной же ситуации симулятор загружает SPSR_irq в CPSR хотя R15 отсутствует в списке регистров.

Данная команда в любом случае должна перегрузить CPSR.

Странно, но почему-то в моем макете с AT91SAM7S64 при отладке через MT-Link перегрузки CPSR не происходит. Могу попробовать на LPC2119, но не думаю что будет большая разница.

Если в списке будет R15, то они обновятся одновременно. Это делается в обработчиках прерываний.

Пробовал так (через MT-Link). Получалось что загружаются привилегированные регистры после чего переключается режим и SP, LR содержат совсем не то.

Вы вообще сами написали этот ASM-файл или сильно переделали чужой? Каким-то очень страшным он мне показался.

Первый блин :-) Поэтому и прошу советов что можно сделать лучше. Долго смотрел на переключатель контекстов FreeRTOS, потом правил файл порта от MSP430.

[GetSmart]

Напишите комментарии в ASM-файле к каждой команде. И ещё отдельно текстом что вообще должен делать этот файл. (каждая точка входа (Public Name)) Может тогда я смогу помочь исправить. А то ооочень трудно воспринимаемая прога. Код перемешан с какими-то отладочными командами. А вообще, я писал пол года назад на асме что-то похожее. Там была организована мультизадачность с временным разделением. Для каждой задачи был свой стек и сохранялся контекст. Очень быстрая (2 мкс переключение задач), но без каких-либо наворотов. Все задачи писались как обычные процедуры на Си, только прерывание переключения задач на асме. Процессор LPC2138.

[GetSmart]

Вопрос: почему у вас в xcl-файле начальные адреса RAM и ROM совпадают? У 7-ых армов одно общее адресное пространство, поэтому адреса должны быть разными. В LPC-шке ROM начинается с 0x00, а внутренняя RAM с 0x40000000.

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

Напишите комментарии в ASM-файле к каждой команде.

все описал, отладочное убрал.

Вопрос: почему у вас в xcl-файле начальные адреса RAM и ROM совпадают?

Проект отлаживаю в ОЗУ, файл .xcl из ИАРовского примера для проекта в ОЗУ.

Прикрепленные файлы

 src.zip ( 2.34 килобайт ) Кол-во скачиваний: 63

 

[GetSmart]

Всё-равно как-то запутанно. Попробуйте разобраться с моим обработчиком. Может переделаете после этого свой.

MODULE MULTI_TASK

PUBLIC TASK_IRQ
EXTERN TASK_DATA
RSEG IRQ_STACK

RSEG ICODE
CODE32

VIC_ORG EQU 0xFFFFF000
VICSoftInt EQU 0xFFFFF018
VICSoftIntClear EQU 0xFFFFF01C
VICVectAddr EQU 0xFFFFF030

VIC_TIMER1 EQU 5
T1_ORG EQU 0xE0008000
T1IR EQU 0xE0008000
T1TC EQU 0xE0008008
T1MR0 EQU 0xE0008018


TASK_IRQ: sub lr,lr,#4
stmdb sp!,{lr}
mrs lr,SPSR
stmdb sp!,{r12,lr}
mov r12,sp ; указатель в стеке IRQ
msr CPSR_cf,lr ; перек. в SYSTEM с разреш. прерыван.
stmdb sp!,{r0-r11,lr}
ldmia r12!,{r9-r11}
stmdb sp!,{r9-r11} ; R12, CPSR, PC

ldr lr,=TASK_DATA+8
ldr r11,[lr,#-4] ; TaskCur
str sp,[lr,+r11,LSL #3]
add r11,r11,#1
ldr r10,[lr,#-8] ; TaskMax
cmp r11,r10
bcc TaskIrq50
mov r11,#0
TaskIrq50: str r11,[lr,#-4] ; TaskCur
add lr,lr,r11,LSL #3
TaskIrq60: ldr sp,[lr,#+0] ; указатель SP новой задачи
ldr r11,[lr,#+4] ; период задачи в тиках
ldr lr,=T1_ORG
str r11,[lr, #+T1MR0 - T1_ORG]
mov r11,#0
str r11,[lr, #+T1TC - T1_ORG] ; сброс таймера в 0
mov r11,#0xff
str r11,[lr, #+T1IR - T1_ORG] ; сброс установленных битов

ldmia sp!,{r9-r11}
stmdb r12!,{r9-r11} ; R12, CPSR, PC
ldmia sp!,{r0-r11,lr}
mrs r12,CPSR
orr r12,r12,#0xD2
bic r12,r12,#0x0D
msr cpsr_cf,r12 ; перезагрузка LR и SP
ldr r12,=VIC_ORG
mov lr,#(1 << VIC_TIMER1)
str lr,[r12,#+VICSoftIntClear - VIC_ORG]
str lr,[r12,#+VICVectAddr - VIC_ORG]; сброс приоритетов VIC
ldmia sp!,{r12,lr}
msr SPSR_cf,lr
ldmia sp!,{pc}^

LTORG

END
____________________________________
Из си-шного файла:

#define TaskMax 3

typedef struct
{ void (*Task)();
xLong Ticks;
} st_task_rec;

typedef struct
{ xLong Max;
xLong Cur;
st_task_rec List[TaskMax];
} st_task;

st_task TASK_DATA;

void RegisterTask(void (*task)(), xInt prior)
{
static const xLong priorTime[SpeedTaskMax] = {PCLKFREQ/50,PCLKFREQ/100,PCLKFREQ/200};

if (TASK_DATA.Max >= TaskMax) return;
if (prior >= SpeedTaskMax) prior = SpeedTaskMax-1;

TASK_DATA.List[TASK_DATA.Max].Task = task;
TASK_DATA.List[TASK_DATA.Max++].Ticks = priorTime[prior];
}

Вообще, у каждой задачи свой стек, в котором по прерыванию таймера (или по команде симуляции аппаратного прерывания) сначала сохраняется контекст (R0-R12,LR, SP, CPSR_main, PC), затем происходит переключение на стек новой задачи и обратная загрузка контекста и переход на прерванную задачу. При всём этом немного используется IRQ-стек. Иначе нельзя.

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

Всё-равно как-то запутанно. Попробуйте разобраться с моим обработчиком. Может переделаете после этого свой.

Спасибо, изучу.
Сходу нарвался на ошибку:

Код

    sub lr,lr,#4    ; подвинули адрес возврата
    stmdb sp!,{lr}; сохранили его на стеке прерываний
    mrs lr,SPSR    ; взяли CPSR процесса в LR
    stmdb sp!,{r12,lr}; сохранили его и R12
    mov r12,sp     ; указатель в стеке IRQ
    msr CPSR_cf,lr ; перек. в SYSTEM с разреш. прерыван.
            ; а также в THUMB если процесс был в THUMB
            ; тут все и упало

Проблема еще и в том, что scmRTOS написана на С++ и там к данных объектов добраться из АСМа в общем случае нельзя (или настоятельно не рекомендуется - я так понял).

При всём этом немного используется IRQ-стек. Иначе нельзя.

Ну, у меня кажется получилось :-)

[GetSmart]

msr CPSR_cf,lr ; перек. в SYSTEM с разреш. прерыван.
; а также в THUMB если процесс был в THUMB
; тут все и упало

Не, разумеется вы это должны доработать. В моей системе THUMB задачи не использовались. Важна была скорость исполнения, а размер не существеннен. Добавьте сброс THUMB-бита. А команды сохранения и восстановления контекста как бы парные (точнее префиксы stmDB и ldmIA). У вас они почему-то одни и те же. К тому же лишние инкременты указателей после этих команд, когда всё это можно сделать прямо в команде. Кстати, 12 байт используемых в стеке IRQ - это просто смешно как мало.

Разбирайтесь. Если что - пишите сюда.

[spf]

Первый блин :-) Поэтому и прошу советов что можно сделать лучше. Долго смотрел на переключатель контекстов FreeRTOS, потом правил файл порта от MSP430.

Еще думаю можно посмотреть на порты uCOS-II для ARM. (http://www.ucos-ii.com/)

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

Послушал советы, кое-чего поправил. Сделал targets для AT91SAM7S64(RAM/Flash) и LPC2119(RAM/FLASH). В качестве стека прерываний теперь используется стек main(), процесс Idle как обычный со своим стеком. Исходники самой ОС взял от последней версии 2.04а.
Надеюсь, возможность попробовать порт на LPC увеличит активность отзывов/советов.
Вопрос с симулятором остается открытым. По моим понятиям все же он некорректно отрабатывает LDMFD LR, {R0-LR}^. Попробую выяснить этот вопрос в отдельной ветке.

Прикрепленные файлы

 scmRTOS_ARM.zip ( 51.88 килобайт ) Кол-во скачиваний: 82

 

[GetSmart]

Странно, но почему-то в моем макете с AT91SAM7S64 при отладке через MT-Link перегрузки CPSR не происходит. Могу попробовать на LPC2119, но не думаю что будет большая разница.

Совсем забыл. Перезагрузка CPSR происходит только когда процессор находится не в USER или SYSTEM режиме. Потому что в этих режимах регистра SPSR вообще нет. Команда как бы некорректная, хотя процессор не падает. И ещё. Прочитать (загрузить в CPSR) можно только SPSR текущего режима. Запись в SPSR - аналогично. Даже если в команде явно будет указан регистр SPSR из другого режима. Непонятно только, зачем ассемблер разрешает так писать.

У вас вообще по какому событию происходит переключение?

А для чего или кого вообще пишите?

Сообщение отредактировал GetSmart - May 17 2006, 16:42

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

Странно, но почему-то в моем макете с AT91SAM7S64 при отладке через MT-Link перегрузки CPSR не происходит. Могу попробовать на LPC2119, но не думаю что будет большая разница.

Совсем забыл. Перезагрузка CPSR происходит только когда процессор находится не в USER или SYSTEM режиме.

Все это понятно. На это я с самого начала нарвался :-) У меня эта команда выполнятеся в IRQ_mode.
Но все же я настаиваю, что восстановление CPSR происходит только в одном варианте команды: когда стоит крыжик (^) И в списке регистров есть R15(PC). При этом восстанавливаются регистры в банке соотв. режима исключений. Если же в команде стоит крыжик и R15 в списке нет, то восстанавливаются регистры user(system) банка и CSPR не восстанавливается.
Или другими словами: если в списке LDM есть R15, то крыжик означает восстановление CSPR, если R15 нет - то крыжик означает восстановление в _user регистры. Детализируя:
LDMxx {R13-R15}^ восстанавливает R13_mode, R14_mode, PC, SPSR_mode->CPSR
LDMxx {R13-R14}^ восстанавливает R13_user, R14_user
Именно так происходит в железе (LPC2119 тоже проверил). Можете проверить. Симулятор же отрабатывает эту команду иначе. Я не вижу ничего незаконного в этой команде поэтому продолжаю считать что в этом случае симулятор явно ошибается.

Даже если в команде явно будет указан регистр SPSR из другого режима. Непонятно только, зачем ассемблер разрешает так писать.

Ассемблер не позволяет их указывать. Это в описании ядра они имеют такие обозначения.

У вас вообще по какому событию происходит переключение?

Планировщик взводит бит программного прерывания в контроллере прерываний.

А для чего или кого вообще пишите?

Для себя :-) Готовлю почву для новых проектов. FreeRTOS не понравилась чрезмерными требованиями к ОЗУ и кривизной написания. scmRTOS использовал в одном проекте на MSP430, понравилась. Из кристаллов под рукой есть макетки с SAM7 и LPC, есть еще ADuС, но на нем пока только пример из иара запускал. Ближайшие 2 проекта будут на ADuC и LPC.

Сообщение отредактировал Сергей Борщ - May 17 2006, 17:01

[GetSmart]

Смотрите, что я нарыл:
(цитата из книжки)
Бит S используется для управления (обновления, по-моему) флагами условий. Если этот бит установлен, флаги условий изменяются в соответствии с результатом выполнения команды. Если этот бит сброшен, состояние флагов условий не меняется. Однако, если при установленном бите S в качестве регистра результата указан R15 производится копирование содержимого SPSR текущего режима в регистр CPSR. Эта возможность используется для восстановления РС и переключения в исходный режим в конце обработки исключительных ситуаций. Не пытайтесь выполнить такую команду в режиме User (System забыли!), поскольку в этом режиме отсутствует регистр SPSR и соответственно результат выполнения этой команды невозможно предсказать.
___________________________
Я так понял, что бит S и есть эта галочка (^). В командах она означает обновление арифметических флагов в CPSR после выполнения команды, если результат не в R15. Если же в R15, то обновится весь CPSR значением из SPSR.
__________________________
Проверил в отладчике IAR 4.20
Команда с битом S типа SUBS R15,R0,R0 перегружает R15 и SPSR копирует в CPSR. А команда SUBS R1,R0,R0 обновляет только арифметические флаги в CPSR.
Команда LDRxx Rx,{R0}^ вообще не меняет регистр CPSR. Тем более, что арифметической операции и нет. Команда LDRxx Rx,{...,R15}^ копирует SPSR в регистр CPSR.
Всё это я проделывал находясь в IRQ режиме, а в SPSR был SYSTEM.
В командах STMxx эта галочка (^) вообще ни на что не влияет, даже если указан R15. Хотя, может и нет. Надо это ещё проверить.
___________________________
А нафига вы её решили использовать без регистра R15 ?

[GetSmart]

Касательно файла Target_LPC2xxx.h

"#define CONTEXT_SWITCH_INT VIC_SW"
- Использовать отдельное прерывание (VIC_SW) не обязательно, если у вас так же прерывать задачу может таймер. Для этого я принудительно вызывал прерывание от таймера такой командой:
VICSoftInt = (1 << VIC_TIMER1)
Внутри обработчика прерывания таймера не забудьте сбросить этот бит, а то зависнет. Если же таймер не переключает задачи, то всё нормально.

Так писать не нужно:
"VICIntEnable |= (1<<CONTEXT_SWITCH_INT);"
Через этот регистр можно только устанавливать биты, но не сбрасывать. Поэтому пишите так:
VICIntEnable = (1<<CONTEXT_SWITCH_INT);

А эта конструкция вообще убьёт всю систему:
"#define BlockContextSwitchMacro() do { \
VICIntEnable &= ~(1<<CONTEXT_SWITCH_INT); \
} while (0) // disable context switching interrupt
"
Для сброса бита разрешения конкретного прерывания есть другой регистр. Надо так:
VICIntEnClear = (1<<CONTEXT_SWITCH_INT);

Кстати, зачем пишите "do {...} while (0)" ???

Для чего timer 0, match 0 используете?

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

Для справки, все свободные биты из 32 источников прерываний можно использовать для своих нужд через регистр VICSoftInt. Специально для этого сделан VIC_SW, но и остальные действуют аналогично. Я проверял. В одной проге аж 4 независимых софт-прерывания зафигачил. Кстати, у меня прерывание, переключающее задачи (которое я приводил) сделано так, что прерывания запрещены очень короткий момент и даже для 100 КГц прерываний ни одного не потеряется!

[GetSmart]

Но все же я настаиваю, что восстановление CPSR происходит только в одном варианте команды: когда стоит крыжик (^) И в списке регистров есть R15(PC). При этом восстанавливаются регистры в банке соотв. режима исключений. Если же в команде стоит крыжик и R15 в списке нет, то восстанавливаются регистры user(system) банка и CSPR не восстанавливается.
Или другими словами: если в списке LDM есть R15, то крыжик означает восстановление CSPR, если R15 нет - то крыжик означает восстановление в _user регистры. Детализируя:
LDMxx {R13-R15}^ восстанавливает R13_mode, R14_mode, PC, SPSR_mode->CPSR
LDMxx {R13-R14}^ восстанавливает R13_user, R14_user
Именно так происходит в железе (LPC2119 тоже проверил). Можете проверить. Симулятор же отрабатывает эту команду иначе. Я не вижу ничего незаконного в этой команде поэтому продолжаю считать что в этом случае симулятор явно ошибается.

Думаю вы правы. Однако у меня симулятор всё как надо сделал. Оказывается в командах LDM и STM когда указан ^ и нет R15 сохраняются и восстанавливаются регистры User/System. Можно даже не переключаться специально в эти режимы. А я и не знал! Команды "LDMFD LR, {R0-LR}^ ; NOP ; ADD LR, LR, #15*4" можно упростить до "LDMFD LR!, {R0-LR}^". У меня в отладчике нормально прошло.

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

Думаю вы правы. Однако у меня симулятор всё как надо сделал. Оказывается в командах LDM и STM когда указан ^ и нет R15 сохраняются и восстанавливаются регистры User/System. Можно даже не переключаться специально в эти режимы. А я и не знал!

Ну вот хоть какая-то польза :-)

Команды "LDMFD LR, {R0-LR}^ ; NOP ; ADD LR, LR, #15*4" можно упростить до "LDMFD LR!, {R0-LR}^". У меня в отладчике нормально прошло.

Нет, нельзя. Если идет ^ и в качестве опроного используется банкируемый регистр то нельзя писать в него обратно и в следующем такте обращаться к нему тоже нельзя. Вот цитата из того же ARM DDI 0029E:

R15 not in list and S bit set (User bank transfer)
For both LDM and STM instructions, the User bank registers are transferred rather
than the register bank corresponding to the current mode. This is useful for saving the
user state on process switches. Base write-back should not be used when this
mechanism is employed.
When the instruction is LDM, care must be taken not to read from a banked register
during the following cycle (inserting a dummy instruction such as MOV R0, R0 after
the LDM will ensure safety).

Да, вот из старого сообщения:

А команды сохранения и восстановления контекста как бы парные (точнее префиксы stmDB и ldmIA). У вас они почему-то одни и те же.

На самом деле это одни и те же команды, разработчики зачем-то дали этим командам по два имени " to support stacks or for other purposes." Так что STMDB == STMFD, LDMIA == LDMFD

[zltigo]

Не сочтите за 'наезд' - работа несомненно полезная! Однако не могу не отметить, что основная прадигма отлично реализованная в scmRTOS на типичном ARM смотрится уже не так привлекательно,
как на AVR с полукилобайтом-килобайтом памяти.

FreeRTOS не понравилась чрезмерными требованиями к ОЗУ и кривизной написания.

В частности по этой причине не смог пройти спокойно мимо вышеотцитированого :-(.
"Кривизну", в виду неопределенности формулировки, оставим в покое (хотя можем и побеседовать - тут
есть подходящие ветки ) а по RAM..
Cобрал Ваш демо проект с тремя светодиодиками:

Код

Module               CODE      DATA      CONST
------               ----      ----      -----
                    (Rel)  (Rel)  (Abs)  (Rel)
?CMAIN                108
?CSTARTUP              56
?EnI_t                 20
?RESET
  + common             60
?_EXIT                 12
?__dbg_break            2
?__exit                18
?cppinit               70
?exit                  14
?segment_init          84
OS_Kernel             300     40
  + shared             32             8     12
OS_Services            16
OS_Target_cpp         272    108
  + shared                            8
main                  478    940    220
scmRTOS_Asm           132
  + common             28
N/A (command line)           768
N/A (alignment)        10
----------          -----  -----    ---     --
Total:              1 624  1 856    236     12
  + common             60

И под FreeRTOS такой-же:

Код

Module               CODE      DATA      CONST
------               ----      ----      -----
                    (Rel)  (Rel)  (Abs)  (Rel)
?CMAIN                 80
?CSTARTUP             476
?DiI_t                 32
?EnI_t                 16
?RESET
  + common             64
?_EXIT                 12
?__exit                 2
?exit                  14
?segment_init          84
?strncpy               44
croutine
  + shared                                  12
heap                  244     24
leds                   76             8
  + shared                            4
list                  174
ll_init                 4
main                  186             8     16
port                  376      4     40     16
portasm               340
tasks                 902    168             8
N/A (command line)           530
N/A (alignment)        10
----------          -----    ---     --     --
Total:              3 072    726     60     52
  + common             64

Собственно разница по декларированному критическому ресурсу (RAM занимаемому ядром) отнюдь не впечатляет:
scmRTOS = 0x148 байт
FreeRTOS = 0x1AC
Итого - 100(dec) байт. Не слишком большая плата за несколько отличающюся базовую функциональность и (личное мнение) за большую способность к доработкам.
Причем, при "необходимости" можно убрать еще по 8 байт на задачу во FreeRTOS :-)

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

Смотрите, что я нарыл:
(цитата из книжки)
___________________________
Я так понял, что бит S и есть эта галочка (^). В командах она означает обновление арифметических флагов в CPSR после выполнения команды, если результат не в R15. Если же в R15, то обновится весь CPSR значением из SPSR.
__________________________

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

Проверил в отладчике IAR 4.20
Команда LDRxx Rx,{R0}^ вообще не меняет регистр CPSR. Тем более, что арифметической операции и нет.

В данном контексте (R15 нет) ^ означает доступ к user-банку. Но поскольку R0 небанкируемый, то в этом конкретном варианте наличие ^ не играет роли.

Команда LDRxx Rx,{...,R15}^ копирует SPSR в регистр CPSR.
Всё это я проделывал находясь в IRQ режиме, а в SPSR был SYSTEM.

Вот тут появляется тонкость, которая не позволила мне восстановить весь контекст одной командой: если в списке есть R15, то ^ означает копирование SPSR в CPSR а не восстановление user-банка. Т.е. значения со стека попадут вместо необходимого мне SP_user, LR_user в SP_irq, LR_irq. Это ответ на

А нафига вы её решили использовать без регистра R15 ?

В командах STMxx эта галочка (^) вообще ни на что не влияет, даже если указан R15. Хотя, может и нет. Надо это ещё проверить.

Влияет. В STM если есть галочка будут сохранены регистры user mode.

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

FreeRTOS не понравилась чрезмерными требованиями к ОЗУ и кривизной написания.

В частности по этой причине не смог пройти спокойно мимо вышеотцитированого :-(.
"Кривизну", в виду неопределенности формулировки, оставим в покое (хотя можем и побеседовать - тут
есть подходящие ветки )

Объясню очень просто: указатели на любой объект передаются как void* что легко позволяет мне передать вместо указателя на семафор указатель на процесс или очередь. Зачем же в "языке высогага уровня Ц" был придуман контроль типов на этапе компиляции? Далее это же void * передается в другие функции место указателя соответствующего типа, а чтобы компилятор не выдавал предупреждения вместо элементарного создания локальной переменной нужного типа и приведения типа

Код

signed portBASE_TYPE xQueueSend( xQueueHandle xQueue, const void *pvItemToQueue, portTickType xTicksToWait )
{
xQueuePtr pxQueue = xQueue;

в описании предлагается задавить предупреждения этого типа в опциях компилятора. Причем предупреждения возникают при компиляции кода самой ОС. Что же это как не кривизна?

а по RAM..

46 байт на битовый семафор мне показалось расточительно. Они его реализуют как очередь из одного элемента нулевого размера. Да и на очередь 46 байт ОЗУ накладных "жаба душит".

Cобрал Ваш демо проект с тремя светодиодиками:
Собственно разница по декларированному критическому ресурсу (RAM занимаемому ядром) отнюдь не впечатляет:
scmRTOS = 0x148 байт
FreeRTOS = 0x1AC
Итого - 100(dec) байт. Не слишком большая плата за несколько отличающюся базовую функциональность и (личное мнение) за большую способность к доработкам.
Причем, при "необходимости" можно убрать еще по 8 байт на задачу во FreeRTOS :-)

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

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

Касательно файла Target_LPC2xxx.h

"#define CONTEXT_SWITCH_INT VIC_SW"
- Использовать отдельное прерывание (VIC_SW) не обязательно, если у вас так же прерывать задачу может таймер. Для этого я принудительно вызывал прерывание от таймера такой командой:
VICSoftInt = (1 << VIC_TIMER1)
Внутри обработчика прерывания таймера не забудьте сбросить этот бит, а то зависнет. Если же таймер не переключает задачи, то всё нормально.

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

Так писать не нужно:
"VICIntEnable |= (1<<CONTEXT_SWITCH_INT);"
Через этот регистр можно только устанавливать биты, но не сбрасывать. Поэтому пишите так:
VICIntEnable = (1<<CONTEXT_SWITCH_INT);
А эта конструкция вообще убьёт всю систему:
"#define BlockContextSwitchMacro() do { \
VICIntEnable &= ~(1<<CONTEXT_SWITCH_INT); \
} while (0) // disable context switching interrupt
"
Для сброса бита разрешения конкретного прерывания есть другой регистр. Надо так:
VICIntEnClear = (1<<CONTEXT_SWITCH_INT);

Каюсь, здесь я промухал. Посыпаю голову окурками :-)

Кстати, зачем пишите "do {...} while (0)" ???

Это долгая история. Сначала увидел такую конструкцию в исходниках линукса и тоже был озадачен. Задал вопрос на сахаре и ReAl мне наглядно объяснил, что поскольку в макрос может быть добавлена еще одна команда то его лучше сразу заключить в {}, но макрос с {} нельзя использовать в лоб в конструкции if(cond) Macro(); else ....; а если добавить do while(0) то смысл не изменится но ограничений уже не будет.

Для чего timer 0, match 0 используете?

Системное время, ОС по нему считает тайм-ауты.

Для справки, все свободные биты из 32 источников прерываний можно использовать для своих нужд через регистр VICSoftInt. Специально для этого сделан VIC_SW, но и остальные действуют аналогично. Я проверял.

Угу, мне об этом говорили. Я, наивный, подумал что в атмеловском SAM7 так же. И тут же получил граблями в лоб - у атмела неиспользуемые биты не реализованы физически, т.е. "атакой, не атакуй...". С тех пор я слегка пуганый, и когда увидел в описании специально заточенный бит подумал "ВОТ!" и глубже решил не копать.

Кстати, у меня прерывание, переключающее задачи (которое я приводил) сделано так, что прерывания запрещены очень короткий момент и даже для 100 КГц прерываний ни одного не потеряется!

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

[zltigo]

Еще раз - я не хоче наступить на горло FreeRTOS, просто мне она субъективно не понравилась.

Это пожалуй главное. Так бывает. Я тоже не в восторге от многого, но идеал при знании потрохов :-)
недостижим, посему начал просто править "под себя" и под свой "вкус". А как "база" максимально устроила.

Объясню очень просто: указатели на любой объект передаются как void*

Ну такуж и на любой. Семафоры ака очередь это отдельная песня и при необходимости иметь оные несомненно буду встраивать 'семафористые' семафоры :-).

Причем предупреждения возникают при компиляции кода самой ОС. Что же это как не кривизна?

Это бардак :-(, такие места правлю, правда "легкой" c "наплевать на warnings" переносимости под разные компиляторы уже гарантировать нельзя.

Более серьезный пример идет в исходнике scmRTOS с сайта автора. Там есть и семафоры и очереди. Если есть желание - можем сравнить.

Нет, особого желания нет. Порядок "платы" ясен и меня совсем не смущают пару сот байт, особенно по отношению к размеру стеков (особенно при отсутствии даже простейших механизмов контроля обьема использования стека присутствующих в FreeRTOS) задач :-(. Кстати о стеках, на штатное (руками и так реализуется без напряга) нововведение FreeRTOS 4.x обратили внимание?

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

Объясню очень просто: указатели на любой объект передаются как void*

Ну такуж и на любой. Семафоры ака очередь это отдельная песня и при необходимости иметь оные несомненно буду встраивать 'семафористые' семафоры :-).

typedef void * xQueueHandle;
typedef xQueueHandle xSemaphoreHandle;
typedef void * xTaskHandle;
Собственно других открытых пользователю сервисов там вроде и нет.

Более серьезный пример идет в исходнике scmRTOS с сайта автора. Там есть и семафоры и очереди. Если есть желание - можем сравнить.

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

Надо будет этот вопрос изучить, спасибо за наводку.

Кстати о стеках, на штатное (руками и так реализуется без напряга) нововведение FreeRTOS 4.x обратили внимание?

Нет, я работал с 3.2.2, как проект сдал больше на FreeRTOS.org не заглядывал. Посмотрю обязательно, спасибо.

[GetSmart]

Команды "LDMFD LR, {R0-LR}^ ; NOP ; ADD LR, LR, #15*4" можно упростить до "LDMFD LR!, {R0-LR}^". У меня в отладчике нормально прошло.

Нет, нельзя. Если идет ^ и в качестве опроного используется банкируемый регистр то нельзя писать в него обратно и в следующем такте обращаться к нему тоже нельзя. Вот цитата из того же ARM DDI 0029E:

Если подумать, то обратная запись в этой команде происходит не в тот регистр, который восстанавливается из стека. Поэтому мне кажется, что всё должно нормально прокатить. А в документе просто не слишком подробно этот момент описан. Он в некотором смысле уникальный. Я бы на вашем месте реально попробовал так упростить и проверить прямо на проце. Тем более, что мой отладчик (IAR 4.20) это проглатил и не подавился.

[zltigo]

typedef void * xQueueHandle;
typedef xQueueHandle xSemaphoreHandle;
typedef void * xTaskHandle;

А здесь-то криминал-то в чем? Совершенно разные типы. Я 'дико извиняюсь', но это
typedef а не define - любой компилятор находясь в твердом уме и здравой памяти обломает
подмену безвариантно.

Нет, я работал с 3.2.2, как проект сдал больше на FreeRTOS.org не заглядывал. Посмотрю обязательно, спасибо.

Кстати :-) обратите внимание, там в переключении контекстов 'nop'-чик недавно добавился...

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

typedef void * xQueueHandle;
typedef xQueueHandle xSemaphoreHandle;
typedef void * xTaskHandle;

А здесь-то криминал-то в чем? Совершенно разные типы. Я 'дико извиняюсь', но это
typedef а не define - любой компилятор находясь в твердом уме и здравой памяти обломает
подмену безвариантно.

Совсем не уверен. Во всяком случае

Код

    int x,y;
    xQueueReceive(&x, &y, 0);

IAR съел молча, хотя int* это совсем не xQueueHandle. И что-то мне казалось что в С это не разные типы а синонимы, это в С++ будут разные типы.

По сравнению объемов мне непонятно откуда такие цифры? Чего-то вы напутали. Заглянул в .map, получил там такое:

Код

OS::Kernel      0x28
IdleProcess     0x6c
Proc1           0x134 ( 8 + 0x12C stack)
Proc2           0x134 ( 8 + 0x12C stack)
Proc3           0x134 ( 8 + 0x12C stack)

Т.е. ядро+Idle занимает 148 байт плюс по 8 байт на каждый процесс. Остальное - стеки прцессов. Счас буду делать аналогичный тест с FreeRTOS, сравню сам. Еще особенность - я не правил .xcl из ИАРовского примера, поэтому возможно погрешность ползет оттуда: в качестве IRQ_STACK в scmRTOS используется CSTACK, да и его размер в .xcl определен как 0x400 что явно замного. Продолжаю эксперименты. Счас попробую замерить время переключения контекстов.

Кстати :-) обратите внимание, там в переключении контекстов 'nop'-чик недавно добавился...

Еще один? :-))

[zltigo]

Совсем не уверен. Во всяком случае

Код

    int x,y;
    xQueueReceive(&x, &y, 0);

IAR съел молча, хотя int* это совсем не xQueueHandle. И что-то мне казалось что в С это не разные типы а синонимы, это в С++ будут разные типы.

Ну начинаем выкручиваться:
1. Амперсандик добавили, спасибо, что не (xQueueHandle) :-)
2. С настройками компилятора разберитесь, ибо я, естественно, как и положено, получил

Код

D:\ARM_WORK\COMMON\LPC2000\rtc.c(107) : Warning[Pe167]: argument of type "int *" is incompatible with parameter of type "xQueueHandle"

По сравнению объемов мне непонятно откуда такие цифры? Чего-то вы напутали. Заглянул в .map, получил там такое:

Тоже из MAP. MAP в тестовом виде прилагается, кстати, был в свое время обрадован IARовским
HTML мапом. Смотрите в приложении:
* MODULE SUMMARY *
Делал только сборку, ничего не менял, на железо не переносил.

Счас буду делать аналогичный тест с FreeRTOS, сравню сам. Еще особенность - я не правил .xcl из ИАРовского примера, поэтому возможно погрешность ползет оттуда: в качестве IRQ_STACK в scmRTOS используется CSTACK, да и его размер в .xcl определен как 0x400 что явно замного.

Это Правильно! Едиственное изменение мною для уравнивания шансов конфигурирось количество приоритетов равное числу задач, ибо так и в scmRTOS. И отключальтись дополнитительные
наворотики. Собственно конфигурация в приложении. На железо заливалось.
Результат возможно будет даже немного лучше при компиляции базовой FreeRTOS, ибо я своего надобавлял.

Счас попробую замерить время переключения контекстов.

Если мне не изменяет память, то я получил на уровне 7us. Но это при ЧЕСТНОМ измерении,
от момента ВНЕШНЕГО а не таймерного прерывания и до проднятия задачи дергающей PIN.
Время это время для FreeRTOS, естественно, не фиксированное. Задач было около 6. Можно
повторить под протокол, но через недельку - болею сейчас.

Еще один? :-))

Если последняя рассматриваеваемая Вами версия была 3.X.X, то помнится да.

[zltigo]

Давайте я Вас еще попытаюсь совлечь c "пути истиного" - TNKernel изучали? Мне весьма понравилось остановило только, что поздновато набрел и под свой вкус надо было сразу шедулер менять -
там он в uCOS стиле, что будет Вам ближе :-). На первый взгляд привлек обильным ASM. Потом оценил скорость FreeRTOS и успокоился. Автор здесь тоже появляется.

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

Сравнил по скорости с FreeRTOS. Тест простой: низкоприоритетный процесс сигналит семафор, более высокоприоритетный его ждет. Код:

Код

/******  FreeRTOS  **********/
static void Task1( void * pvParameters ) {
    for(;;) {
        xSemaphoreTake( xSemaphore, ( portTickType )-1 );
        off(LED0);
    }
}
static void Task2( void * pvParameters ) {
    for(;;) {
        on(LED0);
        xSemaphoreGive( xSemaphore );
    }
}
void main( void ) {
    prvSetupHardware();

    vSemaphoreCreateBinary( xSemaphore );
    xTaskCreate( Task1, "Task1", 300, 0, tskIDLE_PRIORITY + 2, ( xTaskHandle * ) NULL );
    xTaskCreate( Task2, "Task2", 300, 0, tskIDLE_PRIORITY + 1, ( xTaskHandle * ) NULL );

    vTaskStartScheduler();
}
/******** scmRTOS   ***********/
OS_PROCESS void TProc1::Exec() {
    for(;;)
    {
        ef.Wait();
        off(LED0);
    }
}
OS_PROCESS void TProc2::Exec() {
    for(;;)
    {
        on(LED0);
        ef.Signal();
    }
}

Результат (частота 49,152МГц):

Код

   ОС            светодиод горит             светодиод не горит
FreeRTOS THUMB         59 мкс                      35 мкс
FreeRTOS ARM          не компилится согласно документации
scmRTOS  THUMB         7.5 мкс                     7.5 мкс
scmRTOS  ARM            5 мкс                       5 мкс

При этом семафор в scmRTOS занимает 4 байта в FreeRTOS - 76, процесс занимает 4 байта + стек, в FreeRTOS - 76 + стек. Сколько ОЗУ требует ядро FreeRTOS я не искал.

Совсем не уверен. Во всяком случае

Код

    int x,y;
    xQueueReceive(&x, &y, 0);

IAR съел молча, хотя int* это совсем не xQueueHandle. И что-то мне казалось что в С это не разные типы а синонимы, это в С++ будут разные типы.

Ну начинаем выкручиваться:
1. Амперсандик добавили, спасибо, что не (xQueueHandle) :-)

результат &x где x-int имеет тип *int, так что не принимается.

2. С настройками компилятора разберитесь, ибо я, естественно, как и положено, получил

Вот тут да. Согласно рекомендациям в поле suppress those warnings стоит pe815, pe191, pa082, pe167. Заметьте, не я их туда поставил а авторы FreeRTOS.

По сравнению объемов мне непонятно откуда такие цифры? Чего-то вы напутали. Заглянул в .map, получил там такое:

Тоже из MAP. MAP в тестовом виде прилагается, кстати, был в свое время обрадован IARовским
HTML мапом. Смотрите в приложении:

Понял, спасибо. Буду посмотреть.

Счас попробую замерить время переключения контекстов.

Если мне не изменяет память, то я получил на уровне 7us. Но это при ЧЕСТНОМ измерении,
от момента ВНЕШНЕГО а не таймерного прерывания и до проднятия задачи дергающей PIN.
Время это время для FreeRTOS, естественно, не фиксированное. Задач было около 6. Можно
повторить под протокол, но через недельку - болею сейчас.

нда, такой эксперимент я не проводил, может завтра рискну. О своих результатах написал чуть выше.
P.S. к семинару Тексаса выздоровишь (24-го)?

[zltigo]

При этом семафор в scmRTOS занимает 4 байта в FreeRTOS - 76, процесс занимает 4 байта + стек, в FreeRTOS - 76 + стек.

Ваше неравнодушие к семафорам я уже заметил :-)

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

Давайте я Вас еще попытаюсь совлечь c "пути истиного" - TNKernel изучали? Мне весьма понравилось остановило только, что поздновато набрел и под свой вкус надо было сразу шедулер менять -
там он в uCOS стиле, что будет Вам ближе :-). На первый взгляд привлек обильным ASM. Потом оценил скорость FreeRTOS и успокоился. Автор здесь тоже появляется.

Нет, не изучал. Я в свое время портировал ОС CREx от компилятора Introl с мотороллера HC12 на MSP430. Тоже вся на асме была. функциональность примерно как у FreeRTOS - т.е. динамическое создание/удаление процессов, семафоров и прочего. Ошибки вылавливал долго. Потом с Гарри сравнили время переключения контекста с scmRTOS и я забросил CREx в архив :-) И вообще стараюсь с асмом поменьше связываться. Перефразируя принцип IBM "Компилятор должен работать, а я - думать". Первый проект на ARMe сделал на чистом С и про ядро начал читать и асм изучать только сейчас когда переключатель задач писал.

[zltigo]

[quote name='Сергей Борщ' date='May 18 2006, 18:14' post='114555']
1. Амперсандик добавили, спасибо, что не (xQueueHandle) :-)
[quote]
результат &x где x-int имеет тип *int, так что не принимается.
[/quote]
[/quote]
Дело не в размерности а в том, что ДВАЖДЫ нужно ошибится. И параметр не тот подсунуть и
амперсандик добавить.

[quote]
Вот тут да. Согласно рекомендациям в поле suppress those warnings стоит pe815, pe191, pa082, pe167. Заметьте, не я их туда поставил а авторы FreeRTOS.
[/quote]
А я такие "рекомендации" сразу игнорирую - для начала прагмы по конкретным местам, потом
разборки. С наличием такого типа халтуры я уже ранее сразу согласился :-(

[qoute]
P.S. к семинару Тексаса выздоровишь (24-го)?
[/quote]
Не собираюсь на семинар. Но встретится можно и без этого повода.

[zltigo]

Ошибки вылавливал долго. Потом с Гарри сравнили время переключения контекста с scmRTOS и я забросил CREx в архив :-)

Так под IAR платформу scmRTOS очень к месту. Порт для молотилок типа DSP тоже логичен -
наверное даже использую к осени.
C ARM, вот что делать.... Скорость уже тяготит мало, RAM - вполне терпимо. FLASH - вообще без
проблем. И на первое место для меня выходит функциональность.

И вообще стараюсь с асмом поменьше связываться.

После написания в свое время на ASM проекта под 200K кода и исходными текстами сравнимыми
по объему с парой томов "Войны и Мира" - я думаю аналогично :-)
На ASM намекал только с точки зрения 'почитать', кроме того, она далеко не вся на ASM -
просто несколько более критических мест на ASM написаны по сравнеию с более распростаненными.

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

При этом семафор в scmRTOS занимает 4 байта в FreeRTOS - 76, процесс занимает 4 байта + стек, в FreeRTOS - 76 + стек.

Ваше неравнодушие к семафорам я уже заметил :-)

Хорошо, очередь требует 8 байтов накладных расходов :-)

[GetSmart]

2 Сергей Борщ
Когда закончите доводить до ума свою ОСь, надеюсь выложите по изначально обозначенной ссылке. А вообще, неплохо. Я своё детище тоже написал через 3 месяца после знакомства с армом. И тоже стараюсь всё писать на Си, только самые критические участки на асме.

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

2 Сергей Борщ
Когда закончите доводить до ума свою ОСь, надеюсь выложите по изначально обозначенной ссылке. А вообще, неплохо. Я своё детище тоже написал через 3 месяца после знакомства с армом. И тоже стараюсь всё писать на Си, только самые критические участки на асме.

Ось не моя, а порт будет выложен на scmRTOS.narod.ru

[zltigo]

FreeRTOS THUMB 59 мкс 35 мкс
FreeRTOS ARM не компилится согласно документации

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

Код

/* Constants required to setup the initial stack. */
#if __CPU_MODE__ == 1         // zlt[      
#define portINITIAL_SPSR                ( ( portSTACK_TYPE ) 0x3F ) // System mode, THUMB mode, Interrupts enabled.
#endif                      //]zlt

#if __CPU_MODE__ == 2        // zlt[
#define portINITIAL_SPSR                ( ( portSTACK_TYPE ) 0x1F ) // System mode, ARM mode, Interrupts enabled.
#endif                      //]zlt

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

FreeRTOS THUMB 59 мкс 35 мкс
FreeRTOS ARM не компилится согласно документации

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

Ну что сказать? Полез я снова читать доку и вынужден признать что Вы правы: мне в голову запала фраза из доки: It should be noted that some of the macros defined in portmacro.h can only be called from ARM mode code, and use from THUMB code will result in a compile time error.
В принципе я где-то прав. Согласно этой фразе собрать весь проект в чистом ARM не получится. Решил я посмотреть что за ошибки. Скомпилилось без ошибок, ничего криминального в тех макросах не нашел. Да, portINITIAL_SPSR пришлось дописать руками. Но в целом свою фразу насчет "не компилится" беру взад, однако Вы сами признали, что без "доработки напильником" и не работает. Заодно каюсь - вчера измерял вариант Flash Debug, т.е. без оптимизации. Сегодня подправил переключение контекста в своем порте (теперь и симулятор и железо живут одинаково, да и скорость поднял) и попробовал разные варианты оптимизации, результат такой:

Код

   ОС                       светодиод горит             светодиод не горит
FreeRTOS THUMB (Size, max)        67 мкс                      33 мкс
FreeRTOS ARM   (Size, max)        62 мкс                      35 мкс
scmRTOS  THUMB (Size, max)        6.3 мкс                     6.3 мкс
scmRTOS  ARM   (Size, max)        4.6 мкс                     4.6 мкс

FreeRTOS THUMB (Speed, max)       65 мкс                      33 мкс
FreeRTOS ARM   (Speed, max)       58 мкс                      35 мкс
scmRTOS  THUMB (Speed, max)       6.3 мкс                     6.3 мкс
scmRTOS  ARM   (Speed, max)       4.6 мкс                     4.6 мкс

[zltigo]

It should be noted that some of the macros defined in portmacro.h can only be called from ARM mode code, and use from THUMB code will result in a compile time error.
В принципе я где-то прав. Согласно этой фразе собрать весь проект в чистом ARM не получится.

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

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

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

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

Ну и тестов нужно больше хороших и разных, кроме любимого теста от автора scmRTOS.

Если есть желание можем сравнивать. Жду предложений.

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

Прикрепленные файлы

 scmRTOS_ARM.zip ( 53.12 килобайт ) Кол-во скачиваний: 134

 

[zltigo]

Если есть желание можем сравнивать. Жду предложений.

Надо будет заняться безотносительно к scmRTOS, правда со временем похоже будет изрядно туго,
когда на работу выберусь. Быстро не обещаю.
Ну а быстренько и Вашими руками, то можно быстренько вместо ОТСУТСТВУЕЩЕГО во FreeRTOS
семафора сваять аналогичную моргалку на банальном флаге - это просто даст заметно более приближенную к реальной оценку именно шедулера и переключателя задач.

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

Если есть желание можем сравнивать. Жду предложений.

Ну а быстренько и Вашими руками, то можно быстренько вместо ОТСУТСТВУЕЩЕГО во FreeRTOS
семафора сваять аналогичную моргалку на банальном флаге

Или что-то недопонял или в FreeRTOS флагов тоже не нашел. Можно хотябы в общих словах пример кода, я его погоняю.

[sergeeff]

Я давно приглядываюсь к scmRTOS применительно к ARM. На работе текучка одолела – совершенно невозможно заняться чем-то впрок.

Но есть соображение насчет скорости работы scheduler’а. Поиск текущей приоритетной задачи осуществляется простым перебором бит в слове состояния процессов. Очевидно, что время поиска прямо пропрционально номеру приоритета, что не есть хорошо. Есть классная функция, оптимизированная для ARM, которая выдает номер младшего установленного бита в 32-разрядном слове (она используется в Linux’e и TNKernel). Вот ее текст:
ffs_asm:

;-- Standard trick to isolate bottom bit in r0 or 0 if r0 = 0 on entry
rsb r1, r0, #0
ands r0, r0, r1


;-- now r0 has at most one set bit, call this X
;-- if X = 0, all further instructions are skipped

adrne r2, .L_ffs_table
orrne r0, r0, r0, lsl #4 ; r0 = X * 0x11
orrne r0, r0, r0, lsl #6 ; r0 = X * 0x451
rsbne r0, r0, r0, lsl #16 ; r0 = X * 0x0450fbaf

;-- now lookup in table indexed on top 6 bits of r0
ldrneb r0, [ r2, r0, lsr #26 ]
bx lr

.L_ffs_table:
;-- 0 1 2 3 4 5 6 7
.data.b 0, 1, 2, 13, 3, 7, 0, 14 ; 0- 7
.data.b 4, 0, 8, 0, 0, 0, 0, 15 ; 8-15
.data.b 11, 5, 0, 0, 9, 0, 0, 26 ; 16-23
.data.b 0, 0, 0, 0, 0, 22, 28, 16 ; 24-31
.data.b 32, 12, 6, 0, 0, 0, 0, 0 ; 32-39
.data.b 10, 0, 0, 25, 0, 0, 21, 27 ; 40-47
.data.b 31, 0, 0, 0, 0, 24, 0, 20 ; 48-55
.data.b 30, 0, 23, 19, 29, 18, 17, 0 ; 56-63
Очевидно имеем констатное время поиска номера младшего установленного бита в слове.

Думаю полезно эту функцию использовать вместо стандартного решения.

[ig_z]

2 Сергей Борщ

Посмотрел ваш порт, сходу возник архитектурный вопрос.
Почему для контекст свитчера вы выбрали ВИК-СВ а не просто СВИ, были какие то особые причины? СВИ - ядерная часть и поэтому есть у всех, а ВИК - периферия, имеет право и не быть в кристалле.

[sergeeff]

Да. Еще про critical section. Твой вариант запрета/разрешения прерываний не очень безопасный вариант (см. Atmel Application Note Rev. 1156A–08/98) и лучше это сделать так, как сделано в UCOS порте для ARM:
;------------------------------------------------------------------------------
;- Function : unsigned int EnterCritical(void)
;- Treatments : Secure Disable All Interrupt (Atmel rev.1156A) and
; return irq status for disable interrupt
;------------------------------------------------------------------------------
EXPORT EnterCritical

EnterCritical PROC
MRS r0,CPSR ; Set IRQ and FIQ bits in CPSR to disable all interrupts
ORR r1,r0,#NO_INT
MSR CPSR_c,r1
MRS r1,CPSR ; Confirm that CPSR contains the proper interrupt disable flags
AND r1,r1,#NO_INT
CMP r1,#NO_INT
BNE EnterCritical ; Not properly disabled (try again)
mov pc, lr ; return in R0 - saved interrupt status


;------------------------------------------------------------------------------
;- Function : void ExitCritical(unsigned int IrqStatus)
;- Treatments : restore irq status, saved by function EnterCritical() (Atmel rev.1156A)
;------------------------------------------------------------------------------
EXPORT ExitCritical

ExitCritical PROC
MSR CPSR_c, r0
mov pc, lr

Работает дольше, но безопаснее

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

Я давно приглядываюсь к scmRTOS применительно к ARM. На работе текучка одолела – совершенно невозможно заняться чем-то впрок.

Но есть соображение насчет скорости работы scheduler’а. Поиск текущей приоритетной задачи осуществляется простым перебором бит в слове состояния процессов. Очевидно, что время поиска прямо пропрционально номеру приоритета, что не есть хорошо. Есть классная функция, оптимизированная для ARM, которая выдает номер младшего установленного бита в 32-разрядном слове (она используется в Linux’e и TNKernel). Вот ее текст:
Думаю полезно эту функцию использовать вместо стандартного решения.

Отлично! Гарри как раз спрашивал, если такая аппаратная функция в ARM. Обязательно добавлю.

Посмотрел ваш порт, сходу возник архитектурный вопрос.
Почему для контекст свитчера вы выбрали ВИК-СВ а не просто СВИ, были какие то особые причины? СВИ - ядерная часть и поэтому есть у всех, а ВИК - периферия, имеет право и не быть в кристалле.

Дело в том, что SWI всем хороша кроме одного - она исполняется независимо от того - разрешены прерывания или нет. Когда переключение вызывается из потока проблем нет, а вот когда из прерывания возникают сложности - обработчик прерывания уже наложил в стек своей информации. Идеология scmRTOS предполагает, что при возникновении необходимости переключения контекста внутри обработчика прерывания взводится запрос на переключение а собственно прерывание переключателя вызывается в момент выхода из обработчика, когда разрешаются глобальные прерывания и стек содержит только данные текущего потока. Я подумывал о использовании SWI при вызове из потока и "честного" прерывания при переключении в обработчике прерывания, но это потребовало бы изменения "непортируемой" части ОС, хотя и ускорило бы переключение. В общем я пока в раздумье. Есть идеи?

Да. Еще про critical section. Твой вариант запрета/разрешения прерываний не очень безопасный вариант (см. Atmel Application Note Rev. 1156A–08/98) и лучше это сделать так, как сделано в UCOS порте для ARM:
...........
Работает дольше, но безопаснее

Спасибо, не знал (только начинаю ARM осваивать). Изучу и учту. Собственно ради таких замечаний и открыл это обсуждение.

Сообщение отредактировал Сергей Борщ - May 20 2006, 17:52

[ig_z]

Посмотрел ваш порт, сходу возник архитектурный вопрос.
Почему для контекст свитчера вы выбрали ВИК-СВ а не просто СВИ, были какие то особые причины? СВИ - ядерная часть и поэтому есть у всех, а ВИК - периферия, имеет право и не быть в кристалле.

Дело в том, что SWI всем хороша кроме одного - она исполняется независимо от того - разрешены прерывания или нет. Когда переключение вызывается из потока проблем нет, а вот когда из прерывания возникают сложности - обработчик прерывания уже наложил в стек своей информации. Идеология scmRTOS предполагает, что при возникновении необходимости переключения контекста внутри обработчика прерывания взводится запрос на переключение а собственно прерывание переключателя вызывается в момент выхода из обработчика, когда разрешаются глобальные прерывания и стек содержит только данные текущего потока. Я подумывал о использовании SWI при вызове из потока и "честного" прерывания при переключении в обработчике прерывания, но это потребовало бы изменения "непортируемой" части ОС, хотя и ускорило бы переключение. В общем я пока в раздумье. Есть идеи?

Если я правильно понимаю - SWI имеет 6-й наинизший приоритет, поэтому не может прерывать FIQ (3) IRQ (4). Иначе вообще не понятно, зачем нужны софт прерывания.

Да. Еще про critical section. Твой вариант запрета/разрешения прерываний не очень безопасный вариант (см. Atmel Application Note Rev. 1156A–08/98) и лучше это сделать так, как сделано в UCOS порте для ARM:
...........
Работает дольше, но безопаснее

Спасибо, не знал (только начинаю ARM осваивать). Изучу и учту. Собственно ради таких замечаний и открыл это обсуждение.

Возможно достаточно использовать интринсики __disable_interrupt __enable_interrupt. Соответствуют рекомендациям АРМ. Но они вроде бы не инлайнятся.

[Dainis]

Почему для контекст свитчера вы выбрали ВИК-СВ а не просто СВИ, были какие то особые причины? СВИ - ядерная часть и поэтому есть у всех, а ВИК - периферия, имеет право и не быть в кристалле.
Если я правильно понимаю - SWI имеет 6-й наинизший приоритет, поэтому не может прерывать FIQ (3) IRQ (4). Иначе вообще не понятно, зачем нужны софт прерывания.

SWI единственный коректный способ вызова SYSTEM (protected) режима или функций от USER режима.

[GetSmart]

SWI единственный коректный способ вызова SYSTEM (protected) режима или функций от USER режима.

Можно узнать почему?
_____________________
Кстати, если откуда-то вызывается критическая секция, то смысла её вызывать из USER нет никакого. Всё-равно прерывания не запретятся. Именно на этот счёт так усложнилась процедура их запрещения. Хотя пользы от неё почти никакой. Сразу задача зависнет.

Возможно достаточно использовать интринсики __disable_interrupt __enable_interrupt. Соответствуют рекомендациям АРМ. Но они вроде бы не инлайнятся.

Не инлайнятся потому, что работают только а ARM-режиме и чтобы их выполнить из THUMB нужно вызвать ARM-процедуру (__disable_interrupt) и вернуться обратно. __disable_interrupt тоже завесит задачу если её вызвать из USER.

Хотя если... если очень постараться, то можно. Можно запрещать прерывания USER-режима переключаясь в SYSTEM, а потом обратно. Например через тот же SWI. Но это будет ещё медленней (немного).

Сообщение отредактировал GetSmart - May 21 2006, 12:31

[zltigo]

Можно хотябы в общих словах пример кода, я его погоняю.

Думаю сам все сделаю через недельку и доложу. Пока начал немножко ядрышко подчищать :-),
в том числе в части critical section для ядра и для приложений.

Не инлайнятся потому, что работают только а ARM-режиме и....

C Thumb дело ясное, но IAR какое-то темноватое дело получается :-( __disable_interrupt()
не инлайнится и в ARM mode, хотя должна.

Возможно достаточно использовать интринсики __disable_interrupt

Достаточно, в __disable_interrupt() именно такой код 'с контролем' и заложен, вопрос только в том,
нужны-ли эти выкрутасы не для Atmel-овских чипов. Кроме того, не совсем ясно, нужны-ли эти
выкрутасы не при одновременном запрещении IRQ и FIQ.
Еще к размышлению - а почему в порте только IRQ запрещаются? Если использовать исключительно для использования в ядре, то можно подумать и о варианте (скорость?) блокировки только таймерного прерывания. Но тупое-полное для приложений тоже реализовано должно быть.

[GetSmart]

вопрос только в том,
нужны-ли эти выкрутасы не для Atmel-овских чипов. Кроме того, не совсем ясно, нужны-ли эти
выкрутасы не при одновременном запрещении IRQ и FIQ.

А причём тут Атмел? Это "выкрутасы" для стандартного АРМ-ядра нужны. Вышепроцитированная проверка делается только для USER-режима, в котором нельзя запрещать прерывания. Это не связано с "глюками" процов. Там немного другие проверки. Есть такой глюк, когда при одновременном запрещении IRQ и FIQ может сработать в последний момент прерывание, но в этом порте как я понял FIQ вообще не используется и либо нужно придумать ещё одну особую критическую секцию, либо оставить всё на совести пользователя. А на переключение контекстов они вроде как не влияют.

[zltigo]

А причём тут Атмел?

У других жалоб не встречал.

Это "выкрутасы" для стандартного АРМ-ядра нужны.

Я дважды натыкался на комментарии типа такого:

Код

        mrs    r0,CPSR
        orr    r1,r0,#NOINT
        msr    CPSR_c,r1
;-- Atmel add-on
        mrs    r1,CPSR             ;-- Check CPSR for correct contents
        and    r1,r1,#NOINT
        cmp    r1,#NOINT
        bne    tn_cpu_save_sr      ;-- Not disabled - loop to try again
;--------
        mov    pc, lr

Ссылка на источник от _ARM_ есть?

Вышепроцитированная проверка делается только для USER-режима, в котором нельзя запрещать прерывания.

О чем Вы это? Когда нельзя - тогда НЕЛЬЗЯ! А тут элементарный контроль на то, что флаги установились.

но в этом порте как я понял FIQ вообще не используется и либо нужно придумать ещё одну особую критическую секцию, либо оставить всё на совести пользователя. А на переключение контекстов они вроде как не влияют.

Ага, не влияют - я, например, из обработчика FIQ какой-нибудь семафорчик (Signal) дерну, который шедулер за собой потянет...

[GetSmart]

Самая близкая по смыслу цитата из <arm7tdmi.pdf>:

3.9.5 IRQ
The IRQ (Interrupt Request) exception is a normal interrupt caused by a LOW level on
the nIRQ input. IRQ has a lower priority than FIQ and is masked out when a FIQ
sequence is entered. It may be disabled at any time by setting the I bit in the CPSR,
though this can only be done from a privileged (non-User) mode.

- самый конец цитаты.
Хотя весь файл напичкан ограничениями в USER-режиме. Вообще, все эти заморочки стоит учитывать если Ось (порт) будет выполняться в этом режиме. Если же нет, то и заморачиваться не стоит.

О чем Вы это? Когда нельзя - тогда НЕЛЬЗЯ!

Ну дак это же не убьёт процессор. Просто команда выполнится в холостую. Для этого и проверка, чтобы у USER-проги и желания такого не возникало. Чисто через SYSTEM. А иначе - "висеть вам вечно".

Ага, не влияют - я, например, из обработчика FIQ какой-нибудь семафорчик (Signal) дерну, который шедулер за собой потянет...

Я ведь написал - на совести пользователя. Хотя в FIQ делать что-то сложное и вызывать систему вообще не рекомендуется. Так, по-быстренькому обратиться к портам или переменным и назад.

Сообщение отредактировал GetSmart - May 21 2006, 19:14

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

Завтра (в понедельник) буду изучать все это вдумчиво. Пока быстрый ответ такой:
1) приложение исполняется в System mode чтобы можно было запрещать/разрешать прерывания не задействуя SWI с разбором кода команды и ветвлением на функции запрета/разрешения/прочего.
2) FIQ не запрещется ибо предполагается что на то оно и быстрое чтобы из него сервисы ОС не вызывались.
3) __disable_interrupt()/__enable_interrupt() не используются именно потому что запрещает и IRQ и FIQ (см. п. 2).
4) Не разобрался до конца со SWI но мне кажется что если его вызвать внутри обработчика IRQ то проц уйдет в исключение SWI если не сразу то в момент переключения в System mode при разрешении вложенных прерываний. Буду изучать детальнее.
5) Идея при входе в критическую секцию запрещать не все прерывания а только прерывание переключения контекста была мною предложена автору scmRTOS недели 2-3 назад, он ее пока думает.

Сообщение отредактировал Сергей Борщ - May 21 2006, 19:43

[GetSmart]

1,2,3 - OK
4. Как только в коде (даже в IRQ, и даже при запрещённых прерываниях) встречается SWI, то сразу вызывается обработчик SWI. В этом смысле у неё нет никаких приоритетов.

[zltigo]

Просто команда выполнится в холостую. Для этого и проверка, чтобы у USER-проги и желания такого не возникало.

А посмотреть на исходник и почитать Аtmel-овский AN (кстати посвященный отнюдь не ядру
а периферии )

Хотя в FIQ делать что-то сложное и вызывать систему вообще не рекомендуется. Так, по-быстренькому обратиться к портам или переменным и назад.

C чего-бы это вдруг (это если безотносительно к ограничениям конкретной реализации чего-либо).
Совершенно нормальный источник. Даже "Быстрый". По крайней мере приоритетный и со своим
стеком, что позволяет без дополнительных наворотов вложенность в обычные IRQ реализовывать.

[zltigo]

2) FIQ не запрещется ибо предполагается что на то оно и быстрое чтобы из него сервисы ОС не вызывались.
4) Не разобрался до конца со SWI но мне кажется что если его вызвать внутри обработчика IRQ то проц уйдет в исключение SWI если не сразу то в момент переключения в System mode при разрешении вложенных прерываний. Буду изучать детальнее.
5) Идея при входе в критическую секцию запрещать не все прерывания а только прерывание переключения контекста была мною предложена автору scmRTOS недели 2-3 назад, он ее пока думает.

2) Я тоже склонился к такой мысли в процессе "подгонки под себя" FreeRTOS.
Однако при этом остался открытый вопрос с ритуальными плясками от Atmel :-( пока оставлены
из исходя принципа "береженого бог бережет".
4) Сразу. А какие проблемы предполагаются?
5) Это я, как вариант, у себя сделал, тем более во FreeRTOS были уже заложены два отдельных,
но одинаково определенных вызова. Но использовать скорее всего не буду - у меня чаще всего
источник системного прерывания переключается на внешний в процессе работы.

[GetSmart]

А посмотреть на исходник и почитать Аtmel-овский AN (кстати посвященный отнюдь не ядру, а периферии )

У-у-у. А с каких пор CPSR стал периферией?
Хотя если дадите ссылку, то прочту.

Совершенно нормальный источник. Даже "Быстрый". По крайней мере приоритетный и со своим
стеком, что позволяет без дополнительных наворотов вложенность в обычные IRQ реализовывать.

Для таких как вы, придётся делать ещё одну критическую секцию "spatial for FIQ".

Сообщение отредактировал GetSmart - May 21 2006, 20:39

[zltigo]

У-у-у. А с каких пор CPSR стал периферией?
Хотя если дадите ссылку, то прочту.

Не стал, но завязан :-(
А AIC уже в официальных Atmel-овских бумагах выступает как периферия ядра.

Ссылка на единственный источник:
http://www.atmel.com/dyn/resources/prod_do...nts/DOC1156.PDF

[GetSmart]

Не стал, но завязан :-(
А AIC уже в официальных Atmel-овских бумагах выступает как периферия ядра.

Ну и ничего нового не узнал. :-( Смысл ПДФ-а в том, что внутри обработчиков исключений нужно осторожно анализировать/менять регистр SPSR, или по-другому - писать нормально обработчики прерываний. Там вообще ситуация, когда внутри обработчика в регистре SPSR какой-то дурень принудительно разрешает прерывания. Это делать просто не надо. Ни у меня, ни у Сергея Борща такого изврата нет. Глюк-то не периферийный, а программный. Точнее криво-программный.
Кстати, это не только для Атмела, но и в LPC такая же бяка.

[zltigo]

Ну и ничего нового не узнал.

Тем не менее как-то Ваши обьяснения на мой взгляд совсем не совпадали с причинами изложенными
в документе, ну да бог с ними.
Первопричина - в задержке блокировки прерываний на такт после изменения CPSR.
В этот такт может попасть обработчик прерывания, что не страшно, ну обработается. Проблемы
если обработчик разрешит и не запретит по выходу прерывания. Такое просто делать не надо.

Выводы - на прибамбасы в __disable_interrupts() наплевать и забыть.....

Кстати, это не только для Атмела, но и в LPC такая же бяка.

Похоже :-(. Косвенное подтверждение этому можно получить из описания процесса организации вложенных прерываний на LPC.

[amusin]

Есть классная функция, оптимизированная для ARM, которая выдает номер младшего установленного бита в 32-разрядном слове (она используется в Linux’e и TNKernel). Вот ее текст:
...
Очевидно имеем констатное время поиска номера младшего установленного бита в слове.
Думаю полезно эту функцию использовать вместо стандартного решения.

Мысль (именно в приложении к шедулингу) очень здравая. Только приведенный код можно реализовать и на Си (например, первые 2 команды - выделение младшей единички на Си x&(-x))
C точки зрения алгоритмов здесь суть найти число нулей справа
(при #define scmRTOS_PRIORITY_ORDER 0 конечно).

Реализаций этой функции - море: http://www.hackersdelight.org/HDcode/ntz.cc

Для другого порядка приоритетов в карте
#define scmRTOS_PRIORITY_ORDER 1 надо использовать функции из
http://www.hackersdelight.org/HDcode/nlz.cc

[amusin]

Отлично! Гарри как раз спрашивал, если такая аппаратная функция в ARM. Обязательно добавлю.

Нет в АРМ такой инструкции. Взгляни, например, на команду PRIOR в C166
http://www.keil.com/dd/docs/datashts/infineon/c166ism.pdf

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

Отлично! Гарри как раз спрашивал, если такая аппаратная функция в ARM. Обязательно добавлю.

Нет в АРМ такой инструкции.

Я так и ответил :-)

[aaarrr]

Нет в АРМ такой инструкции. Взгляни, например, на команду PRIOR в C166
http://www.keil.com/dd/docs/datashts/infineon/c166ism.pdf

Есть у ARM такая инструкция, правда, начиная с архитектуры V5 - CLZ называется.

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

Спасибо всем, кто подсказал функцию поиска наиболее приоритетного процесса. Просмотрел все варианты на http://www.hackersdelight.org/HDcode/ntz.cc, наиболее эффективно компилится вариант подсказанный sergeeff за счет замены + на |. Теперь пытаюсь разобраться как оно работает чтобы написать такую же но для x = 8 и 16 бит. Кто-нибудь такое делал?

Сообщение отредактировал Сергей Борщ - May 22 2006, 11:34

[amusin]

Теперь пытаюсь разобраться как оно работает чтобы написать такую же но для x = 8 и 16 бит. Кто-нибудь такое делал?

А нафиг? GetHighPriority() лежит в порте ОС, т.е. предназначена именно для ARM. Сделать внутри этой функции static_cast аргумента для ntz (на взгляд профана в С++) - из большей корзины не выпадет, а для nlz из результата вычесть 8 или 24 внутри препроцессорных #if #else.

Сообщение отредактировал amusin - May 22 2006, 11:50

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

Теперь пытаюсь разобраться как оно работает чтобы написать такую же но для x = 8 и 16 бит. Кто-нибудь такое делал?

А нафиг? GetHighPriority() лежит в порте ОС, т.е. предназначена именно для ARM. Сделать внутри этой функции static_cast аргумента для ntz (на взгляд профана в С++) - из большей корзины не выпадет, а для nlz из результата вычесть 8 или 24 внутри препроцессорных #if #else.

Просто в зависимости от количества процессов аргумент для ntz 8, 16 или 32 бит. Или не морочить голову - вроде много тут уже не наэкономить?

[IgorKossak]

Просто в зависимости от количества процессов аргумент для ntz 8, 16 или 32 бит. Или не морочить голову - вроде много тут уже не наэкономить?

Вот именно!
Вознёй с 8 и 16-битными вариантами можно только замедлить работу.

[sergeeff]

Да, конечно, для ARM надо сделать количество процессов - 32. Будет проще и быстрее.

[amusin]

Да, конечно, для ARM надо сделать количество процессов - 32. Будет проще и быстрее.

Кол-во процессов scmRTOS_PROCESS_COUNT надо делать таким, сколько требуется, и не больше, т.к. внутри void OS::TKernel::SystemTimer() есть цикл for(byte i = 0; i < scmRTOS_PROCESS_COUNT; i++).Другое дело, что может быть действительно сделать TProcessMap 32-разрядным, хотя это и не вписывается в идеологию scmRTOS об экономии ОЗУ .
Как вариант, ширину TProcessMap можно сделать по потребности, а ее уже приводить к 32 разрядам внутри GetHighPriority(), если позволит компилятор.

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

Да, конечно, для ARM надо сделать количество процессов - 32. Будет проще и быстрее.

Кол-во процессов scmRTOS_PROCESS_COUNT надо делать таким, сколько требуется, и не больше, т.к. внутри void OS::TKernel::SystemTimer() есть цикл for(byte i = 0; i < scmRTOS_PROCESS_COUNT; i++).Другое дело, что может быть действительно сделать TProcessMap 32-разрядным, хотя это и не вписывается в идеологию scmRTOS об экономии ОЗУ .
Как вариант, ширину TProcessMap можно сделать по потребности, а ее уже приводить к 32 разрядам внутри GetHighPriority(), если позволит компилятор.

Да, так и будем делать - размер TProcessMap минимально необходимый. Про 32 процесса с Гарри утрясли, про GetHighPriority() - для кол-ва процессов меньше 7 сделаю табличный метод - размер таблицы будет те же 64 байта для 6 процессоа, для меньшего кол-ва соответственно меньше.

Беру тайм-аут до выходных - в пятницу надо изделие на выставку отправлять а софт еще процентов на 40 написан.

[sergeeff]

Пара соображений по поводу быстродействия. Я эту идею уже как-то Harry предлагал, но он посчитал это изменение не слишком принципиальным. Тем не менее, считаю целесообразным переписать пару функций, которые многократно вызываются в ядре и scheduler’e:

void SetPrioTag(TProcessMap& pm, const byte pr) { pm |= 1 << pr; }
void ClrPrioTag(TProcessMap& pm, const byte pr) { pm &= ~(1 << pr); }

Эти две функции выполняются быстрее (короче аналога на одну команду) и отпадает необходимость в массиве TProcessMap PrioMaskTable[scmRTOS_PROCESS_COUNT+1] и функции TProcessMap GetPrioTag(const byte pr) const { return PrioMaskTable[pr]; }.

Выигрыш не велик – но все же – короче и быстрее.

[IgorKossak]

...Выигрыш не велик – но все же – короче и быстрее.

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

[dxp]

void SetPrioTag(TProcessMap& pm, const byte pr) { pm |= 1 << pr; }
void ClrPrioTag(TProcessMap& pm, const byte pr) { pm &= ~(1 << pr); }

Эти две функции выполняются быстрее (короче аналога на одну команду) и отпадает необходимость в массиве TProcessMap PrioMaskTable[scmRTOS_PROCESS_COUNT+1] и функции TProcessMap GetPrioTag(const byte pr) const { return PrioMaskTable[pr]; }.

Выигрыш не велик – но все же – короче и быстрее.

За счет чего выигрыш? У АРМа есть аппаратный сдвигатель?

[amusin]

Гарри, ты не добавил const в объявлении
TProcessMap PrioMaskTable[scmRTOS_PROCESS_COUNT+1]
чтобы не заморачиваться с инициализацией таблицы?

[GetSmart]

У АРМа есть аппаратный сдвигатель?

Конечно есть. Сдвигает регистр в 1-тактовой команде на любое количество бит.

[spf]

У АРМа есть аппаратный сдвигатель?

Конечно есть. Сдвигает регистр в 1-тактовой команде на любое количество бит.

Необходимо уточнить ГДЕ задается "любое количество бит".
Если в другом регистре то хорошо.

PS:
Имеются процы у которых количество бит сдвига задается в коде команды - любое но фиксированное.

[GetSmart]

АРМ имеет команды с обоими вариантами: как непосредственное число сдвига, так и из содержимого другого регистра.