Работа с UART в пакетном режиме и ОС Опции

[Pavel V.]

Как правильно организовать работу с пакетным протоколом (что-то наподобие WAKE в собственной реализации) в условиях использования операционки?

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

Ответный пакет формируется в функции обработки команды и запускается отправка по прерыванию.

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

В этом случае возникает необходимость использования чего-то вроде кольцевого буфера для предотвращения потери данных.

Как правильно реализовать такую схему при наличии операционки?

Пока видится только такая схема работы:
1. Процесс, который занимается отправкой данных в порт, занят только тем, что висит в вечном channel.pop() из кольцевого буфера и в случае появления данных выполняет отправку байта в порт.
2. Процесс, который обрабатывает асинхронные события. Например, нажали кнопку. Процесс в этом случае вызывает некую функцию SendInputAsync() в которой формируется пакет и делается необходимое количество channel.push(). Затем процесс уходит в Sleep() на заданное настройками время.

Возможно, необходимо сделать процесс на каждое асинхронное событие?

Смущает передача управления для отправки каждого байта. Можно, конечно, вызывать channel.pop() с таймаутом и воспользоваться дополнительным событием, которое будет устанавливаться только по добавлению в канал полного пакета. Но как-то громоздко получается.

Прошу помощи у более опытных товарищей

[Sirko]

Дабы не создавать похожий топик, спрошу здесь.
Возможно, топикстартеру это будет тоже на руку.

Суть в следующем.
Есть некое устройство, собрано на меге с двумя UARTами. Протокол ModBus. Сетевой адрес к примеру 10.
Первый UART - мастер, управляет другими устройствами с адресами 1 - 9.
Второй UART - слейв, соединен с персоналкой. Если запрос с ПК адресуется основному устройству, то выполняется необходимое действие и возвращается ответ. Когда пакет адресован не основному, то он просто транслируется на первый UART и, соответственно, с первого на второй транслируется ответ. Если адрес не соответствует ни одному устройству, то и ответ, соответственно, не возвращается.

В настоящее время это хозявство благополучно функционирует без операционки. Криво ли, прямо ли, но с задачей своей справляется. Но не так давно решил я постичь csmRTOS и перевести этот проект под ООП. Пока что четких мыслей по поводу реализации нет. Не хочется изначально стартовать в неверном направлении.

Отсюда просьба - поделитесь своими мыслями, кто и как реализовал бы подобную задачу. Я имею ввиду взаимосвязь процессов и объектов, чего, с чем и чем

[remote_job]

Отсюда просьба - поделитесь своими мыслями, кто и как реализовал бы подобную задачу. Я имею ввиду взаимосвязь процессов и объектов, чего, с чем и чем

Один процесс на работу с первым уартом, один процесс на работу со вторым. Ну и в зависимости от сложности формирования ответа, можно еще и третий, самый приоритетный, на управление всем этим делом и формирование команд/ответов. Как-то так.