Easyelectronics.ru

В проекте используется STM32L0xx, также FreeRTOS версии 10.хх.хх, частота MCU порядка 4МГц
Есть определенный драйвер для работы которого, нужно сделать задержку порядка 500uSec. Драйвер генерит частоту на одном из GPIO сконфигурированным как выход. Используються стандартние функции HAL_GPIO_WritePin() для установки Pin в высокий или низкий уровень. Между пиками нарастающего фронка еще происходит вызов HAL_GPIO_ReadPin() для другого пина. Вкратце драйвер питается читать энкодер водяного счетчика, написан крайне криво... Стал переписывать весь бред написаный до меня и столкнулся с проблемой, задержки в 500uSec стали плавать от 550 до 700uSec
.
Для организации задержек, подключил один из аппаратных таймеров в режиме щотчика. И в цикле вычитываю регистр таймера сверяя из нужним значениям. Преривания для таймера не использую. FreeRTOS настроена на переключения планировжика в 1 милисекунду

Вопрос:

Как правильно организовать такие точные кратковременные задержки вместе из FreeRTOS?

configTICK_RATE_HZ сколько? У FREERTOS есть vTaskDelayUntil которая учитывает время выполнения кода. И позволяет сделать точную задержку.

1000 тиков мало для таких задач увеличивайте хотя бы до 2000. При 2000 один тик будет 500мкс, vTaskDelay(1) будет равняться 500мкс. Для точных периодических задержек нужно юзать vTaskDelayUntil учитывающая время кода.

#define configTICK_RATE_HZ ((TickType_t)1000)

Только боюсь этот параметр мне менять НЕ позволят ...
Так как в проекте на этом завязано еще куча вещей

Я попробую ваш совет. Хотельсь би еще дополнительной инфы как правильно работать из таймерами в таком варианте

По другому через ОС не сделаешь. У нее шедулер с 1000 тиками работает. Меньшее время она не отмерит тебе. Если менять не можешь. Тогда запускай таймер в режиме один импульс на 500мкс и жди прерывания/флага

Так таймер и запущен, что ждать в цикле, что в прерывании дают один и тот же результат, время плывет от 550 до 700usec. Невозможно добится точной задержки.

Вот код задержки

С таймером очень просто делитель настрой, чему будет равен один тик таймера (промежуток времени), далее запиши в ARR до скольки тебе посчитать таймер должен, включаешь таймер в режиме OP (один импульс) и ждешь когда он выключиться проверяя бит CEN (включение). Режим Один импульс автоматически выключает таймер когда досчитает до ARR регистра.
void delay_us(unsigned int delay)
{
TIM7->PSC = 8-1; //для частоты 8мгц, одно значение ARR будет соответствовать 1 мкс
TIM7->ARR = delay;

TIM7->CR1 |= TIM_CR1_CEN | TIM_CR1_OPM;
while (TIM7->CR1 & TIM_CR1_CEN);
}

Настрой свободный таймер где-нибудь в начале, а потом просто пинай его включением хоть тыщу раз. Пнул, проверил флаг. Пнул проверил флаг. Все элементарно. И это завязывай с HAL работать. Мозг атрофируется

Спасибо, буду пробовать.
Завязать не могу)) Таковы требования клиента

Единственное когда задержку вводишь заблокируй шедулер на время. Чтобы не переключал тебя. Когда флаг поймаешь разблокируй шедулер. Потому что может получиться так что пока ты ждешь тебя шедулер может переключать. Смотри по ситуации.

vTaskSuspendAll ();
{
/ * Планировщик здесь приостановлен. * /
}
xTaskResumeAll ();

Слуште, ну вы уж совсем тавой... На 4 МГц - и РТОС? Да ну вы что, окститесь! На такой частоте с и с такой частотой системных тиков ядро РТОС забирает половину процессорного времени, если не больше. Каждые 4000 тактов работа передается ядру РТОС, которое тратит нехило так тактов - вы видали портянки исходников? И что остается в сухом остатке?
Вы етну РТОС готовы пихать даже на таймер выключения света.
Какие там еще "требования заказчика"? Заказчик в подавляющем большинстве случаев даже не представляет, какими буквами пишутся программы, а не то чтобы прям 1000 тиков РТОС, да еще и на ХАЛе.

Не занимайтесь ерундистикой, работаете на 4 МГц - работайте без РТОС. Чего вы там не можете распихать без РТОС? Опрос кнопок и работу дин.индикации для четырехразрядного семисегментника? Да ну вы блин ну вы чо. Если по-простому, то по прерыванию TIM2 опрашиваете кнопки и определяете нажатую, а по прерыванию TIM3 переключаете разряды семисегментника.

Если используете динамическое управление тактовой частотой МК, то на время работы в медленном режиме останавливайте планировщик задач и пусть прога работает в отдельной изолированной части без РТОС. Но тут, как я понимаю, не тот случай.

Ну а если никак не умеете, кроме как с РТОС, то увеличивайте частоту МК до 24-36 МГц и не мучайте котенка. Ну раз никак не умеете.
Капец, РТОС издревле была как инструмент для очень насыщенных и сложных задач на "оборотистых" процессорах и МК, а в результате популяризации стала предметом для поиска приключений на неокрепшие головы "молодых учоных".
Некоторое время назад люди умудрялись запихивать в мелкий PIC16 столько всего сразу, и при этом безо всякой РТОС. Умели грамотно составлять автоматы состояний и пользоваться прерываниями.

Не в защиту ТС, но по ходу у него переданный от какого-то индуса проект, который уже закажчики заипались сто раз переделывать, поэтому с ножом к горлу к нынешнему разработчику пристали ничего не менять, шоб оставить все как было, но сделать еще лучше.
Самый лучший совет, конечно был бы в таких обстоятельствах - посылать такого заказчика далеко и надолго, ибо лох. Хотя, конечно, понимаю, что далеко не в каждой ситуации такое возможно.
Если уж действительно невозможно послать заказчика, то совет простой: сделайте приоритет прерыванию таймера выше приоритетов RTOS и засуньте обработчик счета импульсов прямиком туда. Только будьте осторожны, 500мкс на частоте 4МГц - это совсем немного, особенно не развернуться.

P.S. По своему скромному опыту могу сказать, что RTOS реально нужна там, где мелкоконтроллеру наряду с особенно тяжеловесными задачами какого-нибудь управления нужно много общаться по разным-всяким тяжеловесным протоколам одновременно и еще в файловую систему писать. Особенно когда эти протоколы пишет много разных человек с разным опытом разработки, от умеющих декомпозировать задачу на автоматы, до тех, кто все делает на тупых задержках по полсекунды.

Всё бы ничего, но как я написал, при таком соотношении тактовой частоты и частоты тиков - это ахтунг. Каждые 4000 тактов происходит вызов системных функций, длительность которых зависит от количества используемых ресурсов РТОС. Среднее время выполнения одной ассемблерной инструкции - 1,2 такта частоты МК. Среднее время выполнения одной сишной строки - в 3-5 раз дольше.
Так что - либо снижайте частоту систиков, либо повышайте частоту МК.
РТОС с мелкими МК никогда не давала "бесплатной прибавки" мощности. РТОС лишь компенсировала неумение программиста распределять процессорное время.

Мне кажется время плавает потому что планировщик на время некоторых операций для обеспечния атомарности запрещает прерывания.
Я в подобной ситуации прерывание от DCMI вынес за пределы freertos, а сигнал процессу подавал через программное прерывание, которое уже у фриртоса было. Т.е. получается так: прерывание DCMI с приоритетом выше чем configMAX_SYSCALL_INTERRUPT_PRIORITY и программное прерывание с приоритетом ниже чем configMAX_SYSCALL_INTERRUPT_PRIORITY. DCMI крутится себе и фря его не может прервать. Когда кадр получен и предпосчитан (на самом деле там просто RGB565-RGB888), генерирую программное (а у него приоритет ниже - помним, да?) и оно сработает когда я из dcmi выйду. А в этом программном уже сервисы фриртоса можно пользовать - очереди, семафоры и все такое. И именно оно уже будит основную задачу обработки. А задача обработки довольно тяжелая - еле-еле между кадров втискивается, а еще кнопочки/лампочки и прочий гуй.
Таким образом и сервисы оси для удобства и реалтаймовость критичного процесса.

Я выше 300 никогда не задираю - все работает хорошо.
Для столь малых интервалов есть инструменты во FreeRTOS, но таймер свободный все равно нужен.

Pingvin нет у нее никаких инструментов.

Реализация функции задержки меньше 1мс на FreeRTOS с помощью таймера и Task Notification
http://easyelectronics.ru/realizaciya-f ... ation.html

Чип STM32L0xx имеет достаточное количество аппаратных таймеров для этой функции, можно обойтись без прерываний - с выхлопом на любую ногу мк, если использовать дма в пакетном доступе через таймер(TIMx_DMAR). Там смещение получается дикое, в обратную сторону - чтобы добраться до регистров gpio - bsrr. Дма настраивается на событие от таймера и круговой режим.

Это не средства FREERTOS, а аппаратный таймер как его юзать без лишних телодвижения выше рассказал.

Через DMAR до GPIO?? Вы, батенька, йуморист. Посмотрите таблицу распределения адресного пространства. Там же под каждый GPIO выделен 1 кБ адресов и находятся они за 200 МБ о таймеров, а у DMAR диапазон 32х4 байта от начала регистров таймера, и только вперед.
GPIOx->BSSR доступен через обычный DMA, выбрав в качестве назначения абсолютный адрес регистра GPIOx->xxxx
Но всё это тут как бы не при чем. Если нужна работа с энкодером, то аппаратные таймеры TIM1, TIM2 и др. имеют режим работы с энкодером.
А раньше делали энкодер на внешних прерываниях.

Я делал на 14 таймере задержку отлично работает (можно любой свободный таймер), delay задается в микросекундах


Формировал сигнал для пульта RC-5 кодировка. Погрешность несколько мкс. Работает железно.


Сигнал для пульта.



делал конвертер команд на STM32F030. Стмка висит на IR приемнике и слушает команду в формате NEC, как только поступила, через 50мс выдает эту же команду но в формате RC-5 в приемник. В итоге включается и приставка и телевизор одновременно.