jcxz
Свой-
Постов
13 102 -
Зарегистрирован
-
Посещение
-
Победитель дней
29
jcxz стал победителем дня 28 марта
jcxz имел наиболее популярный контент!
Репутация
172 Очень хорошийИнформация о jcxz
-
Звание
Гуру
- День рождения 01.12.1974
Контакты
-
ICQ
Array
Информация
-
Город
Array
-
Кстати: И на ОС уровня 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).
-
Не верю! Сказки не надо рассказывать. Один вход или выход в ISR занимает уже десятки тактов (это если контекст FPU не сохраняется/восстанавливается; иначе будет ещё печальнее). Точно такие же сказки - максимальное время активации задачи во FreeRTOS == 900нс. По причине (как уже сказали выше) - что сервисы РТОС выполняются как правило при запрещённых прерываниях. ЗЫ: Сказочникам советую почитать описание CPU и посмотреть исходный код сервисов FreeRTOS. Для спуска с небес на землю... Кроме ПЛИС можно взять МК с богатой периферией, и реализовать нужный функционал силами этой периферии.
-
От ESP32 там нужен не WiFi, а BT.
-
и что с того?
-
Ну да Гладко было на бумаге, да забыли про овраги.... Один из моих прошлых заказчиков решил перенести наш проект (ранее реализованный на LPC17) на ESP32. "для удешевления" типа. Нашёл какого-то программиста, взявшегося за работу. И вот.... прошёл почти год. Насколько мне известно - до сих пор ещё результат не получен. Хотя в своё время, на LPC, первая версия девайса у нас заработала уже примерно через месяц. Периферии там немного. Да и в целом вроде девайс не особо сложный. Для обычного микроконтроллера по крайней мере. Хотя у меня с самого начала были большие сомнения насчёт реализуемости на ESP32. PS: И даже если заработает всё-таки, то боюсь заказчик будет неприятно удивлён временем его автономной работы (девайс имеет батарейное питание).
-
STM32 & PID-регулятор
jcxz ответил dimir тема в Программирование
Это не всегда так. А чаще вообще не так. Чаще целевым параметром ПИД-регулирования при управлении мотором, является не скорость, а крутящий момент. Например - в электротранспорте так. Потому что задающим воздействием, которое нужно выполнить ПИД-у, является величина нажатия педали акселератора водителем. Педаль задаёт крутящий момент, а не скорость. Аналогично - с электросамокатами и прочими средствами передвижения. -
Много чего. Например - инитит регистры отладки и включает таймер DWT. Если этот таймер используется в коде, но не проинициализирован, то будут проблемы. Наверное нужно всё-таки проверить просто рестарт, а не вкл. питания? С помощью сигнала RESET и с помощью соответствущего регистра сброса ядра или WDT. Если у вас инит регистров физики реализован криво, то он может не срабатывать из-за того, что физика ещё не закончила power-on reset. А вы уже пытаетесь в неё что-писать. Без контроля готовности. В этом случае после сброса по WDT или через ядро, старт должен быть нормальным, как из под отладчика.