Discussion:
для оживления uart/usb CDC/etc
(слишком старое сообщение для ответа)
Nickita A Startcev
2014-04-14 10:02:30 UTC
Permalink
Привет, All !


как-то тут тихо и пусто в последнее время. а давайте обсудим такую тему:

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

как именно принято писать программу для управления такого рода устройствами?

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

наверняка эта тема уже где-то разобрана и есть готовые удобные стратегии для.

. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Ка(ни)баллистические руны
Peter Irich
2014-04-14 18:14:06 UTC
Permalink
Post by Nickita A Startcev
Привет, All !
есть устройство на, например, компорту или аналогичном "символьном устройстве".
оно отображается на ФС как псевдофайл, в который пишем команды и читаем ответы.
устройство может случайно сдохнуть, устройство асинхронно, из устройства
приходят ответы на команды.
как именно принято писать программу для управления такого рода устройствами?
ждать до победного конца ровно ожидаемое число байтов из устройства - путь к
повисанию.
отключать блокировку при чтении - путь к расписыванию длинных развесистых
кривых и однообразных парсеров принятого из устройства.
наверняка эта тема уже где-то разобрана и есть готовые удобные стратегии для.
Запустить приём в отдельном потоке и пусть он ждёт последнего
байта, на работу системы это не повлияет. Также в нём можно ждать
следуюий байт не более какого-то времени и, если он не пришёл,
то выходить с сообщением. Hапример, для COM-порта это время
можно задать в termios.
И зачем разбирать ответ, если он не полный?

Пётр.
Nickita A Startcev
2014-04-21 22:18:04 UTC
Permalink
Привет, Peter !
Post by Nickita A Startcev
как-то тут тихо и пусто в последнее время. а давайте обсудим такую
есть устройство на, например, компорту или аналогичном "символьном
устройстве". оно отображается на ФС как псевдофайл, в который пишем
команды и читаем ответы. устройство может случайно сдохнуть,
устройство асинхронно, из устройства приходят ответы на команды.
как именно принято писать программу для управления такого рода
устройствами?
ждать до победного конца ровно ожидаемое число байтов из устройства
- путь к повисанию. отключать блокировку при чтении - путь к
расписыванию длинных развесистых кривых и однообразных парсеров
принятого из устройства.
наверняка эта тема уже где-то разобрана и есть готовые удобные
стратегии для.
PI> Запустить приём в отдельном потоке и

и трахаться с межпоточной синхрой, да. и при выходе из приЛАЖения висеть.

PI> пусть он ждёт последнего
PI> байта, на работу системы это не повлияет. Также в нём можно ждать
PI> следуюий байт не более какого-то времени и, если он не пришёл,
PI> то выходить с сообщением. Hапример, для COM-порта это время
PI> можно задать в termios.
PI> И зачем разбирать ответ, если он не полный?


. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... жили-были три брата: Лит, Цен и Драт.
Peter Irich
2014-04-22 11:12:14 UTC
Permalink
Post by Nickita A Startcev
Привет, Peter !
Post by Nickita A Startcev
как-то тут тихо и пусто в последнее время. а давайте обсудим такую
есть устройство на, например, компорту или аналогичном "символьном
устройстве". оно отображается на ФС как псевдофайл, в который пишем
команды и читаем ответы. устройство может случайно сдохнуть,
устройство асинхронно, из устройства приходят ответы на команды.
как именно принято писать программу для управления такого рода
устройствами?
ждать до победного конца ровно ожидаемое число байтов из устройства
- путь к повисанию. отключать блокировку при чтении - путь к
расписыванию длинных развесистых кривых и однообразных парсеров
принятого из устройства.
наверняка эта тема уже где-то разобрана и есть готовые удобные
стратегии для.
PI> Запустить приём в отдельном потоке и
и трахаться с межпоточной синхрой, да. и при выходе из приЛАЖения висеть.
При выходе надо просто ликвидировать созданные потоки,
это совершенно не трудно.
Синхронизацию, конечно, надо как-то организовать,
но ведь это разовая работа, а потом это можно будет
исползовать длаьше.

Пётр.

Loading...