[IgorKossak 0]

Это его ветка, он тут хозяин.

Технически не моя, но руки дотянулись.

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

[Nixon 3]

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

[IgorKossak 0]

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

Как Антоха решит.

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

[ReAl 0]

Как Антоха решит.

Хотя, с другой стороны, я бы не чистил.

+1

Вычищать всё — пропадёт полезное.

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

 

 

[dxp 32]

Да нету там никаких 40 процентов :)

Исходные условия:

- STM32F103RG

- тактовая частота ядра 72МГц

- тактовая частота шины периферии 36МГц

- исполнение из флеша с 2 тактами ожидания

- печатная плата - стартеркит от Терраэлектроники

- компилятор IAR 6.30

- максимальные оптимизации по скорости

 

<...>

 

Итоговый результат длительностей наблюдаемых импульсов:

scmRTOS - 2.72 мкс

TNKernel - 2.76 мкс

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

 

Собрал из своих исходников файл с функцией tn_sem_signal() - собственно инкрементирует семафор и освобождаем ожидающую задачу. По возможности почистил от всяких фич других портов (оставил только относящееся к Cortex-M3), TN_ASSERT-ы, отладочные фичи и прочее, н еотносящее к вопросу. Файл даже компилируется - при желании можно посмотреть листинг.

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

[AHTOXA 14]

Вычищать всё — пропадёт полезное.

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

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

 

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

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

[VslavX 0]

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

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

 

TCB большой.

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

 

Ломает глаз обилие указателей на void.

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

 

[ReAl 0]

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 кодировки бьёт.

[Rst7 5]

Предлагаю создать в этом разделе в отдельную тему под названием, например, Нужна ли scmRTOS если есть вложенные прерывания?

...

Вынести туда сообщения:

 

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

[AHTOXA 14]

Продолжим замеры? :)

Замерил скорость переключения контекста на STM32F4DISCOVERY.

168 МГц, 5ws.

Получилось 964 нс. Это просто ракета! :)

[Артём__ 0]

Получилось 964 нс. Это просто ракета! :)

Вы запускали версию scmRTOS для CM3?

Как тогда с FPU работать?

 

 

[AHTOXA 14]

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

Буду делать порт для M4F, надеюсь, что уже скоро.

[Артём__ 0]

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

Ясно.

 

То есть, работать с FPU можно, но только в одной задаче.

Тоже вариант.

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

 

[Nixon 3]

Еще небольшое замечание по ходу.

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

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

[Артём__ 0]

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

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

 

P.S. А где принято дожидаться готовности системы тактирования? В contex_swith_user_hook?

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