www.open-tager.ru

С утречка пришла мысль - попробую просто отключать режим полудуплекс на время передачи!
То есть "разъединить" ножка Rx и Tx

P.S. Не сработало от слова СОВСЕМ. Ну и хрен с ним, пусть ловет, просто буду приемный буфер очищать после передачи данных.

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

Просто отбрасывайте пакеты, которые не предназначены данной плате по адресу.

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.

Для переключения прием/передача в полудуплексе нужно ещё что-то делать, кроме непосредственно включения передачи или приема. Через HAL это делается функциями

и

Что у них внутри - не смотрел. Моя реализация в этом файле: https://github.com/DAlexis/lasertag-sma ... p-driver.c . Это драйвер библиотеки на стороне сенсора.
Ну и плюс сгенерированный кубом инициализатор uart: https://github.com/DAlexis/lasertag-sma ... rc/usart.c , но там ничего необычного кроме HAL_HalfDuplex_Init вместо HAL_UART_Init

<а тут блок ненавязчивой рекламы STM HAL, текст можете придумать сами >

Да я мечусь между SPL, HAL и регистрами.
HAL тоже не идеал, нет гибкости.
У регистров тоже свои плюсы есть.

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

Мне кажется, проблемы на самом деле нет. Покажите пример, где не хватает возможностей или гибкости HAL, и я уверен на 95%, что смогу предложить корректное решение в рамках HAL.

Делать обычные операции через регистры напрямую имеет смысл только если нужно выжать абсолютный максимум производительности в каком-то отдельном месте. Но почти всегда это означает, что лучше взять более мощный МК: ведь может потребоваться ещё чуть-чуть скорости... Код с регистрами труднее читать, и как следствие поддерживать и развивать. Если рутинные вещи вроде разбора флагов прерываний или настройки какого-нибудь DMA делать каждый раз вручную, легко ошибиться. В то время как в HAL код очень качественный и безопасный, везде есть assert-ы и т.п.

SPL можно воспринимать, как неудачную версию HAL. Много разнородных функций, нет единообразия. Приходится держать в голове особенности устройства конкретного МК. Если получилось настроить интерфейс XXX1 в каком-то режиме, то настройка интерфейса XXX2 может требовать каких-то неожиданных новых манипуляций (под XXX может быть что угодно: таймеры, UART, I2C...)

Давайте настроим PWM INPUT на таймере 3.

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

Коррекнтный код должен сгенерироваться при таких настройках в кубе:



Может забыл какую мелочь. Полярность надо поменять, если работать с выходом TSOP-а.

Дальше только написать коллбэк по нужному событию и в путь.

Не, не пойдет!
Первый и второй каналы должны быть настроены на захват, но разных фронтов.
Второй канал должен брать сигнал с той же ножки, что и первый.
Кроме того, режим SLAVE должен быть настроен так, чтобы сбрасывал счетчик таймера в 0, когда приходит фронт, по которому работает второй канал.
Этот режим в даташите описан подробно.

Ну и кроме того, чтобы не было переполнения, третий канал настраиваем на сравнение.

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

Согласен, немного поторопился. Забыл настроить первый канал

Да, поле Master/Slave mode забыл поправить на втором скриншоте

Это не обязательно. У таймера и так есть период и обработчик прерывания переполнения. Код будет проще, если обойтись этим.

Но не суть. Смысл в том, что всё это прекрасно делается через HAL. Конкретно такую конфигурацию я сам не пробовал, потому и неточности, но использовал похожую с захватом внешнего сигнала в двух проектах на разных МК (в смарт-сенсоре и другом проекте на STM32F4). Завелось все быстро, минимум раскуривания документации, максимум программирования смысловой части

Безусловно можно.

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