Реальное тестирование последовательного порта, чтобы определить, жив ли он
Я пишу консольное приложение реального уровня, которое опрашивает несколько последовательных портов для данных и сохраняет результаты в базе данных.
Моя первоначальная идея состояла в том, чтобы открыть порт, прочитать данные, а затем снова закрыть его. Проблема в том, что открытие последовательного порта может занять до 4 секунд, и мне может потребоваться считывание до 8 портов, поэтому открытие и закрытие порт не практичен для каждого цикла.
Вполне возможно, что последовательное устройство отключено от открытого порта, и, конечно, это вызовет проблемы.
Таким образом, можно определить, открыт ли порт и работает ли он, чтобы я мог оставить порт открытым и закрыть и открыть его только тогда, когда обнаружу, что подключенное устройство исчезло.
редактировать
Последовательный порт представляет собой последовательный порт Bluetooth, он говорит с радио Bluetooth, которое, в свою очередь, говорит с микроконтроллером. У меня есть начальный и конечный символы, которые я слушаю, и все это прекрасно работает, пока устройство Bluetooth не выходит за пределы диапазона и эффективно отключается, оставляя последовательный порт все еще открытым.
Конечно, я могу закрыть порт и попробовать открыть его снова, но вместо этого я хотел бы определить, подключено ли устройство к последовательному порту Bluetooth.
Кроме того, вызов serial.close() для последовательного порта в OSX вызывает кратковременное зависание (зависание курсора рабочего стола), я подозреваю, что загрузка процессора составляет 100%, это не происходит в Windows, и поэтому я хочу минимизировать количество открываемых и закрывающихся портов что я должен делать, поскольку я опрашиваю данные приблизительно с 10 устройств Bluetooth один раз в минуту.
Поскольку для открытия последовательного порта требуется до 4 секунд, наилучшим решением будет использование прямого HID-соединения с Bluetooth-радио вместо последовательного SPP-соединения, однако, похоже, что до сих пор никто не подключал realbasic к Bluetooth-HID-устройству и поэтому нет никакой информации или помощи по этому поводу.
2 ответа
Прошло несколько лет с тех пор, как я занимался последовательным программированием в РБ, поэтому я не все вспоминаю.
Класс Serial имеет событие LineStateChanged. Вы проверяли, вызывается ли это после потери или повторного подключения BT-соединения?
Если это не сработает, вы можете попробовать использовать низкоуровневые функции BSD/POSIX, чтобы открыть порт, и использовать вызовы ioctl(), чтобы выяснить его состояние. У меня нет примеров для этого, хотя. И я даже не уверен, что это правильный способ сделать это. Вероятно, все сводится к изучению того, что будет делать программа на C, и переводу этого в RB.
О плохой производительности: обычно это связано с ограниченным контролем RB над управлением событиями: он не видит необходимости чаще опрашивать последовательный порт и, таким образом, проверяет его редко, если у него нет других причин спрашивать для большего простоя от ОС. Хитрость заключается в том, чтобы запустить таймер с высокой частотой (например, один раз каждые 10 мс), а затем вызвать функцию опроса последовательного порта из события действия таймера.
Ваш запрос довольно странный, потому что обычно вы подключаетесь к последовательному порту, а затем ждете, чтобы получить любые данные, отправленные на этот порт. Позвольте мне сказать это по-другому. Последовательный порт не хранит никаких данных, ожидающих вас, когда вы подключитесь. Вы либо слушаете, либо нет.
Вы должны подключиться к порту и прослушать данные. Получив события DataAvailable, вы можете начать обработку данных, но помните, что не все данные в потоке могли быть получены и обработаны до наступления события. Как правило, вам нужно определить, что такое конец сообщения. Иногда это Возвращение Каррейга, а иногда нет. Зависит от системы.
Более подробная информация о DataAvailable доступна по адресу http://docs.xojo.com/index.php/Serial.DataAvailable