-
- Ну я имел в виду, что если на передачу делать буференный вывод
через очередь freertos или кольцевой буфер, то надо сначала из
printf передавать в переписанный fputc(), а потом по 1 байту
вынимать из очереди и передавать в HAL_UART_Transmit_IT(). Или по
другому можно -- в отдельной задаче из очереди класть в буфер
передачи, а потом разом передавать в HAL_UART_Transmit_IT или в DMA
transmit - Mty1(28.04.2024 18:32)
- ужас какой. Хорошо, что я всего этого не знаю. :-) - Лaгyнoв(28.04.2024 19:35)
- Ну в принципе так, только можно оптимизировать уже внутри самой инфраструктуры printf. Для GCC инфраструктуры это перекрыв _write() , по умолчанию объявленную в syscalls.c. Юзать вместо _IT функции _DMA ничто не мешает. Равно как и писать напрямую в регистры DMA... - RxTx(28.04.2024 18:37)
- пока искал, что это за функция, нашел примеры, где её насилуют
постоянными вызовами. наверно оттуда и ноги растут - Vit(28.04.2024 18:26)
- У ST правило именования всех функций (DMA, SPI, I2C, Timers и так
далее) : 1. Софтварный поллинг (функция не выйдет, пока не
отработает): Просто название функции. 2. Через прерывание: дописано
_IT. 3. Через DMA: дописано _DMA. - RxTx(28.04.2024 18:33)
- Ну дык у ТС об _IT. Лагунов вот и удивляется, нахрена по байту пихать. - Vit(28.04.2024 18:46)
- Я понимаю о чем ты и сам так не пишу. Но. HAL_UART_Transmit_IT()
работает совершенно спокойно для передачи по 1 байту и будет так
работать без всяких сбоев. Конечно перегружая проц лишним
оверхедом. Я наталкивался где-то на подобное извращение. - RxTx(28.04.2024 19:02)
- то понятно. ТС когда сдался насчет printf и попыток навернуть непонятный буфер из очередей для fputc, стало грустно, потому как даже DMA не сильно в таком помогает, ибо опять нужен линейный вход (буфер) и/или ожидание. там скорее вопрос нужно задавать о возможности выделить буфер достаточного размера - Vit(28.04.2024 19:41)
- Коллега еще увлекается таким: он вызывает исходные функции
HAL_UART_Transmit_IT() / HAL_UART_Receive_IT() и проч. Но прям
внутри HAL функций прерываний (файлик stm32??xx_it.c) он всегда пишет свой примитивный код:
читает или пишет прямиком из UART регистра. Это работает. Но я
крайне советую обязательно обслуживать ошибки UART, потому что
ошибка UART будучи необработанной так и остается висеть и причиняет
прерывание снова и снова. - RxTx(28.04.2024 19:13)
- А вот тут вы, батенька, неправы... Прерывание общее для TDBE/RDBF
(и ошибок, если включено). Соответственно, чтение регистра
состояния в прерывании обязательно, для правильной обработки. А при
чтении данных после чтения регистра состояния, все ошибки
сбрасываются аппаратно... Idler(171 знак., 28.04.2024 20:19)
- Скажите, а причем TDBE и RDBF? Причем тут внезапно Artery? ТС использует STM32 RxTx(216 знак., 28.04.2024 20:57)
- А вот тут вы, батенька, неправы... Прерывание общее для TDBE/RDBF
(и ошибок, если включено). Соответственно, чтение регистра
состояния в прерывании обязательно, для правильной обработки. А при
чтении данных после чтения регистра состояния, все ошибки
сбрасываются аппаратно... Idler(171 знак., 28.04.2024 20:19)
- Я понимаю о чем ты и сам так не пишу. Но. HAL_UART_Transmit_IT()
работает совершенно спокойно для передачи по 1 байту и будет так
работать без всяких сбоев. Конечно перегружая проц лишним
оверхедом. Я наталкивался где-то на подобное извращение. - RxTx(28.04.2024 19:02)
- Ну дык у ТС об _IT. Лагунов вот и удивляется, нахрена по байту пихать. - Vit(28.04.2024 18:46)
- У ST правило именования всех функций (DMA, SPI, I2C, Timers и так
далее) : 1. Софтварный поллинг (функция не выйдет, пока не
отработает): Просто название функции. 2. Через прерывание: дописано
_IT. 3. Через DMA: дописано _DMA. - RxTx(28.04.2024 18:33)
- Ну я имел в виду, что если на передачу делать буференный вывод
через очередь freertos или кольцевой буфер, то надо сначала из
printf передавать в переписанный fputc(), а потом по 1 байту
вынимать из очереди и передавать в HAL_UART_Transmit_IT(). Или по
другому можно -- в отдельной задаче из очереди класть в буфер
передачи, а потом разом передавать в HAL_UART_Transmit_IT или в DMA
transmit - Mty1(28.04.2024 18:32)