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

Я не шибко опытный, но что то компилер не находит идентификатор 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

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



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

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

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


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

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

(коментарий в ней конечно неправильный)
согласно документу 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 отсутствует в списке регистров.

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

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

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

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

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

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

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

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


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

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

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-стек. Иначе нельзя.

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

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

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

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

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

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

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

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

Все это понятно. На это я с самого начала нарвался :-) У меня эта команда выполнятеся в 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 тоже проверил). Можете проверить. Симулятор же отрабатывает эту команду иначе. Я не вижу ничего незаконного в этой команде поэтому продолжаю считать что в этом случае симулятор явно ошибается.

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

Смотрите, что я нарыл:
(цитата из книжки)
Бит 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 ?

Касательно файла 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 КГц прерываний ни одного не потеряется!

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

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

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

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

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


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


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

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

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

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

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

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

Это долгая история. Сначала увидел такую конструкцию в исходниках линукса и тоже был озадачен. Задал вопрос на сахаре и ReAl мне наглядно объяснил, что поскольку в макрос может быть добавлена еще одна команда то его лучше сразу заключить в {}, но макрос с {} нельзя использовать в лоб в конструкции if(cond) Macro(); else ....; а если добавить do while(0) то смысл не изменится но ограничений уже не будет.
Системное время, ОС по нему считает тайм-ауты.
Угу, мне об этом говорили. Я, наивный, подумал что в атмеловском SAM7 так же. И тут же получил граблями в лоб - у атмела неиспользуемые биты не реализованы физически, т.е. "атакой, не атакуй...". С тех пор я слегка пуганый, и когда увидел в описании специально заточенный бит подумал "ВОТ!" и глубже решил не копать.
Я еще не измерял сколько у меня получилось время переключения - наверное сегодня выделю минутку. Вообще мы с автором scmRTOS обсуждали идею как сильно сократить время запрета прерываний, но пока это на уровне идеи - должно какое-то время повариться в мозгу.

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

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

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

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

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

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

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

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






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

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

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

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

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



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

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


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


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

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

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

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


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

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

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

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

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

[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]
Не собираюсь на семинар. Но встретится можно и без этого повода.

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


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

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

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

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

Сразу как-то прощляпил "не компилится" :-(
Причем поминанием документации. Посмотрел - никаких препятствий, работает, только один битик, естественно,
в 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, т.е. без оптимизации. Сегодня подправил переключение контекста в своем порте (теперь и симулятор и железо живут одинаково, да и скорость поднял) и попробовал разные варианты оптимизации, результат такой:

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

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

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

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

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

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

Я давно приглядываюсь к 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
Очевидно имеем констатное время поиска номера младшего установленного бита в слове.

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

2 Сергей Борщ

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

Да. Еще про 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

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