Всем привет!

Проект сменил систему управления версиями (svn -> git) и переехал с sourceforge.net на github.com.

Страница релиза
Репозиторий оси
Репозиторий примеров

На странице релиза основной архив содержит рабочие проекты примеров, исходный код оси и документацию в pdf формате.

Нет ли планов по портированию на ADSP-BF7xx ?

Все представленные порты - это то, с чем реально работают (или работали ранее) члены команды. То, с чем работа не ведётся, по объективным причинам не может быть представлено. Проект свободный и открытый, любой желающий может принять участие. Порт BF6xx появился так: человек портировал для себя и поделился. Теперь, при хостинге на github, этот процесс вообще упрощается через механизм fork/pull request.

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

Да это CCES. У меня он есть и есть железка.
У меня уже несколько лет существует проект на BF533 без ОС. В следующем году планируется апгрейд проекта на BF704 скорее всего. Из-за разрастания проекта уже очень хочется использовать ОС.
Мне тоже не жалко поделится после портирования, если все получится.
Суда по объему файлов в портах работы и правда не много.
Правда на С++ я еще ничего не писал. И BF7хх еще не изучен.

С++ для порта почти не нужен (да и для использования, можно сказать, тоже). Нужно знать железку (процессор) и средства разработки под неё.

Если имеете намерение сделать порт, то это только приветствуем, приходите в личку.

#ifndef scmRTOS_H
#define scmRTOS_H

#define scmRTOS_VERSION 400

//-----------------------------------------------------------------------------
//
// !!! The order of includes is important !!!
//
#include <stddef.h>
#include <stdint.h>
#include <usrlib.h>
#include <os_target.h>

//------------------------------------------------------------------------------


#endif // scmRTOS_H

scmRTOS_VERSION 400 специально не изменено?

очень много варнингов в в иаровском порте под avr и arm, причем они тянутся еще с версий 3.5x.
Это вызвано тем,что на закладке С/C++ compiler->Diagnostics в примере не стоит галка "Enable remarks".
Например,на такое украшательство
//******************************************************************************
дает Warning[Pa050]: non-native end of line sequence detected
исправляется достаточно просто,например черточкой в конце.
OS_PROCESS static void exec(); //Remark[Pe082]: storage class is not first
исправляется static OS_PROCESS void exec();
многочисленные варнинги Remark[Pa137]: use of C-style cast
на типа return (TPriority)pr; лечится return static_cast <TPriority> (pr);
многочисленные варнинги Remark[Pa109]: the unary minus operator is applied to an unsigned expression
(with possibly unexpected results)
на выражения типа return map & -map;

Это конечно мелочи. Но они тянутся уже давно и может в связи с выходом новой версии
это можно один раз поправить?!

А в общем все равно большое спасибо за отличную бесплатную ось.

Прикольно. Вооще-то это warning на, например, линуксовый LF, вместо CRLF.

Если это - последняя строка файла, может, поэтому ругается? Достаточно добавить перевод строки.

Нет, эти строки находятся и в начале и в конце файлов и компилятор даёт на них варнинги независимо от места.

Нет, просмотрели (этот файл вообще не менялся, в него и не заглядывали, макрос не мешает, но он не нужен), уберём.



Версий чего? ОС была 3.10 (3.11), потом сразу 4.00.


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

Попробовал собрать с ремарками.


Не смог воспроизвести. На каком примере это возникает? Какой код (ASCII) завершения этой строки у вас? В каком файле?


Тут расширение используется, и не вполне понятно, как будет правильно: __task static void или static __task void. Всегда, сколько помню, (у IAR) была нотация

<lang-extension> <qualifier> <type> <id>

Ругань эту даёт только IAR/AVR. Не уверен, что если поменять местами, не будет ругани на других платформах. Надо пробовать.



Да, тут пора привести к каноническому виду.



Тут тоже IAR/AVR выделяется, тот же IAR/ARM ругнулся всего раз на операцию с битовой маской.

Remark[Pe068]: integer conversion resulted in a change of sign D:\slon\scmRTOS\v5\scmrtos-release-v5.0.0\scmRTOS\core\os_kernel.h 458

Остальное его не взволновало. Что интересно - IAR/AVR на это молчит. По ходу, внутри IAR нет согласия по поводу, на что ругаться, а что пропускать. Я так не вижу во всех этих случаях никакого криминала, т.е. расцениваю эти крики ремарки компилятора не по делу. Возможно, не прав, тогда прошу обосновать.

Если хочется ремарок, но вот такие раздражают, можно настроить их адресное подавление.

Всем спасибо за замечания.

А Вам спасибо за scmRTOS

Начал править С-style cast'ы, проверяю, опять ругань, но уже на другие места:

Remark[Pa137]: use of C-style cast D:\pro\scmRTOS\scmrtos-sample-projects\scmRTOS\port\avr\iar\os_target.h 228

А код, на который ругается, такой:



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

Добрый день! Давно использую scmRTOS на разных arm. Спасибо, очень удобная система!
Сейчас пришлось запускать на M0-части lpc4337 В нем не реализован SysTick для M0, так что переносил на другой таймер.
В процессе нашлась маленькая описка. Вот тут, вроде, забыта тильда


https://github.com/scmrtos/scmrtos/blob/mas...c/os_target.cpp строка 314


Сообщение отредактировал darkling07 - Dec 4 2015, 09:28

Да, действительно, забыта. Надо поправить...
Спасибо за сообщение!