www.open-tager.ru

Добавленный фунционал привносит добавленную сложность - это нормально. С HAL-ом или без, но если вы захотите реализовать аппаратный break, то вам придется эту сложность принять.
C новым годом!

Всех с Новым годом!

HAL - это здорово, но хочется уже разобраться во всём на уровне регистров.
Не думал, что столько вопросов появится при работе с "расширенным" таймером.
С базовым все получается "с пол оборота".
Захватить сигнал так же им не получилось.
Опять буду пробовать реализовать ШИМ.

Кстати - почему бы и на HAL не попробовать режим аппаратного захвата ШИМ?
Он подробно описан в референс мануале.

Проблема в том, что в данном чипе в Таймере 1 нет у первого канала выхода на ножку.
Есть только у второго канала.
Можно ли настроить захват в режиме PWM INPIUT со второго канала - я так и не понял!


С режимом Slave тоже много не понятно!
Как это работает?
Кто Slave, кто Master, где это настраивается?


Ну даже хрен с ним, с захватом - можно оставить на 3 таймере!
Почему нормально не работает PWM 1 режим в связке с DMA?

Буду разбираться, что сложно сделать в отсутствие того же логического анализатора или нормального осциллографа.

P.S. Обалдеть! Разобрался с PWM 1 режимом буквально за 3 минуты после того, как написал сей пост!
А если точнее - с настройкой вызовов к DMA
Стоило только внимательно почитать РефМан.
Вот чего не хватало!
TIM1->CR2 |= TIM_CR2_CCDS;

Это значит запросы к DMA будут генерироваться при достижении счетчиком максимального значения, а иначе - запросы отправляются при захвате/сравнении!

CCDS: Capture/compare DMA selection
0: CCx DMA request sent when CCx event occurs
1: CCx DMA requests sent when update event occurs

Ну теперь смело можно сказать - свето-цветовая индикация и захват сигнала у нас есть!

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Сделаю мишень с подобными эффектами
https://youtu.be/q_2Rpf_zCLY?t=7
чтобы при попадании был эффект разлетающихся горящих осколков.
Цветом команды стреляющего игрока.
И дисплей можно замутить для точки захвата
https://www.youtube.com/watch?v=DPuOVSwzLBo

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Alexies, кроме исходников хотелось бы подробное описание протокола.
И нужно учесть, что RGB диод может стоять не один.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Если во всем так разбираться, то никакого времени не хватит. Вот например работа с SD-картой: один только протокол SDIO чего стоит. Вряд ли кто-то станет писать свой драйвер с нуля, да ещё и на уровне регистров.

И по-моему интересней решать действительно сложные задачи (хорошие протоколы, надежная радиосеть, всякие "обратные связи", смарт-карты и другие андроиды ), чем очень хорошо понимать, какие биты в регистре управления таймером решили сделать ST Electronics.

Так мой код и использует аппаратный захват через HAL (Input Capture mode и "захват ШИМ" - это одно и то же).


Да, разумеется. Как что-нибудь заработает, сразу напишу подробное описание.

Не один диод - в каком смысле? Чтобы два диода в одном датчике горели разными цветами? Это зачем?

Вообще, по моему опыту на один круглый датчик диаметром платы 30мм (под корпус LW) не нужно двух RGB-диодов. Одного хватит, чтобы видеть с любого расстояния. А второй - только лишнее энергопотребление. На моих платах сейчас по два диода, потому и говорю - это лишнее

Добавьте определение таймаута на третьем канале и не надо будет из основного цикла следить за переполнением.

Ну я надеялся поучаствовать хоть в каком то открытом обсуждении протокола.




Ну для более наглядного визуального различия разных игровых событий, к примеру.
А что - для точки захвата ещё один протокол писать что ли?
Или электронной мишени?
Я может сделаю "прогресс-бары" захвата на светодиодных лентах ws2812
Шире надо мыслить, тут прав LTagKirov - не надо циклится только на датчике.
На этом чипе можно много всякого полезного барахла реализовать.

И почему Вы протв ws2812?
Используется одна ножка контроллера (против 3 для обычного RGB) - цепляй хоть 500 шт, лишь бы оперативы хватило для буфера.
Стоит 6 р.
https://ru.aliexpress.com/item/50-1000p ... =200001051
Очень яркий.
Схемотехника проще.
Разводка проще.
Чем плох?
Могу драйвер оформить в виде статической библиотеки (если неохота с SPL связываться) - подключите к своему проекту - и всех делов!
Да и сами сможете - исходники дам.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Мое решение обосновано несколькими причинами:
- Как только придут данные по ИК, их нужно скопировать в отдельный буфер, поскольку время обработки может быть существенным (оно включает, как минимум, передачу по UART, возможно медленному). Поскольку правильно писать в прерываниях минимум кода, то операцию копирования лучше вынести оттуда. Всё равно использование буфера будет из главного потока. А если выносить копирование, то логично вынести и проверку таймаута, которая разрешает копирование. Иначе придется вводить дополнительный флаг и чего-то усложнять.
Думаю, не нужно объяснять, почему делать тяжелые прерывания - это плохой стиль программирования. Конечно, это не критично в данной задаче, но это не повод писать абы что и абы как, лишь бы работало.
- Для демодулирования ИК я использую TIM14, у него только один канал. Поскольку на 100% ещё не ясно, что будет в устройстве, я решил сэкономить многоканальные таймеры.
- "Пионеру", не знакомому с нюансами работы STM32, будет проще понять мой код.
- Мой код ИК-демодуляции не менее функционален, и при этом уже полностью готов для реального использования.

А вообще, это осуждение бессмысленно. Прием ИК - элемнтарная задача. Любой вариант можно написать и отладить полностью за 3 часа с нуля, ну серьезно.

Я просто хочу предложить отправную точку, от которой можно начать. Чтобы было что расширять и редактировать. Обычно протоколы коллективно придумывают именно так: кто-то готовит драфт, его улучшают. Конечно всё открыто обсудим!
А в целом - мы вроде и занимаемся уже обсуждением (про диоды)


Протокол должен быть расширяемым. Если вам кажется, что он как-то применим в мишени или контрольной точке - ради бога, приделаете соответствующие расширения. Когда это понадобится.
Я не понимаю, куда вы собираетесь ставить прогресс-бары. В датчики? И при чем здесь точка захвата? Очевидно, точка должна иметь свои мозги, радио, звук и нетривиальную логику.
Как ей поможет данный протокол?
Опишите модель использования протокола подключения смарт-сенсора в описанных вами случаях, будет понятней.

Один универсальный протокол (RCSP) у меня уже есть, и он действительно хорошо подходит для всех задач коммуникации игровых устройств. Делать второй такой же не надо по очевидным причинам. Использовать его в смарт-сенсоре не надо, тоже по очевидным причинам.


Есть хорошее английское слово overdesign. Это то, чего нам не надо
Не предлагаю я вводить какие-то ограничения функциональности заранее. Но проблемы нужно решать нужно по мере их поступления. Невозможно без итераций сразу разработать устройство, которое делает всё на свете. Нужно действовать поэтапно. Это же базовые принципы разработки чего угодно.
Есть тонкая грань между "шире мыслить" и "фантазировать".

Все прекрасно работает на 24 МГц в Армаде НА 4 КАНАЛАХ!!!!
Никаких сбоев!
https://www.youtube.com/watch?v=hfxMOxfElk0

Ещё и музычку играем!

Я приводил код обработчика - где там "существенные операции"?
Проверка интервалов на валидность, setBit() в приемный буфер, и тут же выход.

Зачем в прерывании отправка по UART?!

Сгенерим событие и обработаем в главном цикле.

Противоречия какие то - то не знаете, что ещё будет в устройстве, то на овер-чего-то-там намекаете.

Без обид - пионер в вашем коде ногу сломит!
Ни я, ни LTagKirov с ходу не разобрались.
Там все очень неявно (HAL усугубляет)!
Хотя, справедливости ради - анализ чужого кода всегда дело непростое.


Как я понял - будет два варианта датчика, ибо о взаимодействии речи быть не может, все предложения с моей стороны отвергаются "на корню", причем для меня аргументация сомнительна, мягко говоря... - ну пусть будет так!

Значит главное - протокол.

P.S. Да Вы на управление RGВ 3 канала таймера потратите все равно! Иначе софтовый ногодрыг городить с кучей дополнительных переменных и лишним кодом. К чему тумана напускать "не знаю, что ещё будет..."? А это либо один многоканальный таймер, либо 3 одноканальных. Где "экономия" + ещё 2 ножки контроллера потратите!

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Никакой трудности в подключении умных RGB-диодов нет.

Я не против, переход на смарт-диоды просто не даст _ничего_ нового. Зато обычные RGB-диоды позволят, например, максимально снизить габариты устройства за счет замены одного RGB на 3 маленьких отдельных диодика. Размер готового устройства выйдет чуть больше самого контроллера.
Конечно +5р к цене - это не существенно.
Давайте я сделаю на обычных, а вы потом добавите код поддержки smart, и в коде будет #define, который переключает режимы?

Я просто написал про хороший стиль, а не про то, что ничего работать не будет. Но я против подхода "работает - и ладно"

Вы приводили прототип кода, который как-то работает, а не готовый код. В нем даже нет двойной буферизации (чтобы пользователь читал из другого массива, который содержит копию принятных данных). Почему вы решили, что данные не изменятся прямо в процессе чтения пользователем - я не знаю. Как в такой ситуации ведет себя Армада - я не знаю. Очевидно, Армада гораздо быстрее обрабатывает данные, чем смарт-сенсор будет посылать их по UART.

Я сделал логичное предположение, что второй буфер Вы, конечно, добавите, когда код перестанет быть прототипом. Этот второй буфер будет медленно отправляться по UART. Естественно не из прерывания, а из главного цикла. Чтобы во втором буфере появились данные, их нужно как-то скопировать из первого буфера. Копировать можно либо в прерывании, либо - в главном цикле. Правильнее - в главном цикле. Определять таймаут можно непосредственно перед копированием. Это я и делаю - в главном цикле. Можно перенести в прерывание и добавить флаг - это не важно! Меньше флагов - меньше проблем.


Не нужно говорить за LTagKirov. Он вроде все понял в моем коде, хотя глянул "одним глазком": viewtopic.php?f=5&t=4949&start=20#p47643 .
Вы правда считаете, что в вашем коде, который в 2 раза длиннее (300 строк против 150), с неправильными отступами, без API и огромным количеством вложенных if-ов в обработчике прирываний пионер разберется быстрее?

В упор не виду противоречия. Какие предложения отвергаются? Всё переделать, чтобы было как у вас в прототипе? Какая разница, как декодируется ИК, если это делается корректно и понятным образом? API всё равно будет эквивалентный что у вас, что у меня. За что тут нужно аргументировать?


Да я всегда за мир во всем мире. И просто пытаюсь программировать в соответствии с простыми общепринятыми стандартами. Как делать API, как писать безопасный поддерживаемый код и т.п.