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

Почистим ветку?

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

+1
Вычищать всё — пропадёт полезное.
Вычищать половину — будет не всегда понятно в чём дело.

Запустил на F205, настройки такие же (72 МГц, 2 waitstate на флеши), IAR 6.30, получилось 2.38 мкс.


Вполне красиво и прозрачно, читается практически с листа, это большущее достоинство. TCB большой. Ломает глаз обилие указателей на void. Ну, и видна интенсивная работа с указателями, 32-разрядный проц это прощает.

+1. Конечно, некоторый процент будущих читателей пожалеет тролля, но пользы от полной ветки всяко будет больше.


Выходит, что у 205-го флеш побыстрее. (Остальное-то по идее одинаково)

205-ый покруче 1xx, у него типа акселератор флеша есть. У меня как раз сейчас 217-ый в запуске, потестирую при случае.


Что есть - то есть. Там еще пару элементов можно в отладку убрать, но это несильно сократит размер.


Да вроде не особо? Ну стек представлен как массив указателей void*. И параметр функции входа в поток имеет тоже тип void. Указатель на фукцию - то да, зря там PVOID стоит, надо бы правильный тип вкрутить.

Aprox хочет «продолжить дискуссию» в привате, но это для меня дважды не имеет смысла. Пройдёт его срок поражения в правах — пусть продолжает тут, может, кто-то с ним и продолжит дискутировать. Точнее, на мой взгляд, всё же лучше в этой теме оставить обсуждение выхода scmRTOS 4.0 и хотелок по развитию scmRTOS, можно сравнение с TMKernel оставить, можно тоже вынести в что-то типа «Время переключения в scmRTOS и других ОС».
А вот остальное...

Предлагаю создать в этом разделе в отдельную тему под названием, например, «Нужна ли scmRTOS если есть вложенные прерывания?» (Aprox утверждает. что не нужна, причем вообще, а не только в его задачах, но я таки склоняюсь к вопросительному предложению).
Вынести туда сообщения:
4, 5, 8, 14, *16, *17, *18, 21, *25, 36, *39, c 41 по 48, 50, c 57 по 62, с 65 по 67, *68, 71,
c 73 по 79, 103, 106, 115, 117, 118, со 121 по 128, 130, со 132 по 134, со 136 по 139,
со 141 по 143, 145, 146, со 150 по 169.

Помеченные звёздочкой сообщения касаются в том числе хотелки разделить прерывания на высокоприоритетные «внеосевые» и ниже приоритетом «осевые», не запрещать превые на время критических секций ОС. Но это
а) сильно вплетено в «дискуссию»
б) уже обсуждается (1) в рассылке scmRTOS (я о таком задумался сразу, как начал писать порт STM8, но отложил, сейчас опять вспомнил)

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

Не совсем понятно, что делать с разговором о нестандартности stdint.h, особенно учитывая его переплетенность с разговором о современности вложенных прерываний и ПДП (а также канала, сопроцессора ввода-вывода, сервера периферийных транзакций и т.п.). Из-за этого в перечисленных выше сообщениях частично унесётся тема stdint.h, частично в сообщении 30 останется рассуждение, касающееся ненужности вытесняющей ОС при наличии вложенных прерываний.

Моё это сообщение, само собой, удалить. Независимо от выделения «дискуссии» в отдельную тему.

(1) что и как нужно сделать в почтовиках, чтобы письма в рассылке на сайте groups.google.com выглядели нормально. В почте у меня, кажется, все нормально выглядят, возможно, это groups.google.com кодировки бьёт.

Окей, доберусь до компа - сделаю.

Продолжим замеры?
Замерил скорость переключения контекста на STM32F4DISCOVERY.
168 МГц, 5ws.
Получилось 964 нс. Это просто ракета!

Вы запускали версию scmRTOS для CM3?
Как тогда с FPU работать?

Пока запустил без FPU. То есть, работать с FPU можно, но только в одной задаче.
Буду делать порт для M4F, надеюсь, что уже скоро.

Ясно.


Тоже вариант.
А другие задачи могут через мьютекс давать данные FPU-задаче и получать от неё результат когда будет подсчитано.

Еще небольшое замечание по ходу.
Пользовательская функция system_timer_user_hook() в scmRTOS вызывается после перепланировщика. Может лучше ее вынести в начало обработчика системного таймера?
В различных системах, где требуется манипуляция системами тактирования и режимами энергопотребления это идеологически правильно производить именно system_timer_user_hook(), но делать это лучше до вызова перепланировщика RTOS.

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

P.S. А где принято дожидаться готовности системы тактирования? В contex_swith_user_hook?
P.S.2. А может тогда сделать чтоб была возможность задать два system_timer_user_hook, на входе в OS::SystemTimer_ISR и после планировщика? И пусть каждый решает по ситуации какой ему hook вызывать.