[uriy 4]

Имеется хост устройство стороннего производителя. И мой девайс.

Между собой они соединяются через UART.

Хост устройство имеет дисплей, клавиатуру, динамик, микрофон.

 

Через UART я принимаю сообщения о нажатии клавиш, в ответ могу вывести что-то на дисплей и выполнить другие действия с хостом.

Также через тот-же UART ходит звук по RTP.

Протокол на UART с установкой соединения. У каждого пакета порядковый номер.

На каждый пакет надо давать подтверждение с задержкой не более 300мс, иначе соединение будет разорвано.

Хост кроме подтверждения еще и дает пакет о статусе выполнения команды. Статус выполенния команды может быть выдан через несколько сотен миллисекунд.

 

Сейчас реализовано взаимодействие но без приема/передачи звука.

UART в моем девайса работает по DMA и на прием и на передачу.

Контроллер STM32 после обнаружения IDLE на UART Rx кидает сообщение в очередь в задачу обработчик.

 

Работа с хостом реализована в одной задаче.

Она кидает пакеты на хост, ждет ответ проверяет его и выдает подтверждение.

 

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

 

Может быть кто-то делал что-то подобное.

Как лучше сделать?

 

1. Оставить одну задачу для работы с хостом

2. Две задачи. Одна обрабатывает UART только на прием, вторая только на передачу.

Плюс тут в том что задача приема будет формировать подтверждения.

3. Сделать отдельную задачу для RTP и отдельную для работы с кнопками дисплеем.

[Lagman 1]

Сейчас реализовано взаимодействие но без приема/передачи звука.

UART в моем девайса работает по DMA и на прием и на передачу.

Контроллер STM32 после обнаружения IDLE на UART Rx кидает сообщение в очередь в задачу обработчик.

 

Работа с хостом реализована в одной задаче.

Она кидает пакеты на хост, ждет ответ проверяет его и выдает подтверждение.

 

.....

 

Как лучше сделать?

 

1. Оставить одну задачу для работы с хостом

2. Две задачи. Одна обрабатывает UART только на прием, вторая только на передачу.

Плюс тут в том что задача приема будет формировать подтверждения.

3. Сделать отдельную задачу для RTP и отдельную для работы с кнопками дисплеем.

 

Я бы сделал по второму варианту. Задача приема будет отправлять подтверждение через очередь в задачу передачи, и помещать его (подтверждение) в начало очереди.

[AlexandrY 2]

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

 

Неплохо было бы сначала расшифровать что такое у вас RTP.

Гугль знает только один RTP который поверх IP - UDP, содержит больше десятка кодеков и кучу вспомогательных протоколов.

Такому RTP и десяти задач мало будет.

[uriy 4]

RTP - Real-time Transport Protocol

Вы правильно нашли, но не вижу прчин использовать только в IP сетях.

Тут разработчики хост устройства решили его использовать на UART.

Хост устройство поддерживает только PCM, Alaw, ulaw.

Какие же еще вспомогательные протоколы вы нашли? Разве что может быть RTCP, но здесь он не исползуется.

Зачем ему десяток задач?