Easyelectronics.ru • Просмотр темы - FreeRTOS STM32F4 и внешние прерывания

Easyelectronics.ru

Электроника для всех
Текущее время: 16 авг 2018, 10:51

Часовой пояс: UTC + 5 часов



    • JLCPCB - Прототипы 10 PCBs всего за 2$ (100*100mm, 2-layer)
    • Как мы делаем платы, смотрите на YouTube
    • Крупнейшая китайская фабрика прототипов. 300000+ заказчиков и 10000+ заказов в день!
    • LCSC - Крупнейший китайский онлайн магазин комплектующих.

Начать новую тему Ответить на тему  [ Сообщений: 39 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 22:43 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Кстати, насколько я помню, HAL не шибко дружит с FreeRTOS. Там вроде как именно с прерываниями у него проблемы обычно.

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:06 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Еще один момент, который выплывает у меня периодически с FreeRTOSом и UARTом:
Неважно, UART на DMA или на прерываниях, если приоритет прерывания DMA или UART стоит ниже приоритета FreeRTOSa, то теряются данные, т.е. теряются прерывания. Если ставить приоритет выше RTOSа, то все данные приходят и уходят нормально. Но, как уже писали, нельзя пользоваться функциями RTOSa. Для UARTa я пользую RingBuffer для этих целей и пару флагов глобальных которые приходится периодически опрашивать.

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:08 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 2103
Для приёма байтов от датчика используйте DMA. Это полностью уберет загрузку процессора на операцию приёма с I2C.
После передачи адреса датчика и начального адреса регистра для считывания, запускайте DMA и ждите прерывания DMA_TCIF по завершению приёма. В обработчике этого прерывания разблокируйте задачу и немедленно переключитесь на нее для дальнейшей обработки принятых данных.
Либо просто ждите в задаче, ожидая бит TCIF завершения приема от DMA-потока. Но при большом количестве активных задач это нерационально, стопудово не успеете.

MasterAlexei, Насчет приоритетов DMA - просьба не торопиться с выводами! А то опять понапишите 32-битных.... эээ... Не торопитесь, не торопитесь. Главное, не запутайте топикстартера.

ЗЫ. Процессор то может быть и 32-битный, да вот адресация памяти у него - побайтная. 32-битный - это ширина шины АЛУ. Коммуникационные же шины поддерживают доступ шириной от 8 бит и аж до 256 бит у акселератора


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:12 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Еще момент - Как происходит отправка на уарт данных?
Как я понял, у вас в одной задаче и прием из I2C, и обработка, и отправка на UART. Последний момент как организован? Вы просто заряжаете прерывание TX и в нем идет опрос, сколько еще отправить?
А задача в этот момент ждет конца отправки всех данных?
Если нет, то тут RaceCondition : пока отправляется все на уарт, данные уже на следующем круге обработки поменялсиь, и (у вас же есть счетчик, сколько отправлять) при записи счетчика, или индекса текущего отправляемого байта, происходит сбой, и УАРТ вылетает за границы буфера.

Больше пока идей нет.


BusMaster писал(а):
ЗЫ. Процессор то может быть и 32-битный, да вот адресация памяти у него - побайтная. 32-битный - это ширина шины АЛУ. Коммуникационные же шины поддерживают доступ шириной от 8 бит и аж до 256 бит у акселератора

Там речь идет про регистры у I2C периферии. Там, по стандартам I2C памяти, они действительно 8ми битные.

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:16 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 2103
блин, чувак, да я в курсе про регистры периферии ... это же вы же начали писать про " регистр имеет тип uint32_t", хорошо что потом поправились...
И регистры у датчика могут быть и не 8-битными, а передаваться в два байта по интерфейсу. Например, регистры осей акселерометра - они 16-битные, передаются как 2 байта.

У топикстартера идет софтовый, через HAL прием данных из датчика. Один черт знает, сколько мусора тащит за собой эта "архигениальная" функция HAL, и черт знает, сколько стека задачи она жрет. Я не пользуюсь HAL-ом, потому и не знаю, куда именно складываются все переменные для функции HAL, но подозреваю, что в стек задачи. А во FreeRTOS-е нет жесткого ограничения, и если стек переполнился, то он просто налезает на другие участки памяти. Повреждение участка TCB моментально приведет к краху операционки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:29 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
BusMaster писал(а):
У топикстартера идет софтовый, через HAL прием данных из датчика. Один черт знает, сколько мусора тащит за собой эта "архигениальная" функция HAL, и черт знает, сколько стека задачи она жрет. Я не пользуюсь HAL-ом, потому и не знаю, куда именно складываются все переменные для функции HAL, но подозреваю, что в стек задачи. А во FreeRTOS-е нет жесткого ограничения, и если стек переполнился, то он просто налезает на другие участки памяти. Повреждение участка TCB моментально приведет к краху операционки.

Именно I2C софтовый у HAL не так уж много и отжирает, на самом деле - всего две функции там вызываются еще "вглубь" стека (сейчас глянул), просто они длинные, но не глубокие, так что не думаю, что именно в переполнении стека может быть именно проблема. Мне все же видится именно Race Condition, когда UART еще не кончил, а I2C уже начал (или кто там буфер для UART подготавливает).

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:32 
Старожил
Аватара пользователя

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 1375
Плёвая проблема уже две страницы обсуждается.
Исходники есть от всего.
Что бы не посмотреть отладчиком что происходит и исправить ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:40 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 2103
Оооййй, да это как обычно.... Телепаты, шоу экстрасенсов. Это как чтение детектива - с каждой страницей новый поворот событий, а в конце книги - "а убийца - семейный врач" :)
У нас тут только вторая страница пошла, причем половина первой - отвлеченная ерунда.
Я бы на месте столкнувшегося с проблемой че сделал бы: залез бы в браузер памяти, отыскал бы стек задач, посмотрел его изменение. Затем замерил бы время активности задачи, выставив банальные контрольки (дергания свободных ног) и через логич.анализатор бы глянул, а что где и куда идет, сколько времени идет прием и где начинается обработка, передача.

MasterAlexei писал(а):
, и УАРТ вылетает за границы буфера.
.

Это ровным счетом ничего не меняет! Я могу без проблем по УАРТ-у передавать ЛЮБУЮ ячейку с ЛЮБОГО адреса, взятого ВО ВСЁМ адресном пространстве размером 4 Гигабайта! Включая адреса периферии, адреса флеша, вобщем любой физически существующий адрес. Как вы знаете из курса Си, Си не отслеживает границы массива array[10].


Последний раз редактировалось BusMaster 22 ноя 2017, 23:54, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 22 ноя 2017, 23:44 
Старожил
Аватара пользователя

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 1375
Ну если только время скоротать - тогда понятно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 23 ноя 2017, 14:26 
Старожил
Аватара пользователя

Зарегистрирован: 01 ноя 2011, 23:51
Сообщения: 532
MasterAlexei писал(а):
Кстати, насколько я помню, HAL не шибко дружит с FreeRTOS. Там вроде как именно с прерываниями у него проблемы обычно.

Я б поспорил с этим. FreeRTOS интегрированна в CUBE MX. В конце концов ST не враги ж себе...
Ну и мой опыт показывает что если все правильно настроено то проблем нет. Хотя я HAL в чистом виде не использую и всегда тщательно изучаю как работает та или ф-ция.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 26 ноя 2017, 17:12 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 2103
Ну и раз на то пошло, дабы топикстартер не решил увеличивать частоту до 180 МГц или переходить на 210-мегагерцевый и вдвое более производительный F7xx, попробуем-ка решить эту беду на каких-то жалких 20 МГц...
Ставим задачу:
- по сигналу внешнего прерывания, следующего с частотой 1 кГц, принимаем пакет в 14 байт по I2C, работающем в режиме master-reciever,
- принятый пакет (пусть это будет 7 каналов 16-битных измерений, хотя не принципиально), направляем в какую-то гипотетическую обработку,
- и через каждые 10 принятых пакетов отправляем по UART (терминалка?) обработанные данные,
- и топикстартер хотел еще мигающий с частотой 1 Гц светодиод, пусть будет..

Задача поставлена, решаем ее. Для экономии процессорного времени задействуем DMA по максимуму - на прием по I2C и на передачу UART, освобождая время под математику обработки сигнала.
(блин, наверно будет очень многа букав кода, звиняйте за размеры портянок)

После инита хардвара МК пишем в main() создание задач:
Show


Теперь пишем функции, реализующие задачи.
Мигающий светодиод (очень просто):
Show


Задача приема из датчика. При первом запуске задачи сразу создается очередь на 10 элементов, каждый из которых размером в 14-байтный пакет. Эту очередь мы будем использовать для хранения в ней всех 10 принятых пакетов. Поскольку механизм очередей представляет собой копирование из источника в очередь, то данные буфера могут быть перезаписаны без потери предыдущих.
Также создаются два семафора для синхронизации с прерываниями: xSensorActive - для запуска от EXTI и для возобновления по окончанию приема через DMA от I2C, и xTransferToProcessing - для синхронизации с процессингом данных.
И еще включается реакция на внешние прерывания EXTI.
Show


Теперь задача обработки данных. Чтобы не размазывать текст, привожу с упрощениями, в виде "черного ящика". Там вообще без разницы, какой фильтр и как именно обрабатываются. Суть в том, что задача ожидает заполнения очереди на все 10 пакетов (по условию топикстартера), и как только очередь полностью заполнена, начинается извлечение из очереди и обработка пакетов. Благодаря такому подходу, процессинг может выполняться в 10 раз реже и есть больший запас по времени на длительную обработку. Этим, собственно говоря, и достигается уменьшение потребной частоты МК.
Show


Ну и собственно задача для UART. Так же, чтобы не размазывать портянки, упрощенно. Все необходимые операции с запуском DMA условно опущены.
Show


Теперь дело за обработчиками аппаратных прерываний. Тут тоже просто - сброс флага прерывания и выдача семафора, формирование стоп-бита для I2C по завершению приема через DMA.
Show


Ну и в завершении - драйвер I2C, в предельно сокращенном виде, с функциями инита I2C и чтения с интерфейса через DMA:
Show


Вот графики работы:
INT - по фронту, внешнее прерывание
DATA, CLK - пакеты интерфейса I2C
pa3 - обработчики аппаратных прерываний - по EXTI (в начале пакета) и по DMA TCIF (в конце пакета)
pa4 - активность задачи Sensor (первый импульс - начало чтения из датчика, второй - передача в очередь готового пакета)
pa5 - активность задачи DataProcessing. Вначале наблюдаются пачка из 10 импульсов - это чтение из очереди в задачу. На обработку выделено аж 3 мс, правда, из этого времени нужно вычесть время активности других задач, но всё равно, остается порядка 20-25 тыс. тактов, а это приблизительно 15 тыс. ассемблерных инструкций.
UART - активность задачи UART
Конечно же, работает всё стабильно хоть 10 минут, хоть час. И даже при 20 МГц остается еще примерно 45-50% процессорного времени для "плюшек с фишками". На последенем скрине - красный график, заполнение графика - это свободное процессорное время, которое можно использовать. Фиолетовый график - усредненная загрузка процессора, от 0 до 100%. И это - всего лишь 20 МГц!
Вложение:
DS1Z_QuickPrint37.png
DS1Z_QuickPrint37.png [ 4.64 Кб | Просмотров: 1705 ]

Вложение:
DS1Z_QuickPrint38.png
DS1Z_QuickPrint38.png [ 4.6 Кб | Просмотров: 1705 ]

Вложение:
DS1Z_QuickPrint39.png
DS1Z_QuickPrint39.png [ 5.92 Кб | Просмотров: 1625 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 26 ноя 2017, 22:17 
Старожил
Аватара пользователя

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 1375
Для полного счастья SensorInterface_Init надо на прерывания от I2C сделать (вместо while).
И ошибки i2c тоже желательно проверять.
А то может раком всё встать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 26 ноя 2017, 23:41 
Старожил
Аватара пользователя

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 2103
Тоже можно. Но на такой низкой скорости (всего 20 МГц) это неэффективно. Накладные расходы операционки сжирают на переключениях всё выигранное время. Участок, обслуживающий запрос к датчику - всего около 80 мкс.
А обработку ошибок я просто не стал писать, чтобы не размазывать портянку текста в сообщении.
Цель поста - я хотел показать, что при более-менее грамотном подходе можно получить стабильную работу даже на скорости ЦПУ в 8 раз ниже той, на которой не вышло у топикстартера.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: FreeRTOS STM32F4 и внешние прерывания
СообщениеДобавлено: 27 ноя 2017, 00:13 
Старожил
Аватара пользователя

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 1375
Да я никаких претензиций не высказываю.
Работа огромная проделана, а гуру программирования уже сами добавят, что надо.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 39 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB