jcxz
Свой-
Постов
13 108 -
Зарегистрирован
-
Посещение
-
Победитель дней
29
jcxz стал победителем дня 28 марта
jcxz имел наиболее популярный контент!
Репутация
174 Очень хорошийИнформация о jcxz
-
Звание
Гуру
- День рождения 01.12.1974
Контакты
-
ICQ
Array
Информация
-
Город
Array
-
Например любым эмулятором из: https://sauris.de/index.php/en/
-
Какая разница как оно объявлено? Оптимизатор видит, что оно всегда одно и то же, значит = const. Тогда странно. В Кейле не шарю. Возможно какие-то оптимизации проводятся уже на этом уровне. Не видя ассемблерного выхлопа, сказать ничего невозможно. Советую вам научиться заглядывать в окно дизассемблера. PS: Отлаживать нужно ассемблерный код. Смотреть только на си-строки - бесполезно. На этапе выполнения кода нет уже никакого си.
-
Удержание высоты
jcxz ответил whale тема в В помощь начинающему
...который вы не можете запустить. Тогда в чём его "отличность" интересно? Может он вообще не работает? На практике. PS: Опять болтаете о том, чего не знаете. -
Всё правильно. Так и должно быть. Непонятно - почему вы ожидали иного? Судя по приведённому коду, mode у вас = const. А значит любой вменяемый оптимизатор во всех выражениях будет вместо неё подставлять 0 (даже если выделит место в ОЗУ для неё, то читать оттуда всё равно не станет). И вообще удалит все ветки switch/case для ненулевых значений mode.
-
Считывание кейлом старт прошивки и ее длину
jcxz ответил Метценгерштейн тема в ARM
Я вообще-то говорил о способе избавиться от необходимости volitile, а не о размещении. -
Считывание кейлом старт прошивки и ее длину
jcxz ответил Метценгерштейн тема в ARM
Достаточно передать указатель на этот массив в ассемблерную функцию (где-нибудь вызываемую естественно) и можно не беспокоиться, что оптимизатор создаст её копии и можно обойтись без volatile. Указатель на этот массив в си-шные функции лучше тоже передавать через ассемблерную прослойку. Костыль конечно, но не тяжёлый. -
Кстати: И на ОС уровня FreeRTOS на Cortex-M тоже можно существенно уменьшить время реакции на прерывание. Вплоть до времени выполнения одной непрерываемой операции CPU (команды или входа/выхода в ISR). Т.е. - убрать задержку, вызываемую запретом прерываний при классических критических секциях. Просто делать не запрет всех прерываний, а только маскирование их через регистры NVIC, оставляя незамаскированными критические прерывания. ~12 лет назад писал код для PRUSS в OMAP L137 - документация была. И была открытой. А если она тогда была, то значит и сейчас есть. Ведь Всемирный Разум ничего не забывает. Если что-то где-то когда-то было в открытом доступе, значит наверняка где-то сохранилось. Даже если сейчас на официальном ресурсе недоступно.
-
Это с чего это "не даёт"? Раньше давал, а теперь почему перестал?
-
Раз уж решили править стек и прочее, то может стоит сперва хотя-бы почитать как работает система прерываний в вашем CPU? Всё детально разжёвано в документации на ядро. И как происходит выход из прерывания, и какие есть режимы CPU, и переключение стеков (MSP/PSP) - всё там есть. Если нужно выйти из ISR в определённый адрес, то можно подменить в стеке адрес возврата и выйти штатным образом. Также можно отредактировать содержимое LR, чтобы изменить режим CPU и активный стек после выхода. Но совершенно непонятно - на кой это нужно? На кой вообще потребовалось править MSP при запущенной ОС? Складывается впечатление, что вы не понимаете как работает ОС в целом. Поэтому и такие странные хотелки. ЗЫ: "Объяснять на пальцах" всё это - невозможно. Раз уж решили заниматься системными вещами и вмешиваться в работу ОС, то нужно предварительно глубоко изучить функционирование CPU и научиться читать документацию. Также нужно знать и уметь писать на ассемблере. Иначе - лучше не заниматься не своим делом.
-
Считывание кейлом старт прошивки и ее длину
jcxz ответил Метценгерштейн тема в ARM
Что мешает положить её например - в один из неиспользуемых векторов таблицы векторов прерываний? И забыть о проблеме. -
полноценный линукс на "мелких МК" (типа Cortex-M) не возможен по определению. Меньше всяких "блохеров" читайте.
-
Или недобор? max ведь не указано. А значит и 0.5с может не хватить. И почему 0.5с, а не 5с или не 50с? ЗЫ: Вобщем, как уже сказали - решение с задержкой кривое. Сегодня работает, завтра - нет. Но ТСу лень читать документацию, чтобы сделать правильно.
-
Наверняка есть. Но это же документацию читать надо.
-
Всё а не всё. Всё-таки CPU с FIQ/IRQ гораздо шустрее реагируют на прерывания, чем Cortex-M с NVIC.
-
Я вообще-то писал не про время входа в свой ISR, а про случай, когда ваше срочное прерывание возникло в тот момент когда уже только начался вход/выход в другой ISR. И писал это не про ARM-ы с переключением состояний FIQ/IRQ, а про Cortex-M с его NVIC (STM32). Никакой стабильности там быть не может по определению. А будет джиттер в десятки тактов (опять же - Cortex-M).