Возможно ли реализовать виртуальный uart на stm32?

Question

[Sneiksus]

Возможно ли реализовать UART передачу данных с STM32 с обычного цифрового пина?
Первая проблема что нужно при скорости 9600 бит/c передача одного бита должна происходить прмерно 1/9600 = 104 микорсекунды. HAL_Delay поддерживает минимальный период 1 милисекунда. Вторая проблема, не понимаю какой надо выставлять уровень напряжения на пине в простое, когда комуникация не происходит. Делал ли кто-то подобное и существуют ли какие-то библиотеки?

Answer 1

[jcmvbkbc]

Первая проблема что нужно при скорости 9600 бит/c передача одного бита должна происходить прмерно 1/9600 = 104 микорсекунды. HAL_Delay поддерживает минимальный период 1 милисекунда.

Это говорит о том, что нужно использовать другой метод для организации задержки. Например основанный на таймере со счётчиком.

какой надо выставлять уровень напряжения на пине в простое

Стандартно -- высокий логический. Сколько вольт этому должно соответствовать конкретно -- зависит от того, что вы подключите снаружи. Явно там будет какой-нибудь конвертор или другой микроконтроллер.

Comments

[Sneiksus]

jcmvbkbc Получится сделать задержку каждых 104 микросекунды с тактовой частотой чипа 2мгц, какие тогда ставить значения на прескалер и счетчик? И еще, если все вже использовать задержку длино 1мс, то это не будет работать на меьшей скорости? Когда ставишь скорость 9600 то чип прям ожидает что сигнал будет меняться точно с такой скоростью? Просто стало интересно если например подрят идут две логические единицы, то как он понимает что это два разных бита, а не один и тот же или переход в режим ожидания.

[pfg21]

Sneiksus, какие задержки. Таймер с прерываниями все прекрасно делают. HAL тут только помешает.

[jcmvbkbc]

Когда ставишь скорость 9600 то чип прям ожидает что сигнал будет меняться точно с такой скоростью? Просто стало интересно если например подрят идут две логические единицы, то как он понимает что это два разных бита, а не один и тот же или переход в режим ожидания.

Приёмник синхронизируется по спадающему фронту в начале стартового бита и ожидает что следующие информационные биты, бит чётности и стоповые биты прийдут с настроенной скоростью. Обычно приёмник самплит сигнал на повышенной частоте (мне встречались варианты до x16) и выбирает отсчёты из середины временного диапазона отведённого биту. Это позволяет передатчику использовать не точное значение битовой скорости, а приближённое, пока ошибка накопленная за время передачи всех битов одного байта не превышает ~20% одного битового интервала.

[SunTechnik]

Посылка всегда идёт пачкой битов.
Обычно: 1 стартовый бит, 8 бит данных, 1 стоптовый бит.

Поэтому есть некая автосинхронизация и небольшой уход частоты может быть компенсирован..

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

[jcmvbkbc]

Получится сделать задержку каждых 104 микросекунды с тактовой частотой чипа 2мгц,

Не вижу с этим проблемы.

И еще, если все вже использовать задержку длино 1мс, то это не будет работать на меьшей скорости?

Никакой стандартной скорости это не соответствует. 1200 немного быстрее, 300 существенно медленнее.

[Sneiksus]

jcmvbkbc, хорошо ну а когда допустим, передатчик выключен а приемник вклюен, и на rx пине у него лог. 0 а когда включается передатчик в режиме ожидания и у него сразу появляется лог. 1 Такую ситуацию он как интерпретирует?

[jcmvbkbc]

передатчик выключен а приемник вклюен, и на rx пине у него лог. 0 а когда включается передатчик в режиме ожидания и у него сразу появляется лог. 1 Такую ситуацию он как интерпретирует?

Никак не интерпретирует, это нарастающий фронт.

[Sneiksus]

jcmvbkbc, а почему тогда переход от стоп бита на лог. 1 интерпретируется? Потому что перед этим он получил стартовый бит? То есть до получения стартового бита( перехода с 1 на 0) он не начинает работу?

[jcmvbkbc]

почему тогда переход от стоп бита на лог. 1 интерпретируется?

Sneiksus, как интерпретируется? Стоп-бит это тоже 1.

То есть до получения стартового бита( перехода с 1 на 0) он не начинает работу?

В первом приближении -- да.
Есть ещё BREAK, когда в линию выдаются непрерывно нули, но это детали фрейминга более высокого уровня.

[Sneiksus]

jcmvbkbc, тут имел ввиду почему переход от 0 на 1 при ввключении устройства не интерпретируется, а при переходе с 0 на 1 в конце передачи интерпретируется именно как стоп-бит

[pfg21]

jcmvbkbc, х16 херасе бе однобитный ацп:) Я б просто ловил переход 0-1 и 1-0, а потом алгоритмом определял "средний" уровень.

[jcmvbkbc]

почему переход от 0 на 1 при ввключении устройства не интерпретируется, а при переходе с 0 на 1 в конце передачи интерпретируется именно как стоп-бит

Sneiksus, интерпретация состоит в том, что бит принимается и проверяется, что он -- "1", иначе -- ошибка фрейминга при приёме байта. То что в этом месте ожидался стоп-бит приёмник понимает просто считая принятые биты после старта.

[Sneiksus]

jcmvbkbc, теперь более-менее понимаю, спасибо

Answer 2

[pfg21]

Это называется программный uart.
Реализаций - мильён и маленькая тележка, разного уровня качества и проработанности. Погуглить реализации под стм32 и подобрать нужное.