aprox

ReAll Прошу обратить внимание на мой пост 2: Artem, где я ссылкой на официальный документ компилятора IAR для Cortex-M показал, что ваши приемы программирования прерываний нынче не работают. В разделе scmRTOS я много раз давал ссылку на кристаллы с ядром Cortex-M, тем самым образуя контекст разговора. Но почему-то оппоненты предпочли сердиться и нервничать вместо того, чтобы прочитать внимательно документацию на компилятор С++ IAR для Cortex-M. Вот и сейчас, с "профессионалами" происходит то же самое. Ну, прочтите же наконец о прерываниях документацию на компилятор C/C++ для Cortex-M! Тут мы вьезжаем в отдельную тему- что в эмбердерстве имеет практический смысл оформлять в виде классов, а что не имеет. Мое мнение таково- если в приложении имеется много однотипных обьектов, например кнопки, хранимые, индицируемые и редактируемые парметры, диалоговые окна, очереди, то безусловно имеет прямой практический смысл писать класс однотипных обьектов и потом тиражировать их в любом количестве. Если же в приложении обьект встречается один раз, а к этому случаю принадлежит практически вся периферия микроконтроллера, то тратить время и силы на создание класса такого устройства не имеет практического смысла, поскольку о тиражировании таких обьектов внутри одного приложения речи быть не может. ISR относятся как раз к таким, нетиражируемым обьектам. Поэтому включать их в состав методов класса не имеет никакого практического смысла.

Увы, по причине того, что контроллер прерываний в Cortex автоматически сохраняет контекст при срабатывании прерывания, становится уже ненужным управляющее слово __irq, обычно указывающее компилятору сохранять контекст программным способом. Вот, что пишут в той же доке IAR ARM, на которую вы же и ссылались: Иными словами, время старых, привычных решений уходит. "Врачу - исцелися сам."

Спасибо за ответ. Но ваша ссылка касается обсуждения исключительно в рамках scmRTOS, авторы которой наделали кучу заголовочных файлов с удобными им макросами. Я же работаю в стандарте C++ IAR v6.0 c библиотекой CMSIS специально для STM32. В этой библиотеке уже заготовлены все возмжные для каждого кристалла обработчики прерываний с заданными именами, начально это пустышки. Юзеру остается только наполнить эти пустые ISR своим конкретным кодом и обьявить этот обработчик дружественным в нужных классах. Других путей я не вижу. В хелпе IAR v6.0 для ARM и Cortex я не нашел управляющего слова __interrupt. А у директивы pragma не нашел параметра vector. Что я делаю не так? По-моему inline-подстановка в данном случае используется не по назначению. Не для этого она придумана. Да и вообще, задача сделать метод класса обработчиком прерывания имеет чисто академический интерес из той же серии- использовать обьектное программирование не по назначению.

В разделе по scmRTOS, в процессе диспута про OS, я встретил пример кода на C++, в котором был представлен некий класс, описывающий работу UART. И в этом классе один из методов якобы был обработчиком прерывания! Как сделать обработчик прерывания отдельной функцией- мне понятно. Но как сделать метод класса таким обработчиком- совершенно неясно в практическом плане. Я работаю с кристаллами STM32 Cortex, пишу на C++, поэтому очень интересует данный вопрос. Если кто умеет назначать метод класса обработчиком прерываний- буду крайне признателен за наводку.

Не желаете продолжить абортированную дискуссию? Меня по-прежнему очень интересует вопрос - как практически написать на С++ так, чтобы один из методов статического класса вызывался по прерыванию, и адрес точки входа в эту ISR был бы помещен компилятором+линкером в .intvect ? Если нетрудно, то конкретный листинг для STM32 Cortex.

Именно "никто подобного не делает" и должно вас насторожить в первую очередь. На мой взгляд, идея производить полуфабрикаты железа из рассчета на крупного оптового покупателя - идея абсолютно бесперспективна в комерческом и маркетинговом плане. Особенно в России. Вы же просили оценить маркетинговую сторону вашей задумки, а не техническую, правда?

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

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

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

Весь список конечно не оглашу, но намекну на практически любой 32-бит чип с ядрами ARM-9/11 или Cortex M3/4. Я лично исторически прирос к продукции STM. Ее линейка STM32 имеет периферию, насыщенную дополнительными фичами. И эти фичи устраняют на аппаратном уровне узкие места в паралелльных задачах управления и связи, вытесяющие RTOS попросту становятся не нужны. Я просто не стану связываться с допотопными архитектурами. А Линукс- да, вашей задаче супер-сервера в самый раз. Бессмысленно же изобретать велосипеды. Да, посмотреть на себя со стороны критическим взглядом - очень полезно. Ну, а как вы оцениваете на "современность" недавне появление DMA у периферии? Причем в любой комбинации, можно даже сквозной канал передачи организовать, например от UART прямо в SPI, минуя память и процессор. Зачем в этом случае посредники в виде RTOS? Я-то не боюсь. Потому, что прерывание вырабатывается UART-ом не по фиксированному кол-ву принятых символов, а по time-out в конце непрерывной посылки. Фактическое число принятых символов можно посмотреть потом в контроллере DMA. Этот прием охватывает даже ваш пример следования одиночных символов, я уж не говорю про пакетный MODBUS.

Мой мотив очень прост, решил исследовать вопрос - какой будет выигрыш от использования scmRTOS в моих задачах? Именно эта OS привлекла внимание тем, что она по-моему единственная предполагает использование C++. Начал с пары очень простых вопросов к авторам и апологетам. Ответы не впечатлили. Стало понятно, что продукт чисто софтовый, абстрактный, не учитывает развитие периферии современных микроконтроллеров. На этом собственно и все, диспут заканчиваю. Были бы знакомы с современной периферией микроконтроллеров, то заменили бы кучу мелких прерываний от каждого символа, всего одним прерыванием по окончанию работы канала DMA, который сейчас имеется у каждого приличного UARTа. Глядишь, и очереди оформлять для многозадачной OS не потребовалось бы. На stm.com даже AN такой есть. Кстати, у вас метод uart_t::irq_handler() представлен как член класса uart_t. Позвольте каверзный вопрос, как это удается в С++ оформить метод класса в виде ISR? Да еще и зарегестрировать соответствующий вектор в контроллере прерываний?

Конкретный пример с цифрами не приведу, потому что не занимался таким исследованием. Зато могу сослаться на IAR, который предлагает два варианта компиляторв с С++ : -1: урезанный Embedded C++ для мелких кристалов, где надо экономить ресурсы памяти и -2. полнофункциональный Extended Embedded С++ с тяжелыми библиотеками. Так вот, темплейты C++ поддерживаются только тяжелым Extended. Отсюда и непонятное противоречие в scmRTOS- с одной стороны вроде заботятся о мелких кристаллах, а с другой- тут же все портят использованием темлейтов. Причем, как я понимаю, ради абстрактной красоты. Могу вспомнить свой случай, к чему приводит использование темплейтов. В IAR сделал проект С++ без темплейтов для STR911FAM44 с ядром ARM-9. Приложение заняло примерно 160K кодов и констант во флеш. Потом соблазнился красотой темплейтов и оформил то же самое с темплейтами. Пришлось включать компиляцию с опцией Extended. Размер использованой флеш сразу вырос до 210K. "Имеющий уши- услышит".

Писать OS на С++ для архаичных 8-ми разрядных кристаллов и гордиться, что заняли всего 512 байт ОЗУ - это вам представляется суперсовременным? Вы же этим и юзера заставляете писать на C++. А сколько при этом будет впустую истрачено флеша на одних только "темплейтах" при компиляции проекта - это уже совсем безразлично мелким пользователям? Скандал раздуваете по-моему вы. Думаю, вовсе не из потребности в рекламе, а от беспомощности в серьезной и предметной аргументации.

Чисто софтовые RTOS вытесняющего типа сильно отстают от развития периферии современных микроконтроллеров. Все фичи, которыми так гордятся авторы софтовых OS, теперь исполняются аппаратно много эффективнее. К сожалению, не всем это понятно, приходится обращаться к конкретным примерам. Это вы зря. Обиделись наверное...

Речь шла о встроенном в микроконтроллер web-сервере. Для его реализации из всего стека протоколов нужен минимум: ARP-запросы, из ICMP только ping, да и то, можно обойтись, и конечно TCP. Причем, TCP в сильно урощенном виде. Здесь я считаю важным, что современная периферия в микроконтроллерах позволяет большинство коротких служебных пакетов обрабатывать и отправлять обратно в сеть прямо из ISR, обслуживающей MAC. Вытеснение процессов происходит на аппаратном уровне, специальная вытесняющая OS для этого не нужна.

Русским же языком было написано- у каждой задачи- приемника свой отдельный флаг тригеринга. А каждая задача-источник обращается только к одной задаче приемнику. Этот вопрос следует из непонимания структуры взаимодействия задач. Реализованные в ISR параллельные задачи-источники НЕ разделяют общие ресурсы. Их цель другаяя - сжать входную информацию от приферии и передать потребителю, медленной задаче-серверу, только самое необходимое. для его работы. Например, для приложений c WEB-сервером, задача ISR может произвести очень сильное сжатие информации. Она может самостоятельно отвечать на ARP запросы, отвечать пакетами Sync и Ack, сама выделять чистый http- запрос в текстовой форме, сама контролировать время соединений, их количество, сама фильтровать клиентов по адресам и, наконец, сама выделять текст http- запроса, буферизировать его. Собственно, последнее только и предназначено медленной задаче WEB-серверу. Та же история и с USB, с UART, с CAN и прочее.. Неужели не в курсе, что современные чипы позволяют организовать работу всего этого одновременно в псевдопараллельном режиме c вытеснением по приоритету? Зато прекрасно понял, - в чисто софтовой реализации, типа scmRTOS, они отжили свой век.

В том-то и дело, что для каждой периферии существует только одна задача - приемник запроса. По каналу Ethernet - только WEB-серверер, по UART- только свой отдельный интерпретатор команд, по USB- тоже только свой интерпретатор, от клавиатуры - только свой контроллер. У каждого свой флаг готовности. Никаких перекрестий потоков. "Приемники" работают на общий ресурс, который живет своей отдельной жизнью. Они имеют доступ к этому ресурсу последовательно, поочереди, в фоновом режиме. Поэтому опять же никаких столкновений интересов не наблюдается. Но сказать, что в моем случае нет никаких быстрых процессов, выполняемых параллельно, и вытесняющих друг друга по приоритету- будет неправильно. Они таки реализованы в задачах-источниках, целиком размещенных в ISR. Счастье - не счастье, а необходимость в вытесняющей OS сразу же отпала. Зачем лишние сущности?

Про scmRTOS - понятно. А вот Linux игнорируете напрасно, он специально заточен на описанный вами тип задач. По-моему, для борьбы со "сторонним кодом" неизвестных людей есть только одно средство - это round robin. От моих задач управления устройством описанное вами довольно далеко, а чтобы сразу несколько клиентов наваливались поуправлять режимами- так совсем невозможный и недопустимый вариант. Поэтому могу лишь посочувствовать и посоветовать обратиться к готовым решениям для серверных приложений. А это, увы, Linux и ему подобные OS. Мне хватает просто флага готовности, мол сообщение готово- можно забирать и использовать в своих целях. Само сообщение буферизовано задачей-источником, поэтому нет напряга по времени с реакцией на этот флаг. Не понял. Может, мы опять о разном говорим? Что вы подразумеваете под "конфигурацией web-сервера" через uart? Потомки Линукса для мобильных устройств, например Android, вполне приличное время работают от батарейки на платформе Cortex M4. Цена конечно выше, но не порядки.

Насколько я понял, вы реализуете готовые приемы, написанные дизайнерами сайтов? Может, в этом случае проще обратиться к готовым решениям на базе Linux для микроконтроллеров, а не тратить время на scmRTOS, предназначенную для малых кристаллов c ограниченными возможностями? Вот этого я не понял. С ответом на запрос по-моему в жизни никто особенно не торопит. Так зачем тогда все эти "приоритеты и вытеснения" именно для скриптов? Торопиться здесь надо только в одном месте- там, где входящие пакеты вываливаются из MAC, их нужно фильтровать, сортировать и выделять непосредственно http-query. А потом, с интерпретатором и скриптами, уже никакой гонки нет. Как раз именно потому, что нет никакой гонки в этом конкретном вопросе ембедерства, вполне себе может быть очень простой кооператив. Вы же, надеюсь, не центральный сервер для хостинга создаете на однокристальном микроконтроллере? Я так и знал, что говорим о разных вещах. Защищенные методы и данные обеспечивают только надежную сохранность контекста задачи, исполняемой в псевдопараллельном режиме. Синхронизация же процессов совсем из другой оперы. Как и обычно делают провайдеры, когда идет перепрошивка сайта- останавливают на какое-то время работу web-сервера, клиентам на запросы он выдает ошибку 500- busy, и занимаются переконфигурацией сколько надо времени. Вот, и вся синхронизация.

Вы слишком спешите с выводами. Нет никаких "конкурентных" потоков у периферии. Если от UARTa идут строки запросов, то они идут в строго определенный интерпретатор этих запрсов. И никто другой туда не сунется. То же самое, инапример, с Ethernet MAC-ом, после выделения, HTTP запросы поступают в строго определенный интерпретатор, и тоже никто к этому WEB серверу не сунется с чем-то другим. О каких таких "конкурентных потоках" вы говорите? Я их не наблюдаю. Наверное вы не поняли, что задачей в моем случае является ISR, которая оформлена в виде защищенного метода в классе с защищенными данными. Никто туда, кроме методов самого класса добраться не может. Какие такие "конкурентные потоки"? Можете представить конкретный пример? Я видимо чего-то упустил, но по-моему CGI основано на использовании .dll в серверах на ПК? При чем тут scmRTOS для малых 8-ми разрядных чипов?

А смысл? Зачем нужна вообще scmOS, если и без нее реализуются все те же самые функции вытеснения процессов с приоритетом и защищенность данных каждой отдельной задачи? Зачем мне осваивать ставшую ненужной OS и подлаживаться под ее условности? Этот язык я использую для опреления задачи реального времени как класса с защищенными методами и данными. Отдельные стеки, сохранять контекст каждой задачи, уже не неужно. Соответственно, одна из главных фич многозадачных OS с приходом C++ выглядит ненужной. [ коды skipped] Разделение приложения на "драйвер" и системную часть - очень условно и субьективно. В моем случае можете считать, в программе одни только" драйверы". И эти "драйверы", которые я упорно называю автономными паралелльными процессами, прекрасно взаимодействуют друг с другом и вытесняют друг-друга, без всякой центральной системной части. Конечно, это благодаря только современным чипам, в которых реализованы вложенные прерывания периферии с приоритетом. Видите ли, ссылаться на опыт прошлого, на проблемы со старыми чипами... как-то неконструктивно. Я знаю все те проблемы, сам наплясался с бубном всласть. Сейчас время другое- в чипах появились нормальные прерывания с приоритетом, периферия вся забуферирована через FIFO, не надо программно торопиться с пересылками блоков данных- это за нас делает DMA. Напичкали все, о чем мечталось лет десять назад. Так, пользоваться надо!

Точнее сказать, без привычной из прошлого OS. В реальности я получаю те же самые функции OS, вытеснение процессов с учетом приоритета, но использую фичи железа современных чипов, а не софт. Видимо, отсюда и непонимание друг-друга, программистов и железячников. В результате произведенной разведки scmRTOS, я понял главное - мне она не нужна. Извините, если кого обидел.

Нет, не целиком. Я вижу задачу периферии в виде статического класса C++, у которого только метод exec() оформлен как ISR от периферии. Конструктор же класса- отдельно. Также отдельно от ISR методы коммуникации с другими процессами. Если чип позволяет вложенные прерывания по приоритету, как например в последних Cortex, то автоматически решается проблема приоритетов задач. А использование задачи в виде класса с защищенными данными и методами автоматически решает проблему сохранения контекстов на переключениях, нет нужды в стеках для каждой отдельной задачи. Это вероятно дилетантский подход с точки зрения знатоков С++ и OS, но у меня, как ни странно, он работает в задачах связи. Ваш вариант использования того, что есть в scmRTOS - плох тем, что хочешь не хочешь, а придется идти длинным путем через OS, через диспетчер, через полинг, через арбитр приоритетов.... когда сработает, да и сработает ли вообще посланный signal - никто толком не знает. В моем варианте- все четко и практически мгновенно.

А по делу, - хочется видеть в составе scmRTOS класс задач, которые умеют ожидать настоящие прерывания от периферии. Безумный вариант через SW не предлагать. Еще хочется видеть эти прерывания вложенными по приоритету, т.е никаких запретов на время исполнения ISR. Видите, как просто -хочется, чтобы C++ наконец-то заработал на современных чипах. PS. Забыл совсем. SW прерывания для медленных фоновых задач вполне можно оставить, какие они сейчас уже есть.

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