http://scmrtos.sourceforge.net/

Добавил релиз порта для Fujitsu FR.

Старые ресурсы на narod.ru и igpss.com прекратили свое существование.
Весь старый сайт и предыдущие версии перенесены на SF.net в раздел old -- http://scmrtos.sourceforge.net/old/

В репозиторий, в ветку branches/ARM_STR71x добавлен порт для STR71x.

Стандартные примеры, идущие в комплекте scmRTOS работают. Как обычно, каждый пример имеет два targets: RAM и FLASH. Проверялось с IAR v4.30A на демо-плате IAR STR711-KS.

Поскольку стандартная библиотека имени ST отказалась компилироваться в режиме С++, а в комплекте IAR нет заголовочных файлов для STR71x (были в 4.20 потом исчезли), пришлось написать свой. Имеющийся в комплекте IAR 4.30 заголовочный файл для ST73x (а также бывшие в 4.20 файлы для STR71x) написан в стиле файлов для LPC2ххх, т.е. каждый регистр описан в виде битовых полей, что затрудняет его использование с С++, файл для порта написан в стиле файлов для AT91, т.е. структуры на каждый периферийный модуль с описанием битов через #define.

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

В приложении .bat-файл для вытаскивания порта с набором примеров из репозитория. Требует наличия Subversion.

То есть полезно качать всем? А не только тем, кто хочет STR71x пользовать?

Полезно для тестирования, вдруг что-то еще нароете или что-то на другой платформе не поедет, но "качать" можно пока только при помощи subversion или через web интерфейс.
(пробное новое ядро - http://scmrtos.svn.sourceforge.net/viewvc/..._STR71x/Common/ )

А как насчет реализации следующих фич:
1. Специализация шаблона Msg для пересылки указателей.
2. Наследование Msg от EventFlag.
3. API без заморочек с регистром букв в названии методов.

Да. Ну или дождаться следующего релиза, в который эти изменения будут внесеныВ ветке branches/b1 лежит вариант, в котором все сервисы наследуются от TService и в котором можно легко создавать свои сервисы с необходимой функциональностью. Сейчас вяло текут обсуждения о необходимости следовать этим путем или же оставить существующие сервисы как есть, а параллельно им добавить TService.
Боюсь, тут будут проблемы с совместимостью со старыми версиями. Хотя, чем раньше такой переход делать - тем проще. Мысли в этом направлении уже думаются, предлагаю всем желающим принять участие (только надо ветку другую открыть).

P.S. В процессе исправления упомянутых выше багов внес баг в OS::TBaseMessage. Только что поправил. Исправленная версия в репе.
Хм. А это вовсе и не баг. Так и должно было быть. Поправлю взад...

Хочется задать вопросы автору scmRTOS.
Вышла версия 3, а описание есть только на вторую.
А теперь вопросы к Гари:
- какие изменения и доработки внесены в 3 версию по сравнению со 2;
- планируете ли Вы дальнейшее развитие и в каком направлении.

http://scmrtos.sourceforge.net/releases/WhatsNew.html


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

Из крупных изменений планируется сделать и документировать API для создания пользователем своих собственных сервисов (как показывает практика, всегда есть те, кому не хватает существующего ). В каком-то виде это уже и сейчас есть - в репозитории проекта есть ветка, где такой вариант представлен. Но это пока только прототип, хотя и работоспособный (Сергей Борщ им пользуется - это вообще была его идея ). В окончательной версии может что-то поменяться.

А когда можно, хотя бы приблизительно, ожидать документацию по версии 3 ?

Не могу сказать. Не раньше, чем через несколько месяцев. На самом деле основные моменты остались прежними. Ориентируйтесь пока на это + список изменений, который опубликован.

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

Просьба к модераторам этого раздела.
Слить все по scmRTOS в порядке дат поступления в один раздел и поставить в шапку.
Извините, если напрягаю.

Еще раз извиняюсь, но уже наглость, и из ARM тоже.

Собственно про ARM была только одна ветка - в ней обсуждались кое-какие идеи в процессе написания порта. http://electronix.ru/forum/index.php?showt...=16114&st=0

Да, я про нее и говорю (в первую очередь).

Или сделать еще более концентрированно -- собрать все ссылки на обсуждение и разместить подборку на сайте scmRTOS.

Это самый оптимально-нормальный вариант.

Кто выдаст список?

И будем общаться на английском языке. Супер.

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

На sf.net в форуме можно писать по-русски, но там движек не очень удобный.

Появился порт для avr-gcc v4.xx. Порт имени Олександра Редчука aka avreal. Пока лежит в репозитории, в branches/avreal.

Приведу полный путь для тех, кто еще не в танке, но желает попробовать svn

или качайте с сайта архивчик avr-gcc.rar (будет лежать до тех пор, пока не выйдет полный релиз порта)

Уточнение - avr-gcc 3.4.6 тоже проверено, работает.
Код потолще выходит (в основном из-за того, что у 3.х не работает выбрасывание линкером неиспользуемого кода), но в некотором смысле "безопаснее", так как 4.x производит более "агрессивную" оптимизацию и не всё ещё проверено.

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

Обновления в основной ветке репозитория:
- Исправлен баг в сервисах, проявлялся при одновременном доступе к сервису нескольких процесов. Описание бага применительно к TMutex тут: Bug Tracker. Баг проявляется независимо от платформы, поэтому обновление рекомендуется всем пользователям.
- Порт для STR71x перенесен из branches в основную ветку.
- Убрана поддержка обратного порядка приоритетов из портов ARM7. По времени она проигрывала прямому порядку, на приложение порядок приоритетов влияния не оказывал, исходники загромождались бесполезным кодом.

Для желающих попробвать на ARM7 (AT91SAM7, LPC2xxx, ADuC, STR71x):
1) ставите svn
2) Скачиваете файл get_samples.bat
3) По комментариям в начале файла запускаете его, указывая семейство и локальную директорию в качестве параметров.

Обновлен avr-gcc порт ( branches/avreal )

1) Смена контекста по методу 1 сделана через прерывание SPM_READY (идея и реализация Сергей Борщ).
rationale (отмазка) - всё равно маловероятно, что это прерывание будет использоваться из application section (всё равно программа стопорится на время выполнения операций с флеш), но теперь не занят компаратор / нога IO, не нужно для каждого процессора вписывать нужную ногу.

2) Добавлены нормальные макросы (а не #if 0 ) вариантов компиляции примера - для выбора разных сочетаний приоритетов и длительностей, ну и немного откомментированы эти варианты.

3) Влиты изменения из основной ветки, см. предыдущий пост.

Отловлен баг в порте для ARM7.
Не работало с количеством процессов более 9.

Исправить в OS_Target_cpp.cpp
extern TPriority const PriorityTable[64] =
{
строчку
на

Исправил в репозитории.

Подскажите, а как пользоваться SVN под proxy? Есть проблемы с подключением к репозиторию, а вот как их решить - неразобрался.

На сайте http://subversion.tigris.org/ в поле поиска набираете proxy и вперёд.

Поднята и действует система ежедневних снапштотов. В снапшот входит порт+пример - тот же комплект, что и на download странице проекта. Берется это здесь. Дополнительная инфа тут.

В порт avr-gcc добавлены недостающие примеры.
В примерах 1 и 3 для scmRTOS_CONTEXT_SWITCH_SCHEME == 1 используется преривание SPM_vect, для примера 2 сделан применявшийся ранее вариант прерывания по компаратору, пусть будут оба.

Обсуждение использования разных прерываний и логики их выбора где-то там:
http://electronix.ru/forum/index.php?showt...43646&st=15
там и продолжать, если что.

Нашел небольшую недоработку.

При изменении значений параметров:



scmRTOS_IDLE_PROCESS_DATA_STACK_SIZE
scmRTOS_IDLE_PROCESS_RETURN_STACK_SIZE



(в версии 3.00-beta под AVR) возникает ошибка компиляции.

Приходится править вручную функцию:

OS_PROCESS void process<prIDLE, **, **>::Exec()



И если не сложно, подскажите где определяется размер стека прерываний?

Эти параметры определяются в scmRTOS_TARGET_CFG.h.
Другое дело, что в соответствующем месте OS_Target_cpp.cpp вместо определений в версии 3.00 стояли численные значения.
В версии 3.05 уже исправлено.

Спасибо.
Но это всё пол беды ... Не могу преодолеть трудность.
Запускаю прием данных по прерыванию от SPI. Система падает.
Причём, чёткой закономерности нет. Может работать очень долго а иногда после первого же байта и умирает.
Перевёл всё процессы в Sleep(0) чтоб не мешали, отключил всё лишнее, на вход поступает только SPI сигнал блоками по 8 байт 1 раз в секунду. Обработчик прерывания упрощён для отладки и выглядит так:

//SPI Interrupt Handler
#pragma vector = SPI_STC_vect
OS_INTERRUPT void SPI_ISR(void)

{
//класс обёртка
OS::TISRW_SS ISRW;

unsigned char temp;

//Забираем принятые данные из регистра SPDR
temp = SPDR;

//Загружаем следующий байт для передачи
//SPDR = 0xAA;

//импульс на осц для контроля
CLRBIT(PORTA,LED_AVR);
__delay_cycles(10);
SETBIT(PORTA,LED_AVR);
}

Аппаратно сдвиговый регистр SPI интерфейса работает, видно как он передаёт пустой байт вместо 0xAA.
Но прерывание не происходит.
Что можно сделать?

Зависит от применяемого класса в обработчике

TISRW - прерывание полностью работает на стеке прерванного процесса

TISRW_SS (Separate Stack) - прерывание сохраняет то, что счёл нужным компилятор, на стеке процесса затем переключается на отдельный стек.
Что за стек - надо смотреть конкретный порт. Порты avr использует основной стек (на котором начинается работа main), для avr/gcc размер - всё что осталось от памяти после статически размещённых переменных и стеков процессов, для avr/IAR - CSTACK и RSTACK.

Думается, TISRW_SS имеет смысл только при разрешении вложенных прерываний (тогда вложенное сразу начнёт работать на отдельном стеке) либо если прерывание вызывает каскад внешних функций, каждая из которых что-то сохраняет на стеке, или для жадных до стека (заводящих там переменные).
Если вложенных прерываний нет, а вызываемих функций нет либо стек не особо расходуется - отдельный стек ничего не сэкономит (а время на переключение займёт).
Разные прерывания могут пользоваться разной обёрткой.

p.s. на мой взгляд, тема не для "news:scmRTOS"
Может, для "Начало работы with scmRTOS"

Спасибо

Нашел где было. Дело оказалось не в софте. Самопроизвольно останавливался кварц.

Как начались проблемы ещё год назад в AT90CAN с осц, так и не работает нормально.





-