IgorKossak 0 20 апреля, 2012 Опубликовано 20 апреля, 2012 · Жалоба Это его ветка, он тут хозяин. Технически не моя, но руки дотянулись. Тем более, что были просьбы, предупреждения и индульгенция модератора ветки в привате. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nixon 4 20 апреля, 2012 Опубликовано 20 апреля, 2012 · Жалоба Почистим ветку? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 20 апреля, 2012 Опубликовано 20 апреля, 2012 · Жалоба Почистим ветку? Как Антоха решит. Хотя, с другой стороны, я бы не чистил. Здесь довольно толково многие вещи объясняются невзирая на причины таких объяснений. Да и в назидательном плане будет полезно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 20 апреля, 2012 Опубликовано 20 апреля, 2012 · Жалоба Как Антоха решит. Хотя, с другой стороны, я бы не чистил. +1 Вычищать всё — пропадёт полезное. Вычищать половину — будет не всегда понятно в чём дело. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 20 апреля, 2012 Опубликовано 20 апреля, 2012 · Жалоба Да нету там никаких 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 15 20 апреля, 2012 Опубликовано 20 апреля, 2012 · Жалоба Вычищать всё — пропадёт полезное. Вычищать половину — будет не всегда понятно в чём дело. +1. Конечно, некоторый процент будущих читателей пожалеет тролля, но пользы от полной ветки всяко будет больше. Запустил на F205, настройки такие же (72 МГц, 2 waitstate на флеши), IAR 6.30, получилось 2.38 мкс. Выходит, что у 205-го флеш побыстрее. (Остальное-то по идее одинаково) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 20 апреля, 2012 Опубликовано 20 апреля, 2012 · Жалоба Запустил на F205, настройки такие же (72 МГц, 2 waitstate на флеши), IAR 6.30, получилось 2.38 мкс. 205-ый покруче 1xx, у него типа акселератор флеша есть. У меня как раз сейчас 217-ый в запуске, потестирую при случае. TCB большой. Что есть - то есть. Там еще пару элементов можно в отладку убрать, но это несильно сократит размер. Ломает глаз обилие указателей на void. Да вроде не особо? Ну стек представлен как массив указателей void*. И параметр функции входа в поток имеет тоже тип void. Указатель на фукцию - то да, зря там PVOID стоит, надо бы правильный тип вкрутить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 22 апреля, 2012 Опубликовано 22 апреля, 2012 · Жалоба 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 22 апреля, 2012 Опубликовано 22 апреля, 2012 · Жалоба Предлагаю создать в этом разделе в отдельную тему под названием, например, Нужна ли scmRTOS если есть вложенные прерывания? ... Вынести туда сообщения: Окей, доберусь до компа - сделаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 24 апреля, 2012 Опубликовано 24 апреля, 2012 · Жалоба Продолжим замеры? :) Замерил скорость переключения контекста на STM32F4DISCOVERY. 168 МГц, 5ws. Получилось 964 нс. Это просто ракета! :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Артём__ 0 24 апреля, 2012 Опубликовано 24 апреля, 2012 · Жалоба Получилось 964 нс. Это просто ракета! :) Вы запускали версию scmRTOS для CM3? Как тогда с FPU работать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 24 апреля, 2012 Опубликовано 24 апреля, 2012 · Жалоба Пока запустил без FPU. То есть, работать с FPU можно, но только в одной задаче. Буду делать порт для M4F, надеюсь, что уже скоро. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Артём__ 0 24 апреля, 2012 Опубликовано 24 апреля, 2012 · Жалоба Пока запустил без FPU. То есть, работать с FPU можно, но только в одной задаче. Ясно. То есть, работать с FPU можно, но только в одной задаче. Тоже вариант. А другие задачи могут через мьютекс давать данные FPU-задаче и получать от неё результат когда будет подсчитано. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nixon 4 24 апреля, 2012 Опубликовано 24 апреля, 2012 · Жалоба Еще небольшое замечание по ходу. Пользовательская функция system_timer_user_hook() в scmRTOS вызывается после перепланировщика. Может лучше ее вынести в начало обработчика системного таймера? В различных системах, где требуется манипуляция системами тактирования и режимами энергопотребления это идеологически правильно производить именно system_timer_user_hook(), но делать это лучше до вызова перепланировщика RTOS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Артём__ 0 24 апреля, 2012 Опубликовано 24 апреля, 2012 · Жалоба Пользовательская функция system_timer_user_hook() в scmRTOS вызывается после перепланировщика. Может лучше ее вынести в начало обработчика системного таймера? А если ни одна задача не стала готовой к выполнению? А вы уже генератор запустили, а он допустим не нужен, так как программа опять в idle уйдёт? P.S. А где принято дожидаться готовности системы тактирования? В contex_swith_user_hook? P.S.2. А может тогда сделать чтоб была возможность задать два system_timer_user_hook, на входе в OS::SystemTimer_ISR и после планировщика? И пусть каждый решает по ситуации какой ему hook вызывать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться