www.open-tager.ru
http://www.open-tager.ru/forum/

Умный датчик. Smart sensor.
http://www.open-tager.ru/forum/viewtopic.php?f=5&t=4949
Страница 6 из 17

Автор:  onegray [ 31 дек 2016, 17:24 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

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

Автор:  Pingvin [ 01 янв 2017, 11:51 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

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

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

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

Вложения:
TIM1_PWM_INPUT.png
TIM1_PWM_INPUT.png [ 130.67 KiB | Просмотров: 9734 ]

Автор:  Pingvin [ 01 янв 2017, 12:59 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

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

Автор:  Pingvin [ 01 янв 2017, 13:31 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

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

Автор:  Alexies [ 01 янв 2017, 18:07 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

Pingvin писал(а):
HAL - это здорово, но хочется уже разобраться во всём на уровне регистров.

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

И по-моему интересней решать действительно сложные задачи (хорошие протоколы, надежная радиосеть, всякие "обратные связи", смарт-карты и другие андроиды :) ), чем очень хорошо понимать, какие биты в регистре управления таймером решили сделать ST Electronics.
Pingvin писал(а):
Кстати - почему бы и на HAL не попробовать режим аппаратного захвата ШИМ? :?
Он подробно описан в референс мануале.

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

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

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

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

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

Автор:  Pingvin [ 01 янв 2017, 18:36 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

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

Добавьте определение таймаута на третьем канале и не надо будет из основного цикла следить за переполнением.
Цитата:
Да, разумеется. Как что-нибудь заработает, сразу напишу подробное описание.

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

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


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

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

Автор:  Alexies [ 01 янв 2017, 19:56 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

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

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

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

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

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

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

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

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

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

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

Pingvin писал(а):
Шире надо мыслить, тут прав LTagKirov - не надо циклится только на датчике.

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

Автор:  Pingvin [ 01 янв 2017, 20:08 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

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


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

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

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

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

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

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

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


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

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

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

Автор:  Alexies [ 01 янв 2017, 20:21 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

Pingvin писал(а):
И почему Вы протв ws2812?
...
Могу драйвер оформить в виде статической библиотеки (если неохота с SPL связываться) - подключите к своему проекту - и всех делов!
Да и сами сможете - исходники дам.
;) :)

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

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

Автор:  Alexies [ 01 янв 2017, 20:48 ]
Заголовок сообщения:  Re: Умный датчик. Smart sensor.

Pingvin писал(а):
Никаких сбоев!

Я просто написал про хороший стиль, а не про то, что ничего работать не будет. Но я против подхода "работает - и ладно"
Pingvin писал(а):
Я приводил код обработчика - где там "существенные операции"?

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

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

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

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

В упор не виду противоречия. Какие предложения отвергаются? Всё переделать, чтобы было как у вас в прототипе? Какая разница, как декодируется ИК, если это делается корректно и понятным образом? API всё равно будет эквивалентный что у вас, что у меня. За что тут нужно аргументировать?
Alexies писал(а):
А вообще, это осуждение бессмысленно. Прием ИК - элемнтарная задача. Любой вариант можно написать и отладить полностью за 3 часа с нуля, ну серьезно.


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

Страница 6 из 17 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/