Всем привет!

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

Что касаемо скорости. Тестировал на stm32f4discovery, проц STM32F407 Rev A (То есть, не работает ART prefetch), частота 168 МГц.
Итак.

• Если два процесса не использовали FPU, то передача управления осуществляется за 900ns.
• Если один из двух процессов использовал FPU, то передача управления осуществляется за 1.1us.
• Если оба процесса использовали FPU, то передача управления осуществляется за 1.34us.

Красивая картинка:

К порту залиты примеры для STM32F4xx. Кроме стандартных четырёх примеров добавлен пятый - "5-FPU".
Он тестирует неизменность контекстов задач при выполнении действий с плавающей точкой.

Да, кстати. Этот порт подходит без изменений для M4F, M4 и M3. Так что, скорее всего, в дальнейшем развиваться будет именно он.


Забыл написать.
Краткая инструкция по скачиванию.

• Забираемся в папку, в которую мы хотим скачать примеры.
• Даём команду
  svn co https://scmrtos.svn.sourceforge.net/svnroot...F/GCC/STM32F4XX STM32F4XX
• Появляется папка STM32F4XX
• Заходим в неё, даём команду switch.bat (в линуксе - sh switch.sh)
• Всё.

Антон, Спасибо огромное.

«Кричат эмбеддеры „Ура!“ и в воздух чипчики бросают».

Схемы доступа претерпели изменения, в текущий момент:

• svn checkout svn://svn.code.sf.net/p/scmrtos/code/ и т.д.

Смотреть на странице http://sourceforge.net/p/scmrtos/code/

Добавлю сюда, пожалуй. Вот что я раскопал по поводу смены схемы доступа к svn.
Итак:

1. Сменился путь svn, был: http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/ , стал: http://svn.code.sf.net/p/scmrtos/code/)
2. Доступ по https теперь требует авторизации.
3. Анонимный read-only доступ остался только по http (http://svn.code.sf.net/p/scmrtos/code/trunk) и svn (svn://svn.code.sf.net/p/scmrtos/code/trunk).
4. Новый адрес веб-интерфейса к svn: http://sourceforge.net/p/scmrtos/code/
   К сожалению, если забраться там поглубже, то в ссылке появляется номер ревизии: http://sourceforge.net/p/scmrtos/code/563/tree/trunk/ .
   Путём невероятного напряжения умственных сил я догадался, как получить ссылку на HEAD. Надо заменить номер ревизии на слово HEAD: http://sourceforge.net/p/scmrtos/code/HEAD/tree/trunk/

Таким образом, пример из моего первого сообщения теперь будет выглядеть так:

Вопрос: как в новой версии получить архив какой-либо части (trunk и др.) или всего дерева, включая старые версии?
Раньше были значки для формирования нужного архива.

Эта ссылка http://svn.code.sf.net/p/scmrtos/code/ у меня не работает (404 Not Found). Остальные дают результат.

Никак, в новой версии этого нет. Либо посчитали, что это не нужно, либо просто не успели приделать.
Пока что можно пользоваться старой версией, думаю что она какое-то время ещё будет доступна. А потом может и к новой прикрутят.

Хм. У меня работает. Может быть это были временные трудности?
(В любом случае, эта ссылка не для браузера, а для svn-клиента, браузером там практически нечего делать)

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

Конечно делали
Пример 5-FPU как раз этим и занимается.
Там две задачи постоянно проверяют неизменность своего контекста (контексты изначально различаются), а третья - вычисляет число Пи.

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

а где можно почитать как проекты на с без оси адаптировать под csmrtos?

обязательно ли все делать на с++ или можно подключать старые модули на с?

и существуют ли где либо ссылки по прикручиванию к этой оси какой либо виртуальной машины пи-кода?

Там сначала обычные регистры заполняются разными значениями, потом эти значения копируются в плавучие регистры, а потом в цикле производится сравнение их значений. Если выявляется несовпадение - начинает моргать светодиод.
А почему у вас возникли сомнения в неизменности контекста?

Почитайте для начала Руководство пользователя. Это поможет понять, как вообще устроены программы с использованием scmRTOS.
Модули на си подключать можно.
Насчёт пи-кода - не припоминаю. Знаю только, что к ардуине прикручивали.

сомнений конкретно относительно scmrtos как таковых нет, но изучая разные сайты нашел обсуждения относительно pawn, что в некотоых случаях он работает некорректно, соответственно если буду использовать scmRTOS то хотелось бы быть уверенным в ней на все 100%

спасибо за ответы, посмотрю ваши ссылки

добрый день,задачка стала увеличиваться, увеличил размер памяти под стек заморгал светодиод, контекст нарушается?

Может быть. Хотя я довольно интенсивно использую порт в нескольких проектах, и ни разу с таким не сталкивался.
Какой у вас был размер стека, и какой стал? Может быть всё равно не хватает?
И убедитесь, что у вас самая свежая версия оси, я там что-то исправлял вроде.

за основу взят ваш пример

typedef OS::process<OS::pr0, 4000> TProc0;
typedef OS::process<OS::pr1, 1000> TProc1;
typedef OS::process<OS::pr2, 4000> TProc2;
typedef OS::process<OS::pr3, 306> TProc3;--- так не работает

typedef OS::process<OS::pr0, 4000> TProc0;
typedef OS::process<OS::pr1, 1000> TProc1;
typedef OS::process<OS::pr2, 4000> TProc2;
typedef OS::process<OS::pr3, 303> TProc3;--- так работает

при величине стека третьей задачи больше 303 начинает моргать светодиод

TProc3 Proc3;

template <>
OS_PROCESS void TProc3::exec()
{
test_context(0x87654321);--- ваша функция на ассембл
}


обнаружил случайно - стал в ваш пример свое нутро пихать сохранив эту задачку с проверкой сохранения контекста, пока везде стек был 300байт все работало нормально, на определенном этапе разростания задачи загорелся и не выключался светодиод - решил сначала что плата накрылась поменял отладочную плату поведение не изменилось, подумал, что ошибка возникла изза переполнения стека, везде увеличил до 1000 светодиод стал моргать, тогда стал искать как влиятет размер стека в разных задачах, обнаружил что при размере стека в третьей задаче больше 303 байт светодиод в ней моргает, при меньших значениях не горит, такое поведение меня очень удивило,логичнее было бы еслиб было наоборот, видимо ошибка где то в ядре системы?

Сообщение отредактировал сарматъ - Aug 12 2013, 08:55