Jump to content

    
Sign in to follow this  
AHTOXA

Выпущена scmRTOS 4.0.

Recommended Posts

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

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

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

Share this post


Link to post
Share on other sites
Почистим ветку?

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

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

Share this post


Link to post
Share on other sites
Как Антоха решит.

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

+1

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

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

 

 

Share this post


Link to post
Share on other sites
Да нету там никаких 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-разрядный проц это прощает. :)

Share this post


Link to post
Share on other sites
Вычищать всё — пропадёт полезное.

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

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

 

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

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

Share this post


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

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

 

TCB большой.

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

 

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

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Предлагаю создать в этом разделе в отдельную тему под названием, например, Нужна ли scmRTOS если есть вложенные прерывания?

...

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

 

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

Share this post


Link to post
Share on other sites
Пока запустил без FPU. То есть, работать с FPU можно, но только в одной задаче.

Ясно.

 

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


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

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

 

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this