Перейти к содержанию
    

aprox

Участник
  • Постов

    368
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о aprox

  • Звание
    Местный
    Местный
  • День рождения 18.01.1949

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

1 838 просмотров профиля
  • Tpeck

  1. ReAll Прошу обратить внимание на мой пост 2: Artem, где я ссылкой на официальный документ компилятора IAR для Cortex-M показал, что ваши приемы программирования прерываний нынче не работают. В разделе scmRTOS я много раз давал ссылку на кристаллы с ядром Cortex-M, тем самым образуя контекст разговора. Но почему-то оппоненты предпочли сердиться и нервничать вместо того, чтобы прочитать внимательно документацию на компилятор С++ IAR для Cortex-M. Вот и сейчас, с "профессионалами" происходит то же самое. Ну, прочтите же наконец о прерываниях документацию на компилятор C/C++ для Cortex-M! Тут мы вьезжаем в отдельную тему- что в эмбердерстве имеет практический смысл оформлять в виде классов, а что не имеет. Мое мнение таково- если в приложении имеется много однотипных обьектов, например кнопки, хранимые, индицируемые и редактируемые парметры, диалоговые окна, очереди, то безусловно имеет прямой практический смысл писать класс однотипных обьектов и потом тиражировать их в любом количестве. Если же в приложении обьект встречается один раз, а к этому случаю принадлежит практически вся периферия микроконтроллера, то тратить время и силы на создание класса такого устройства не имеет практического смысла, поскольку о тиражировании таких обьектов внутри одного приложения речи быть не может. ISR относятся как раз к таким, нетиражируемым обьектам. Поэтому включать их в состав методов класса не имеет никакого практического смысла.
  2. Увы, по причине того, что контроллер прерываний в Cortex автоматически сохраняет контекст при срабатывании прерывания, становится уже ненужным управляющее слово __irq, обычно указывающее компилятору сохранять контекст программным способом. Вот, что пишут в той же доке IAR ARM, на которую вы же и ссылались: Иными словами, время старых, привычных решений уходит. "Врачу - исцелися сам."
  3. Спасибо за ответ. Но ваша ссылка касается обсуждения исключительно в рамках scmRTOS, авторы которой наделали кучу заголовочных файлов с удобными им макросами. Я же работаю в стандарте C++ IAR v6.0 c библиотекой CMSIS специально для STM32. В этой библиотеке уже заготовлены все возмжные для каждого кристалла обработчики прерываний с заданными именами, начально это пустышки. Юзеру остается только наполнить эти пустые ISR своим конкретным кодом и обьявить этот обработчик дружественным в нужных классах. Других путей я не вижу. В хелпе IAR v6.0 для ARM и Cortex я не нашел управляющего слова __interrupt. А у директивы pragma не нашел параметра vector. Что я делаю не так? По-моему inline-подстановка в данном случае используется не по назначению. Не для этого она придумана. Да и вообще, задача сделать метод класса обработчиком прерывания имеет чисто академический интерес из той же серии- использовать обьектное программирование не по назначению.
  4. В разделе по scmRTOS, в процессе диспута про OS, я встретил пример кода на C++, в котором был представлен некий класс, описывающий работу UART. И в этом классе один из методов якобы был обработчиком прерывания! Как сделать обработчик прерывания отдельной функцией- мне понятно. Но как сделать метод класса таким обработчиком- совершенно неясно в практическом плане. Я работаю с кристаллами STM32 Cortex, пишу на C++, поэтому очень интересует данный вопрос. Если кто умеет назначать метод класса обработчиком прерываний- буду крайне признателен за наводку.
  5. Выпущена scmRTOS 4.0.

    Не желаете продолжить абортированную дискуссию? Меня по-прежнему очень интересует вопрос - как практически написать на С++ так, чтобы один из методов статического класса вызывался по прерыванию, и адрес точки входа в эту ISR был бы помещен компилятором+линкером в .intvect ? Если нетрудно, то конкретный листинг для STM32 Cortex.
  6. Именно "никто подобного не делает" и должно вас насторожить в первую очередь. На мой взгляд, идея производить полуфабрикаты железа из рассчета на крупного оптового покупателя - идея абсолютно бесперспективна в комерческом и маркетинговом плане. Особенно в России. Вы же просили оценить маркетинговую сторону вашей задумки, а не техническую, правда?
  7. Выпущена scmRTOS 4.0.

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

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

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

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

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

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

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

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

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