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

jcxz

Свой
  • Постов

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

  • Посещение

  • Победитель дней

    29

jcxz стал победителем дня 28 марта

jcxz имел наиболее популярный контент!

Репутация

174 Очень хороший

4 Подписчика

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

  • Звание
    Гуру
    Гуру
  • День рождения 01.12.1974

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

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

25 800 просмотров профиля
  1. Какая разница как оно объявлено? Оптимизатор видит, что оно всегда одно и то же, значит = const. Тогда странно. В Кейле не шарю. Возможно какие-то оптимизации проводятся уже на этом уровне. Не видя ассемблерного выхлопа, сказать ничего невозможно. Советую вам научиться заглядывать в окно дизассемблера. PS: Отлаживать нужно ассемблерный код. Смотреть только на си-строки - бесполезно. На этапе выполнения кода нет уже никакого си.
  2. ...который вы не можете запустить. Тогда в чём его "отличность" интересно? Может он вообще не работает? На практике. PS: Опять болтаете о том, чего не знаете.
  3. Всё правильно. Так и должно быть. Непонятно - почему вы ожидали иного? Судя по приведённому коду, mode у вас = const. А значит любой вменяемый оптимизатор во всех выражениях будет вместо неё подставлять 0 (даже если выделит место в ОЗУ для неё, то читать оттуда всё равно не станет). И вообще удалит все ветки switch/case для ненулевых значений mode.
  4. Я вообще-то говорил о способе избавиться от необходимости volitile, а не о размещении.
  5. Достаточно передать указатель на этот массив в ассемблерную функцию (где-нибудь вызываемую естественно) и можно не беспокоиться, что оптимизатор создаст её копии и можно обойтись без volatile. Указатель на этот массив в си-шные функции лучше тоже передавать через ассемблерную прослойку. Костыль конечно, но не тяжёлый.
  6. Кстати: И на ОС уровня FreeRTOS на Cortex-M тоже можно существенно уменьшить время реакции на прерывание. Вплоть до времени выполнения одной непрерываемой операции CPU (команды или входа/выхода в ISR). Т.е. - убрать задержку, вызываемую запретом прерываний при классических критических секциях. Просто делать не запрет всех прерываний, а только маскирование их через регистры NVIC, оставляя незамаскированными критические прерывания. ~12 лет назад писал код для PRUSS в OMAP L137 - документация была. И была открытой. А если она тогда была, то значит и сейчас есть. Ведь Всемирный Разум ничего не забывает. Если что-то где-то когда-то было в открытом доступе, значит наверняка где-то сохранилось. Даже если сейчас на официальном ресурсе недоступно.
  7. Это с чего это "не даёт"? Раньше давал, а теперь почему перестал?
  8. Раз уж решили править стек и прочее, то может стоит сперва хотя-бы почитать как работает система прерываний в вашем CPU? Всё детально разжёвано в документации на ядро. И как происходит выход из прерывания, и какие есть режимы CPU, и переключение стеков (MSP/PSP) - всё там есть. Если нужно выйти из ISR в определённый адрес, то можно подменить в стеке адрес возврата и выйти штатным образом. Также можно отредактировать содержимое LR, чтобы изменить режим CPU и активный стек после выхода. Но совершенно непонятно - на кой это нужно? На кой вообще потребовалось править MSP при запущенной ОС? Складывается впечатление, что вы не понимаете как работает ОС в целом. Поэтому и такие странные хотелки. ЗЫ: "Объяснять на пальцах" всё это - невозможно. Раз уж решили заниматься системными вещами и вмешиваться в работу ОС, то нужно предварительно глубоко изучить функционирование CPU и научиться читать документацию. Также нужно знать и уметь писать на ассемблере. Иначе - лучше не заниматься не своим делом.
  9. Что мешает положить её например - в один из неиспользуемых векторов таблицы векторов прерываний? И забыть о проблеме.
  10. полноценный линукс на "мелких МК" (типа Cortex-M) не возможен по определению. Меньше всяких "блохеров" читайте.
  11. stm32f747 + Ethernet (LwIP)

    Или недобор? max ведь не указано. А значит и 0.5с может не хватить. И почему 0.5с, а не 5с или не 50с? ЗЫ: Вобщем, как уже сказали - решение с задержкой кривое. Сегодня работает, завтра - нет. Но ТСу лень читать документацию, чтобы сделать правильно.
  12. stm32f747 + Ethernet (LwIP)

    Наверняка есть. Но это же документацию читать надо.
  13. Всё а не всё. Всё-таки CPU с FIQ/IRQ гораздо шустрее реагируют на прерывания, чем Cortex-M с NVIC.
  14. Я вообще-то писал не про время входа в свой ISR, а про случай, когда ваше срочное прерывание возникло в тот момент когда уже только начался вход/выход в другой ISR. И писал это не про ARM-ы с переключением состояний FIQ/IRQ, а про Cortex-M с его NVIC (STM32). Никакой стабильности там быть не может по определению. А будет джиттер в десятки тактов (опять же - Cortex-M).
×
×
  • Создать...