-
Постов
368 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о aprox
-
Звание
Местный
- День рождения 18.01.1949
Контакты
-
Сайт
Array
-
ICQ
Array
Информация
-
Город
Array
Посетители профиля
1 845 просмотров профиля
-
прерывания в C++
aprox ответил aprox тема в Программирование
ReAll Прошу обратить внимание на мой пост 2: Artem, где я ссылкой на официальный документ компилятора IAR для Cortex-M показал, что ваши приемы программирования прерываний нынче не работают. В разделе scmRTOS я много раз давал ссылку на кристаллы с ядром Cortex-M, тем самым образуя контекст разговора. Но почему-то оппоненты предпочли сердиться и нервничать вместо того, чтобы прочитать внимательно документацию на компилятор С++ IAR для Cortex-M. Вот и сейчас, с "профессионалами" происходит то же самое. Ну, прочтите же наконец о прерываниях документацию на компилятор C/C++ для Cortex-M! Тут мы вьезжаем в отдельную тему- что в эмбердерстве имеет практический смысл оформлять в виде классов, а что не имеет. Мое мнение таково- если в приложении имеется много однотипных обьектов, например кнопки, хранимые, индицируемые и редактируемые парметры, диалоговые окна, очереди, то безусловно имеет прямой практический смысл писать класс однотипных обьектов и потом тиражировать их в любом количестве. Если же в приложении обьект встречается один раз, а к этому случаю принадлежит практически вся периферия микроконтроллера, то тратить время и силы на создание класса такого устройства не имеет практического смысла, поскольку о тиражировании таких обьектов внутри одного приложения речи быть не может. ISR относятся как раз к таким, нетиражируемым обьектам. Поэтому включать их в состав методов класса не имеет никакого практического смысла. -
прерывания в C++
aprox ответил aprox тема в Программирование
Увы, по причине того, что контроллер прерываний в Cortex автоматически сохраняет контекст при срабатывании прерывания, становится уже ненужным управляющее слово __irq, обычно указывающее компилятору сохранять контекст программным способом. Вот, что пишут в той же доке IAR ARM, на которую вы же и ссылались: Иными словами, время старых, привычных решений уходит. "Врачу - исцелися сам." -
прерывания в C++
aprox ответил aprox тема в Программирование
Спасибо за ответ. Но ваша ссылка касается обсуждения исключительно в рамках scmRTOS, авторы которой наделали кучу заголовочных файлов с удобными им макросами. Я же работаю в стандарте C++ IAR v6.0 c библиотекой CMSIS специально для STM32. В этой библиотеке уже заготовлены все возмжные для каждого кристалла обработчики прерываний с заданными именами, начально это пустышки. Юзеру остается только наполнить эти пустые ISR своим конкретным кодом и обьявить этот обработчик дружественным в нужных классах. Других путей я не вижу. В хелпе IAR v6.0 для ARM и Cortex я не нашел управляющего слова __interrupt. А у директивы pragma не нашел параметра vector. Что я делаю не так? По-моему inline-подстановка в данном случае используется не по назначению. Не для этого она придумана. Да и вообще, задача сделать метод класса обработчиком прерывания имеет чисто академический интерес из той же серии- использовать обьектное программирование не по назначению. -
прерывания в C++
aprox опубликовал тема в Программирование
В разделе по scmRTOS, в процессе диспута про OS, я встретил пример кода на C++, в котором был представлен некий класс, описывающий работу UART. И в этом классе один из методов якобы был обработчиком прерывания! Как сделать обработчик прерывания отдельной функцией- мне понятно. Но как сделать метод класса таким обработчиком- совершенно неясно в практическом плане. Я работаю с кристаллами STM32 Cortex, пишу на C++, поэтому очень интересует данный вопрос. Если кто умеет назначать метод класса обработчиком прерываний- буду крайне признателен за наводку. -
Не желаете продолжить абортированную дискуссию? Меня по-прежнему очень интересует вопрос - как практически написать на С++ так, чтобы один из методов статического класса вызывался по прерыванию, и адрес точки входа в эту ISR был бы помещен компилятором+линкером в .intvect ? Если нетрудно, то конкретный листинг для STM32 Cortex.
-
Процессорная плата на ARM за $35
aprox ответил inforsis тема в Отладочные платы
Именно "никто подобного не делает" и должно вас насторожить в первую очередь. На мой взгляд, идея производить полуфабрикаты железа из рассчета на крупного оптового покупателя - идея абсолютно бесперспективна в комерческом и маркетинговом плане. Особенно в России. Вы же просили оценить маркетинговую сторону вашей задумки, а не техническую, правда? -
Спасибо за понимание. Остается только добавить, что каждый узел периферии в микроконтроллерах все больше получает оснований называться "отдельным процессором" на общей шине. По-моему, крайне неразумно игнорировать сей тренд современности и упираться рогом в чисто софтовые решения. Уже. Согласен, что решений много. Но категорически не согласен, что все они равноценны и имеют право на жизнь. Интересно, а как вы представляете себе еще можно оценить достоинства некого универсального инструмента вроде эхотажной 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 для этого не нужна.