Из-за того, что мои предложения повисли в воздухе, решил открыть тему здесь.
У меня вопросы по scmRTOS (извините, если они покажутся дилетанскими, я только начал мучить ОС). Раньше считал, что в uC OS лишняя заморочка, сейчас уже так не считаю.
Общие вопросы для общего развития.
1. Зачем понадобилось иметь порядок приоритетов сверху вниз (насколько я понял из-за Blackfin только). a&-a немногим проигрывает.
2. Я хочу ограничиться
#if scmRTOS_CONTEXT_SWITCH_SCHEME == 0,
т.е. использовать всегда программное прерывание.
Правильно ли это ?
3. Про OS::TChannel сказано, что этот объект оставлен для совместимости с версией 1. Рекомендуется пользоваться OS::channel.
Мне же показалось, несмотря на универсальность OS::channel, применение его для байтовых каналов слишком расточительным. Я бы рассматривал бы как чистый FIFO буфер, как-то так
#define TFIFO OS::Channel
и изменил он нем представление как об атавизме. Или я чего-то не понял ?

Платформозависимые вопросы.
Я использую LPC2148 с IAR 5.10. Использовал порт Сергея Борщ с незначительными собственными доработками.
1. Интересует особенности использования векторных прерываний, кроме системного времени. На что следует обращать внимание.
2. Или их использовать нежелательно.
PS. Не считайте мои вопросы наездом, scmRTOS - замечательная вещь.

Не понял, что дает a & -a. У Blackfin'a есть специальная команда, которая сразу вычисляет позицию первого ненулевого бита. Оба порядка приоритетов сущестувуют, чтобы можно было оптимизировать операцию вычисления приоритета для конкретного процессора. Пока это только Blackfin. Но кто знает, может есть и еще какие. Кажется у FR32 (Fujitsu) тоже есть такая аппаратная возможность.


Надо указать в конфиге:
#define scmRTOS_CONTEXT_SWITCH_SCHEME 1.


Вы сравнили производительность OS::TChannel и OS::channel<byte> и она оказалась в пользу первого? Или на основании чего такая оценка?

А это всегда так. Чтобы что-то сдвинулось - надо сделать это самому Не только для blackfin. Это для любого процессора, у которого есть встроенная инструкция clz - подсчета количества ведущийх нулей. Тогда нахождение самого приоритетного процесса, ожидающего выполнения сводится к одной этой команде. Такой же подход, если не изменяет память, реализован в порте для фуджиков. Ядро ARM имеет такую команду начиная с v5, поэтому для таких ARMов обратный порядок приоритетов будет давать выигрыш в объеме кода и, главное, времени переключения контекста. В текущем порте для ARM поддержка обратного порядка приоритетов является атавизмом, тянущемся со второй версии, когда для обратного порядка приоритетов pr0 был самым низкоприоритетным процессом. Тогда я реализовал поддержку обратного порядка для упрощения портирования между платформами. В третьей версии мы придумали простой способ объявлять pr0 самым высоким приоритетом вне зависимости от прямого/обратного порядка. Наверное нужно в следующем релизе поддержку обратного порядка из порта исключить, а задание scmRTOS_PRIORITY_ORDER перенести из пользовательских исходников в исходники порта, тем более что для количества процессов меньше 6 GetPrioTag() вычисляется таблично и разницы нет ни по времени, ни по объему, а для большего кол-ва процессов вычисление для прямого порядка компилируется в более эффективный код. Программное прерывание это #define scmRTOS_CONTEXT_SWITCH_SCHEME 1. Да, это более эффективный метод - весь контекст сохранятется/восстанавливается только когда необходимо перепланирование, а не в каждом прерывании - но, к сожалению, он не работает на кристаллах без контроллера прерываний (ADuC). В любом случае вы всегда можете его изменить, сравнить результаты и выбрать более подходящий.

Про TCannel лучше ответит dxp.
1)Не забывать в прерываниях, которые используют сервисы ОС заводить в начале обработчика объект типа OS::TISRW
2) Не забывать, что некоторые сервисы (тот же channel) при отсутствии/избытке данных могут захотеть перевести текущий процесс в спячку, что для прерывания невозможно.
3) Пока не реализована поддержка вложенных прерываний. Я с трудом представляю, с какой стороны к этому подступиться. Если реализуете - не забудьте поделиться
Других ограничений вроде как нет.

P.S. и не стесняйтесь склонять мою фамилию

Приведите, пожалуйста, пример аналога Push-Pop для channel.

Не понял вопроса. В чем затруднение? Все аналогично:


Отличия, конечно, имеются - OS::channel::pop(), в частности, поддерживает таймауты, поэтому будет работать чуть медленнее.

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

1. OS::TCannel использует макроподстановки, что не есть гуд.
2. OS::channel имеет расширенную функциональность (таймауты и возможность, например, помещать элемент не только в конец очереди, но и в начало).
3. Для единства стиля.

У меня нюх как у собаки.


Я считал также, но в Вашем порте сделано наоборот, поэтому я так и решил. Но это не принципиально.


Это соответствует моим представлениям.


Понял, также как с системным таймером.


Хочется поподробнее осветить этот момент.


Насколько я знаю по Keil, вложенные прерывания реализуются через макросы при входе и выходе из прерывания, но т.к. на возврат используется один регистр приходится пользоваться стеком, чтобы не затереть. Вложенные прерывания, на мой взгляд, извращение (но я не догматик). Тем более создатели ARM, я надеюсь, солидарны со мной.


Спасибо dxp и Сергею Борщу за оперативность (я тоже исправляюсь).


Понял, это мой глюк.


А это как раз понятно.

Ну например прерывание передачи по UART забирает данные из OS:channel<uint8_t>. А данные там кончились... В этом случае pop() попытается передать управление другой задаче, и это приведет к краху. Поэтому прежде чем вызвать pop() надо проверить - а есть ли данные. Аналогично для push().
Для TEventFlag есть специальная функция SignalISR() - ее можно использовать в прерываниях без опаски. Она при необходимости может поставить какую-либо задачу в очередь готовых к выполнению, но саму перепланировку не выполняет - перепланировка будет выполнена после выхода из прерывания.


В каком месте? Покажите, может там ошибка...

Понял.


Откуда я залил уже не помню.
Файл OS_Target_asm.s79
Дата файла от 08.02.07
//******************************************************************************
//*
//* FULLNAME: Single-Chip Microcontroller Real-Time Operating System
//*
//* NICKNAME: scmRTOS
//*
//* PROCESSOR: ARM7
//*
//* TOOLKIT: EWARM (IAR Systems)
//*
//* PURPOSE: Target Dependent Low-Level Stuff
//*
//* Version: 3.00-beta
//*
//* $Revision: 31 $
//* $Date: 2007-02-08 18:51:14 +0600 (╨є╤й, 08 ╤д╨╡╨▓ 2007) $
//*
//* Copyright © 2003-2006, Harry E. Zhurov
//*
//* Permission is hereby granted, free of charge, to any person
//* obtaining a copy of this software and associated documentation
//* files (the "Software"), to deal in the Software without restriction,
//* including without limitation the rights to use, copy, modify, merge,
//* publish, distribute, sublicense, and/or sell copies of the Software,
//* and to permit persons to whom the Software is furnished to do so,
//* subject to the following conditions:
//*
//* The above copyright notice and this permission notice shall be included
//* in all copies or substantial portions of the Software.
//*
//* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
//* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
//* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
//* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
//* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
//* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH
//* THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//*
//* =================================================================
//* See http://scmrtos.sourceforge.net for documentation, latest
//* information, license and contact details.
//* =================================================================
//*
//******************************************************************************
//* ARM port by Sergey A. Borshch, Copyright © 2006


#include "scmRTOS_CONFIG.h"
#include "scmRTOS_TARGET_CFG.h"
#include "OS_Target_core.h"

module scmRTOS_Asm


#define MODE_USER 0x10
#define MODE_FIQ 0x11
#define MODE_IRQ 0x12
#define MODE_SVC 0x13
#define MODE_ABORT 0x17
#define MODE_UND 0x1B
#define MODE_SYS 0x1F

#define NIRQ (1<<7)
#define NFIQ (1<<6)
#define THUMB (1<<5)

// Context structure:
// lo address
// CPSR
// R14 (LR)
// R0
// R1
// R2
// R3
// R4
// R5
// R6
// R7
// R8
// R9
// R10
// R11
// R12
// Process interrupt point (return address)
// hi address

CODE32
;-------------------------------------------------------------------------------

#if scmRTOS_CONTEXT_SWITCH_SCHEME == 0
COMMON INTVEC:CODE:ROOT
org 0x00000008
LDR PC, Context_Switcher_Adr ; Branch to swi_handler
org 0x00000018
LDR PC, IRQ_Wrapper_Adr
org 0x00000020

org 0x00000028
Context_Switcher_Adr:
DC32 Context_Switcher
org 0x00000038
IRQ_Wrapper_Adr:
DC32 IRQ_Wrapper

;-------------------------------------------------------------------------------
RSEG ICODE:CODE

IRQ_Wrapper:
MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching to System mode, because context has to be saved
; on top of user mode stack, enable FIQ
STMFD SP!, {R0-R12,LR} ; store R0_R12, dummy store LR to reserve space in context
STMFD SP!, {R1,LR} ; reserve space for CPSR, store LR_user on top of context

MOV R0, SP ; store context pointer in non-banked register
MSR CPSR_c, #(NIRQ | MODE_IRQ) ; switching back to IRQ mode
SUB LR, LR, #4 ; adjusting return address
STR LR, [R0, #4*15] ; store return address in reserved space (instead of saved LR_user)
MRS R1, SPSR ; move stored CPSR of process to non-banked register
STR R1, [R0] ; store SPSR in reserved space (instead of saved R1)

IRQ_SWITCH ; call IRQ handler

MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching to System mode, because context has to be restored
; from user mode stack, enable FIQ
MOV R0, SP
B ContextRestore ; restore saved IRQ context

RSEG ICODE:CODE
PUBLIC SaveSP
PUBLIC Set_New_SP

SaveSP:
// __arm void SaveSP(TStackItem** Curr_SP)
MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching to System mode, to get access to sp_user
STR SP, [R0]
MSR CPSR_c, #(NIRQ | MODE_IRQ) ; switching back to IRQ mode
BX LR
Set_New_SP:
// __arm void SetNewSP(TStackItem* New_SP)
MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching to System mode, to get access to sp_user
MOV SP, R0
MSR CPSR_c, #(NIRQ | MODE_IRQ) ; switching back to IRQ mode
BX LR

;-------------------------------------------------------------------------------
// __swi __arm void OS_ContextSwitcher(TStackItem** Curr_SP, TStackItem* Next_SP);
Context_Switcher:
MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching to System mode, because context has to be saved
; on top of user mode stack, enable FIQ
STMFD SP!, {R0-R12,LR} ; store R0_R12, dummy store LR to reserve space in context

SUB R2, SP, #4*2 ; store context pointer in non-banked register (reserve space for CPSR, LR)
MSR CPSR_c, #(NIRQ | MODE_SVC) ; switching back to supervisor mode
STR LR, [R2, #4*15] ; store return address in reserved space (instead of saved LR_user)
MRS R3, SPSR ; move stored CPSR of process to non-banked register
MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching back to System mode

STMFD SP!, {R3,LR} ; store CPSR, LR_user on top of context and adjust SP_user
STR SP,[R0]
MOV R0, R1
ContextRestore
LDMFD R0!, {R1, LR} ; restoring LR_user, saved CPSR_user
ADD SP, R0, #4*14 ; set process SP

MSR CPSR_c, #(NIRQ | MODE_IRQ) ; switch to IRQ mode to get access to SPSR_irq
MSR SPSR_cxsf, R1 ; store process CPSR to SPSR_irq to restore at return from irq

LDMFD R0, {R0-R12,PC}^ ; restoring remaining context, CPSR and reti

#else //if scmRTOS_CONTEXT_SWITCH_SCHEME == 1;
-------------------------------------------------------------------------------
COMMON INTVEC:CODE:ROOT

org 0x00000018
IRQ_SWITCH ; ∩σ≡σ⌡εΣ ∩ε αΣ≡σ±≤ Φτ ΓσΩ≥ε≡φεπε Ωεφ≥≡εδδσ≡α
;-------------------------------------------------------------------------------
RSEG ICODE:CODE
// TStackItem* OS_ContextSwitchHook(TStackItem* sp);
EXTERN OS_ContextSwitchHook
PUBLIC ContextSwitcher_ISR
ContextSwitcher_ISR:
MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching to System mode, because context has to be saved
; on top of user mode stack, enable FIQ
STMFD SP!, {R0-R12,LR} ; store R0_R12, dummy store LR to reserve space in context

SUB R0, SP, #4*2 ; store context pointer in non-banked register (reserve space for CPSR, LR)
MSR CPSR_c, #(NIRQ | MODE_IRQ) ; switching back to IRQ mode
SUB LR, LR, #4 ; adjusting return address
STR LR, [R0, #4*15] ; store return address in reserved space (instead of saved LR_user)
MRS R1, SPSR ; move stored CPSR of process to non-banked register
MSR CPSR_c, #(NIRQ | MODE_SYS) ; switching back to System mode

STMFD SP!, {R1,LR} ; store CPSR, LR_user on top of context and adjust SP_user
; to use process stack in OS_ContextSwitchHook
_BLF OS_ContextSwitchHook, Hook_Relay ; store context pointer(R0), get new context pointer(R0)
IRQ_DONE ; reset interrupt controller
ContextRestore
LDMFD R0!, {R1, LR} ; restoring LR_user, saved CPSR_user
ADD SP, R0, #4*14 ; set process SP

MSR CPSR_c, #(NIRQ | MODE_IRQ) ; switch to IRQ mode to get access to SPSR_irq
MSR SPSR_cxsf, R1 ; store process CPSR to SPSR_irq to restore at return from irq

LDMFD R0, {R0-R12,PC}^ ; restoring remining context, CPSR and reti

RSEG ICODE:CODE
Hook_Relay:
LDR R1, =OS_ContextSwitchHook ; call Thumb mode routine
BX R1
#endif


;-------------------------------------------------------------------------------
RSEG CSTACK:DATA
RSEG ICODE:CODE
// Set SP_irq to main() stack, restore context referenced by R0

// void OS_Start(TStackItem* sp);
PUBLIC OS_Start
OS_Start:
MSR CPSR_c, #(NIRQ | NFIQ | MODE_IRQ) ; switching to IRQ mode, disable FIQ & IRQ
LDR SP, =SFE(CSTACK) & 0xFFFFFFF8 ; End of CSTACK
MSR CPSR_c, #(NIRQ | NFIQ | MODE_SYS) ; switching back to System mode, disable FIQ & IRQ
; ContextRestore typically called from System mode

B ContextRestore ; Restore context = run process
;-------------------------------------------------------------------------------
ENDMOD

END
PS. Я в тесте выделил красным и зеленым цветом места.
Я текст исходный.

Сообщение отредактировал alexander55 - Oct 2 2007, 04:48

Нет, это не то. В scmRTOS под "программным прерыванием" понимается обычное прерывание, которое генерится из программы:Его преимущество именно в том, что даже если его сгенерировать внутри прерывания, в обработчик мы попадем "с чистого листа", т.е. из фона, когда на стеке нет данных из обработчиков других прерываний. Это сильно упрощает процесс переключения контекста. Поскольку swi не маскируется - его использовать для этой цели не получилось. А в нулевом варианте swi используется просто как быстрый способ вызвать функцию с переходом в ARM-режим.

[quote name='Сергей Борщ' date='Oct 2 2007, 11:57' post='301622']
Нет, это не то. В scmRTOS под "программным прерыванием" понимается обычное прерывание, которое генерится из программы
[/quote]
Я считал "программным прерыванием" SWI. Отсюда вся путаница.
Теперь мне надо возвратиться в исходное и все продумать сначала.

[quote name='Сергей Борщ' date='Oct 2 2007, 11:57' post='301622']
Его преимущество именно в том, что даже если его сгенерировать внутри прерывания, в обработчик мы попадем "с чистого листа", т.е. из фона, когда на стеке нет данных из обработчиков других прерываний.
[/quote]
Я считал, что в Supervisor (если не разрешать вложенные прерывания) можно попасть только из System режима (т.е. из фона). Т.е. SWI является отложенным прерыванием, хотя и с высоким приоритетом.
Опять какая-то неувязка.
[/quote]

Теперь, еще один вопрос.
С каким приоритетом внутри VIC лучше использовать прерывание по системному таймеру ?

В идеале так: самый низкий приоритет у переключателя контекста, чуть выше - у системного таймера, остальные - еще выше. Подробно обсуждалось тут: http://caxapa.ru/98558.html

Вопрос. Как в scmRTOS организовать карусель скажем из трех процессов ?

Никак. А зачем?

В доке это написано

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