Отчего же? Что нам мешает динамически изменять вектора в контроллере прерываний? Дело же в другом- ISR должна быть оформлена по другому, не как обычные процедуры и функции.

Вполне достаточно, чтобы понять- методы в классах нельзя назначать как ISR. В принципе нельзя, независимо от возможностей компилятора. На эту ошибку я и указал Antoxa. Что же касается вызвать метод класса из настоящей ISR, то последняя должна размещаться в программном модуле, тоже написанном на С++. И вот, я действительно не знаю- есть ли в компиляторе С++, например IAR, такие служебные слова, которые превращают обычную функцию в ISR? Если знаете- буду очень признателен услышать.




Кстати, высокомерничать не я первый начал. Однако, поступаю по-христиански: "Око за око, зуб за зуб" (с)-Нагорная проповедь

Ржу, аки конь. Со слезами на глазах.
2 Aprox - читать вам еще не перечитать книжки по C++. Иначе вас размажут аки блин местные спецы. Через полгода заходите.

Такая настойчивость уже начинает раздражать.
Aprox, специально для Вас объясняю.
1. У любой, сколько-нибудь сложной задачи существует более одного способа решения, основанных на целой куче исходных данных, выходных результатов, имеющихся инструментов, наработок, time to market, способности к расширению, изменению и т. д.
2. Любое решение будет в той или иной степени приемлемым и имеющим право на жизнь.
Поэтому Ваши безапелляционные суждения вроде "RTOS себя изжили" Вам следовало бы произносить примерно так: "Конкретно мной, отталкиваясь от моих личных, весьма предвзятых и далеко не исчерпывающих опыта, знаний, предпочтений, религиозных убеждений, в моей частной задаче было принято решение, которое никоим образом не относится к данной теме. Извините, что вклинился". И произнести это надо было именно про себя, т. е. даже не вслух. Ибо Ваши сообщения в этой теме, начиная с первого, являются ни чем иным как нарушением правил форума.
Считайте это предупреждением.
Модератор.

Ну, наконец-то начинаете осознавать недостатки scmRTOS в деле взаимодействия с периферией по прерываниям!

Видите, уже становится понятно, что nested прерывания ой, как не помешали бы, чтобы успеть за всеми быстрыми процессами.

А что, разве scmRTOS и nested interrupt - несовместимы?

Господа, мы кормим тролля. Ему абсолютно до лампочки все объяснения, его невозможно в чём-то убедить. Единственное действенное средство - игнорировать. ( Ну или забанить )

Как ни крути, а "чтобы успеть за всеми быстрыми процессами" нужно каждому прерыванию по отдельному процессору!

Welcome to FPGA!


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

А так - синяки, эмоции, тонус, адреналин.. Жизнь!

Вы знаете — ну прекрасно отношусь!
Только давайте уточним, что опять имеется ввиду под «современностью» и что означает «недавнее» —
Десять лет (MSP430x15x/16x)?
Пятнадцать-двадцать (M16C, Fujitsu MB90).
Или все двадцать-двадцать пять? PTS (Peripheral Transaction Service) в однокристалках Intel MCS196 (оно и в MCS96 было, но я с ними не работал совсем) был таким хитрым DMA, который при разрешении отрабатывал по тому же запросу, что запрос прерывания, т.е. специальной линии запроса DMA не было, но при разрешении PTS оно перехватывал прерывание на себя, делал пересылку. Когда его задание заканчивалось — он просто переставал перехватывать прерывание на себя и отрабатывал назначенный обработчик.
Или ещё больше — в многокристальных микропроцессорных комплектах, например, КПДП 580ВТ37 aka i8237, перекочевавший позже внутрь чипа в контроллеры на базе i186 и в материнки IBM PC.

И какой смысл пересылать по одному байту через DMA, чтобы потом по таймауту узнать, что это был один байт?

Кгм... Вы имеете понятие о разнице между свободной функцией либо статической функцией-членом класса и нестатической функцией-членом? О неявной передаче указателя this? Что указатель на свободную функцию/статический метод и на функцию-член имеют разные размеры (указатель на нестатический член класса — целая структура из нескольких полей)?
Что аппаратура контроллера по вектору может только вызвать функцию void (*)(void), но не может передать ей указатель на экземпляр класса?
Мдааа.... Я начинаю уставать.....

Несомненно. Для устаревших контроллеров. Для современных Cortex-ов это не так — Вы что, действительно этого не знаете?!!
Но и для устаревших контроллеров некоторые компиляторы поддерживают назначение статических методов класса на вектора, так как указатель на статический метод по форме не отличается от указателя на С-функцию, а их компиляторы умеют оформлять как обработчкик прерываний (это IAR для AVR):



Вы бы таки сходили по предложенным ссылкам. И подумали о различии статических и нестатических функций-членов. Потом говорили бі «невозможно» по поводу того, что работает (цитаты кода из так и непросмотренных Вами ссылок).



Ну я опять Вас отправлю к моему сообщению с кусокм кода, про который Вы написали «коды skipped».
Там это было продемонстрировано для avr-gcc в виде модификации main.cpp из одного из примеров scmRTOS. В C++ файле свободная функция - обработчик прерывания, которая объявлена другом класса и вызывает приватный нестатический метод класса.
И там же я написал, что всё было проверено в железе. Т.е. я и так был уверен. что всё работает, но, как обычно, не хотел выкладывать код с возможными описками.

В примерх scmRTOS обработчики прерываний сидят себе в main.cpp, обработчик системного таймера — в OS_Target_cpp.cpp и всё работет.
IAR же вообще позволяет прямо в описании класса непосредственно статический метод объявить обработчиком, ссылки на примеры по форуму я Вам тоже уже давал.

Так Вы и исходники scmRTOS не смотрели перед тем, как, извините, трындеть тут?

Господи, я думал, Вы хоть язык С++ да его компиляторы знаете... Так же ж страдали за поддержку возможностей языка современными микроконтроллерами...

Согласен.
Убедить можно того, кто что-то по теме знает и готов слушать.

Aprox'у медаль за совершение невозможного - я ранее считал что Александр не умеет ругаться вообще.

Спасибо за понимание. Остается только добавить, что каждый узел периферии в микроконтроллерах все больше получает оснований называться "отдельным процессором" на общей шине. По-моему, крайне неразумно игнорировать сей тренд современности и упираться рогом в чисто софтовые решения.

Уже.



Согласен, что решений много. Но категорически не согласен, что все они равноценны и имеют право на жизнь.

Интересно, а как вы представляете себе еще можно оценить достоинства некого универсального инструмента вроде эхотажной scmRTOS, кроме как не примерив этот инструмент к своим лично целям и практическим задачам? Ну, как еще? Слепо довериться авторитету авторов? Поддаться очарованию их знаниям языка С++?

И потом, я не говорил, что все "RTOS себя изжили", а только вытесняющего типа. Потому что, грубо говоря, заботу об "вытеснении" в значительной степени теперь берет на себя встроенная в микроконтроллер периферия. Вполне допускаю, что этот медицинский факт в данной конференции у многих вызывает раздражение и обиды. Не возражаю перенести обсуждение в другую ветку с более спокойной реакцией на очевидные вещи.

Всё, терпение лопнуло. Aprox получил 15 суток read only за троллинг.
Модератор.

Не успел Хотел попросить Игоря не наказывать, но не успел. Уж больно забавная тема получилась.

P.S. Не забыть попросить о том же модераторов в ветке FPGA. Судя по всему нас и там ждут незабываемые открытия.

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

Извините.

а IgorKossak ничего не обещал... жестоко...

Aprox, как я понимаю (каждый понимает в меру своей испорченности ) хотел всего лишь услышать зачем нужна ОСь, если для его задач в микроконтроллере есть достаточно ресурсов, чтобы обойтись без нее. (надеюсь, правильно понял)
мое мнение - если нет надобности в ОС, то и не надо.

также затронул тему про ненужность новых типов (uint8, uint16 и т.п.) - опять же кому как удобно.

а по-поводу scmRTOS - использовал в нескольких проектах. работают стабильно.
в одном пришлось отказаться, т.к. пришлось добавлять функциональность, а места для хранения и обработки данных в камне не хватило.

разработчикам уважуха
было бы не плохо в состав ОС добавить обработчики прерываний для UART, SPI, и т.п. с буферами, обработчиками ошибок и т.д.

Это его ветка, он тут хозяин.
Ни в коем случае! Что вы! Даже жестко коммерческие проекты разделяют собственно OS и middleware.

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

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

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

+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 вызывать.

Открыл проект 1-EventFlag для AVR\IAR. Заменил M168 на M128:

Это так и раньше было?
Или что-то забыли добавить?

Ну, не после планировщика - планировщик всегда вызывается при выходе из прерывания, т.е. последним. Возможно, вы имели в виду, после функции Kernel.system_timer()?


Не очень понимаю проблему. Хук этот предназначен для выполнения пользовательского кода внутри обработчика системного таймера, и код этот как-то не предполагается, что тесно связан с потрохами ОС. Не могли бы вы пояснить на примере?


Так было всегда. Проблема тут в том, что описания регистров у AVR для разных МК нередко отличаются. Поэтому код, связанный с ними, и вынесен на уровень проекта, чтобы не привязывать исходники ОС к конкретным МК. Если меняется МК, то в этом конфигурационном заголовке надо и имена соответствующим образом поменять. А пример - он на то и пример, чтобы показать, как делается. Пользователь может вообще всё сделать по-своему - например, выбрать в качестве источника прерывания переключения контекстов какой-нибудь другой аппаратный модуль вместо используемого в примере. Просто SPM показался наиболее подходящим для этой цели.

Ясно, не заметил. Раньше М128 без проблем запускалась.
Ну да ладно, у Атмела местами такой бардак с именами, что на все случаи трудно сделать.


Если я правильно понял, то проблема в том, что непонятно как строить системы, использующие различные режимы энергосбережения:
в Idle_hook происходит засыпание МК в глубокий sleep с выключением кварца и прочей периферии. Просыпаться МК может например по прерыванию системного таймера, но все источники тактирования заглушены и их надо запустить и дождаться их готовности. Так вот как это правильней сделать?

Это, как я понимаю, зависит от конкретного МК. Только не ясно, как это связано с хуком системного таймера и его положением внутри обработчика прерывания.

Такие вещи у всех МК специфичны.


Системный таймер (работающий от часового кварца например) может быть источником пробуждения.
А system_timer_user_hook можно бы использовать как функцию где включается периферия и кварц после сна. И чем раньше system_timer_user_hook будет вызван, тем лучше, так как после пробуждения МК работает от медленного RC.
Сейчас сделано так:

А может лучше так? Пока выполняется Kernel.system_timer() происходит в фоне стабилизация кварца.

Это не столько связано с включением/отключением кварца, сколько с переключением источника тактирования. Например я при idle переключаю основной CLK с 48MHz на 32kHz/1kHz (не могу я уснуть полностью - кое что делать приходится), по таймеру получаю управление в функцию хука, которая производит обратное действие, но перепланировка rtos при этом выполняется раньше, еще при работе от низкочастотного источника синхронизации. Получаем лишние задержки.

_Артём_ все правильно написал.

Вопрос скорее по порту GCC ARM, навеян этим. Из каких соображений не используется структура .init секций? Насколько мне известно, в коммерческой (и триальной (была у меня)) сборках от CodeSourcery секции есть.
Это связано с необходимостью писать соответствующий сложный startup?

Всё очень просто - когда писался порт, этого механизма не было.
Тем более, стартап и линкерный скрипт всё равно свои, так что как сделали сначала, так и осталось. Только линкерный скрипт подправили при переходе на .init_array.

?? Не знаю как на ARM, а на AVR .init было реализовано в 2008 (тут упомянуто).
Порт для Cortex создавался же существенно позже. Эта поддержка была наверняка реализована в компиляторе.

Так вы "не знаете", или всё же утверждаете "наверняка"?

Порт для кортексов выпущен в 2009 году. В это время компилятор GCC только-только узнал о кортексах. Тот же самый Sourcery G++ Lite 2009q1-161 из своего дефолтного стартапа банально не вызывал конструкторы глобальных объектов, и не линковал их. Поэтому были написаны свой скрипт и стартап.
И в чём, по-вашему, заключается "эта поддержка в компиляторе" при условии написания своего стартапа и линкерного скрипта?

В компиляторе+линкере реализована поддержка секций вообще.
Для AVR это часть avr-libc. В идущих в ней линкерных скриптах секции указаны в нужном порядке, в gcrt1.S используются некоторые из секций для нужд стартапа, остальные отданы пользователю.
С компилятором тут связано разве что то, что он помещает конструкторы в выделенную для них секцию именно из этой группы.

Глянул на lite и trial: в lite нет многих файлов инициализации, которые есть в trial.
Следовательно:

В trial есть, в lite нет.

При этом условии ни в чем.
Понятно, что писать свой аналог тяжело, и следовательно, не необходимо.

Именно! Но не для arm-gcc. Раньше (во время выпуска первых версий порта для кортексов) конструкторы помещались в секцию .ctors, а сейчас они переехали в .init_array. Получается, что arm-gcc вообще никак не поддерживал эти .init, а использовал и использует другие механизмы
Кстати, вот здесь klen очень подробно расписал, как должен работать механизм с .init_array. И ещё вот здесь обсуждали это.



Извините, но не верю. Линкерные-то скрипты - они все есть и в lite. И там нет поддержки .initX секций.

Зарегистрируйтесь здесь, скачайте, установите и сравните.
Там несколько файлов с копирайтом CodeSourcery, включая бинарные. В составе поставки расширенные библиотеки и другие отличия.

Наконец запустил свою плату на F207, IAR 6.30 + TNКernel
72МНz, 2WS, IAR6.30 - 2.16 мкс
120МНz, 3WS, IAR6.30 - 1.30 мкс
Да, еще измерил обратное переключение при засыпании приоритетной задачи на ожидании объекта - 1.63 мкс (для 120МГц).



STM32F4DISCOVERY у меня тоже есть - в столе лежит , но руки дойдут не скоро . И не думаю что TNKernel на нем на 168МГц из микросекунды "выбежит", поэтому в целом согласен - новая версия SCM чуточку быстрее.

Такой механизм я реализовывал в своем первом стартапе для ARM7. И после просмотра результатов первой же сборки исходника удалил, ибо конкретно для ARM использовать их так, как это сделано в AVR, невозможно - ассемблер после функции размещает константы для команд типа LDR R0, =main. Поэтому закончив выполнение кода функции процессор должен выполнить команду перехода чтобы не начать исполнять эти константы как код. А переход надо делать на метку, расположенную в начале следующей функции. И летит к чертям вся красота получения линейного кода путем размещения __naked__ функций в .init - секциях, ибо первая функция должна начинаться меткой на которую делался переход из предыдущей секции, а заканчиваться переходом на метку, с которой начинается следующая функция и т.д. В общем случае раздельной компиляции имя метки начала следующей функции неизвестно.

А в секции .ctors или .init_array хранится просто массив указателей на конструкторы, с ним никаких подобных проблем нет. Можно, конечно, и .init-секции сделать массивами указателей, но есть ли в этом смысл? Сейчас можно всю необходимую инициализацию разместить в __low_level_init().

Наблюдаю непонятное поведение проекта 1-EventFlag для AVR\IAR (компилировал в IAR6.10, поменял выходной формат на ubrof8, запускал в AVRStudio 4).
Поставил точки прерывания на строчках:


Странность в том что после старта программа проходит по точкам не 1-2-3, а 1-3-2, что при Kernel.ReadyProcessMap равном 0x0E быть вроде как не должно.
И шо це таке?

Нажмите для просмотра прикрепленного файла

Уважительная причина и внятное объяснение, спасибо. Если у участников проекта нет возражений, будем переносить.

Не вижу смысла. Я уже парой постов выше показал, что arm-gcc этого не поддерживает и не поддерживал никогда (.ctors, затем сразу .init_array). И Сергей Борщ далее написал, что просто не получается нормально это сделать. А вы продолжаете упорствовать (причём даже не попробовав!).