-
- Нашёл таки! Спецификация протокола WAKE от ЛИ Dingo(1 знак., 08.12.2021 14:48, ссылка)
- Подумывал его использовать, но с изменениями - маркерный
байтоктэт добавить и в конец пакета. Но передумал, ибо на лету декодировать несколько сложнее (хотя проще кодировать на лету). Но особенно в свете того, что (слава гитхабу) нашел готовенькую реализацию COBS на на Java :) - Argon(08.12.2021 15:09)
- Подумывал его использовать, но с изменениями - маркерный
- Счас имею схожую задачу, изобретаю свой велосипед. Девайсы висят на
общей шине, мастер один, скорость 250кбит (и есть желание сделать
500кбит). Разделитель пакетов - сигнал BREAK. Дальше заголовок
фиксированного размера и данные. В конце - CRC. - LightElf(08.12.2021 13:58)
- Linux терпеть ненавидит break'и гонять по линии. Использование CPU
взлетает в небеса. - lloyd(08.12.2021 14:26)
- Кстати, ЕМНИП в Windows XP при наличии break на линии RS232 во время открытия COM-порта выдавалась ошибка типа "порт занят". - rezident(08.12.2021 15:08)
- В DMX для этого я просто переключаю на 9600, передаю 0 и обратно
переключаю. Что мешает так же сделать? - Andreas(08.12.2021 14:51)
- Эта надо в драйвере делать. А ковырять драйвера никто не любит. - LightElf(08.12.2021 15:03)
- Не понял? Скорость UART в драйвере переключать? Наоборот, в
приложении на винде(хз как на линухе) не всегда выходит BREAK
выставлять, а уж скорость переключить всегда можно. Но времени
занимает немало, поэтому это только для передачи маркера:
переключил, выкинул ноль, переключил, передаешь пакет. - Andreas(08.12.2021 15:10)
- вот именно потому, что времени занимает немало. - LightElf(08.12.2021 15:18)
- SetCommBreak - delay - ClearCommBreak времени занимает чууууть меньше, но реальная задержка нестабильна. - Andreas(08.12.2021 15:43)
- А как в Винде принять BREAK? - rezident(08.12.2021 15:15)
- SetCommMask EV_BREAK, хотя не пробовал. - Andreas(08.12.2021 15:41)
- вот именно потому, что времени занимает немало. - LightElf(08.12.2021 15:18)
- Не понял? Скорость UART в драйвере переключать? Наоборот, в
приложении на винде(хз как на линухе) не всегда выходит BREAK
выставлять, а уж скорость переключить всегда можно. Но времени
занимает немало, поэтому это только для передачи маркера:
переключил, выкинул ноль, переключил, передаешь пакет. - Andreas(08.12.2021 15:10)
- Эта надо в драйвере делать. А ковырять драйвера никто не любит. - LightElf(08.12.2021 15:03)
- А, но у меня к счастью тут нет линуха. - LightElf(08.12.2021 14:42)
- Угу. Тут прямо сейчас наши погромисты решают одну проблему на платке с Линукс. Если устроить "горячую" перезагрузку платы, не закрыв открытый в программе порт переходника USB-RS232, то после перезагрузки Linux отказывается понимать наличие порта по причине того, что USB при инициализации рапортует о перегрузке порта по току. Хотя тока там со 100% вероятностью с гулькин %, но вполне возможен breake на линии RS232 в момент инициализации USB. При том холодный перезапуск системы rezident(19 знак., 08.12.2021 14:40)
- Linux терпеть ненавидит break'и гонять по линии. Использование CPU
взлетает в небеса. - lloyd(08.12.2021 14:26)
- Ну в общем, определился - буду применять COBS. Однако не знает ли
кто ресурса с нормальным объяснением по-русски? Ибо то, что в
русской статье на википедии - дурной автоматический перевод. Да и
английская статья через жопу написана. Argon(582 знак., 08.12.2021 10:42)
- Надеюсь CRC у вас будет наличествовать? При кодировании COBS при сбое даже в одном бите весь пакет фтопку нужно пускать. В отличие от какого-нибудь Modbus ASCII или RTU где, во-первых, изначально предусмотрена LRC/CRC и, во-вторых, даже необнаруженный единичный сбой в самом худшем случае значение лишь одного регистра/переменной испортит. - rezident(08.12.2021 12:36)
- COBS требует для формирования пакета знать наперёд его содержание
до 254 байт. Подход довольно простой: ищем сколько ненулевых
октетов следует в буффере (но не более 254), записываем N + 1,
записываем эти байты. Второй и последующие подряд идущие нули,
логично, кодируются как 0x1 (перед нами идёт 0 ненулевых октетов) - lloyd(08.12.2021 10:47)
- Октетом вы называете байт? Почему привычно не назвать байтом? Что
такое N? Куда записываем N + 1? Куда записываем "эти байты"? Почему
второй и последующие нули кодируются 0x1? Их не получится спутать с
настоящими 0x1? - Argon(08.12.2021 10:52)
- Байт - это минимально адресуемая ячейка памяти процессором. У
C2000, к примеру, байт 16-битный. А октет всегда 8-битный. lloyd(635 знак., 08.12.2021 11:28)
- "11 22 00 00 -> 03 11 22 01 00" А почему второй эээ... октет
00 не превратился в 01 ? - Argon(08.12.2021 11:54)
- а, понял - это не 00 данных, а разделитель пакетов, верно? - Argon(08.12.2021 12:05)
- Да, в COBS 00 - это признак окончания пакета, время, когда есть
смысл проверять содержимое на корректность. Технически, это можно и
на лету делать, но чуть замороченнее - lloyd(08.12.2021 12:51)
- ок, спасибо! - Argon(08.12.2021 12:52)
- Да, в COBS 00 - это признак окончания пакета, время, когда есть
смысл проверять содержимое на корректность. Технически, это можно и
на лету делать, но чуть замороченнее - lloyd(08.12.2021 12:51)
- а, понял - это не 00 данных, а разделитель пакетов, верно? - Argon(08.12.2021 12:05)
- "11 22 00 00 -> 03 11 22 01 00" А почему второй эээ... октет
00 не превратился в 01 ? - Argon(08.12.2021 11:54)
- Хех, во всех RFC, которые я читал, были октеты вместо байтов. Это у
них шиза какая-то. Якобы в старину бывали и не 8-разрядные байты. А
могли бы не выпендриваться и написать на первой странице своего
документа "у нас байт 8-разрядный". - SciFi(08.12.2021 11:19)
- В компилере для семейства C2000 размер байта 16 бит (да и память
там такая). И это не очень-то старина. - Vit(08.12.2021 11:44)
- Блин, эти "октеты" сбивают с толку. Даже в статейке про COBS на википедии говорится о байтах. Мы ведь обсуждаем байтовый протокол, где байт = 8 бит, зачем же усложнять объяснение? Иначе можно под каждым вторым сообщением на сахаре уточнять: "вы говорите о 8-битных байтах?" "Это не байт, а октет!" - Argon(08.12.2021 11:56)
- В компилере для семейства C2000 размер байта 16 бит (да и память
там такая). И это не очень-то старина. - Vit(08.12.2021 11:44)
- N - количество не нулевых байт подряд. N+1 передаем (записываем) перед этими не нулевыми байтами, сам нулевой байт не передаем (записываем). Если идет сразу ноль, тогда ненулевых байт ноль, передаем 0+1=1, сам ноль не передаем. Настоящий 0х01 не нулевой, он идет внутри ненулевых, сами ненулевые ни как не анализируются. - AlexBi(08.12.2021 11:08)
- Байт - это минимально адресуемая ячейка памяти процессором. У
C2000, к примеру, байт 16-битный. А октет всегда 8-битный. lloyd(635 знак., 08.12.2021 11:28)
- Октетом вы называете байт? Почему привычно не назвать байтом? Что
такое N? Куда записываем N + 1? Куда записываем "эти байты"? Почему
второй и последующие нули кодируются 0x1? Их не получится спутать с
настоящими 0x1? - Argon(08.12.2021 10:52)
- Стоит заменить UART на CAN, как все проблемы решаюся автоматически. - evgeniy1294(07.12.2021 20:15)
- угу, или на езернет - Argon(07.12.2021 20:25)
- Тоже вариант. UART прекрасен, но и другие интерфейсы не отстают. - evgeniy1294(07.12.2021 21:57)
- угу, или на езернет - Argon(07.12.2021 20:25)
- Мастер в бесконечном цикле по кругу перебирает всех слейвов при
этом передает информацию им если она есть. Когда слейв слышит свое
имя на шине - отвечает что жив и передает здесь же информацию на
мастер если есть. большие пакеты разбиваются на подпакеты с длиной
"окна" связи. детект обрыва связи если не отвечает слейв пару
циклов. Квитируется успех передачи. Если успеха нет то передача в
любом из направлений повторяется. - Tpoeшник(07.12.2021 18:23)
- При такой организации связи латентность трансляции события от слева
к мастеру может оказаться недопустимо высокой. При том, что
необходимость возможности экстренной передачи ТС сразу обозначил. "Но могут быть экстренные ситуации, когда второй без запроса
отправляет данные." - rezident(07.12.2021 19:08)
- Такой протокол хорошо работает когда реальные данные на передачу есть, условно, в одном из двадцати опросов. Тогда циклом проверки что новых данных нет нигде можно принебречь. Любые свежие данные отправляются условно сразу, нет необходимости в отдельном механизме приоритетной передачи. - Cкpипaч(07.12.2021 21:48)
- Это из реального небольшого проекта. Есть недостатки. Нравится то что "протокол" простой и устойчив по отношению к ошибкам. - Tpoeшник(07.12.2021 21:41)
- Ну тогда подчиненная шина уже плохой вариант! Упс. Два девайса и
дележка на мастер слейв это вообще извращение !!! - Aleksey_75(07.12.2021 19:28)
- Но дуплексная связь! - rezident(07.12.2021 19:36)
- Кто первый встал того и тапки! Уронил уровень на 11 тактов шины, я
здесь папа, слушаем меня !!! - Aleksey_75(07.12.2021 20:12)
- а уровень чего уронил при дуплексной связи? - Argon(07.12.2021 20:27)
- Алексей имеет в виду состояние BREAK на линии, как признак инициации начала обмена данных. rezident(279 знак., 07.12.2021 21:40)
- а уровень чего уронил при дуплексной связи? - Argon(07.12.2021 20:27)
- Кто первый встал того и тапки! Уронил уровень на 11 тактов шины, я
здесь папа, слушаем меня !!! - Aleksey_75(07.12.2021 20:12)
- Но дуплексная связь! - rezident(07.12.2021 19:36)
- именно так и работаем - Лaгyнoв(07.12.2021 18:31)
- При такой организации связи латентность трансляции события от слева
к мастеру может оказаться недопустимо высокой. При том, что
необходимость возможности экстренной передачи ТС сразу обозначил. "Но могут быть экстренные ситуации, когда второй без запроса
отправляет данные." - rezident(07.12.2021 19:08)
- Re: 1. Если связь по TTL уровням, то скорее всего легко добавить
еще один логический сигнал, означающий желание слейва отправить
данные. Это намного проще, чем решать проблему незапрошенных
посылок на протокольном уровне - VLLV(07.12.2021 09:49)
- Заново лин изобрести?? - Aleksey_75(07.12.2021 18:20)
- Да, по TTL, но это не навсегда. Будет вариант с коннектом через
USB-UART. Ну как бы то ни было, девайсы уже в железе имеются и
добавлять что-то не хотелось бы. Особенно учесть, что слейв - это
SBC, использование GPIO будет выглядеть совсем уж ардуинообразно :) - Argon(07.12.2021 10:01)
- Ну, можно тогда в ответе на проверку "heartbeat" отдавать запрос, просто скорость побольше и опрашивать почаще. - VLLV(07.12.2021 10:08)
- Не так уж и сложно сочинить свой протокол. Если некое знакомство с существующими в природе протоколами имеется (брать из них фичи там, где надо). Потому что готовый протокол для всего этого списка хотелок будет моструозным, КМК, ведь там будет много чего ещё ненужного. - SciFi(07.12.2021 07:52)
- HDLC и ее производные. Я вот сделал как-то реализацию стека IrDA, и
теперь пользуюсь им при случае для межпроцессорного взаимодействия.
Вполне годная вещь, позволяет реализовать все вышеперечисленное. - il-2(07.12.2021 06:16)
- спасибо, интересно! краем глаза пробежал по описанию, байтстаффинг
- прикольная штука ) Я как раз не мог сообразить как
синхронизировать кадры, если буду изобретать велосипед ) - Argon(07.12.2021 06:23)
- Есть похожий simple serial protocol (SSP) - misyachniy(07.12.2021 09:26 - 10:06)
- Спасибо, да, похоже на то что нужно. Многабукаф -> Argon(1 знак., 07.12.2021 09:52, ссылка)
- Какой-то лютый студенческий самопал. На первых же страницах: il-2(241 знак., 07.12.2021 12:35)
- И что смущает. Типичный прием. - RxTx(07.12.2021 16:24)
- Типичный - это когда делается подстановка, в результате которой управляющие коды встречаются только в тех местах, где должны. А тут - вместо одного кода поставили два, и там где его быть не должно. Вот пример правильной подстановки: il-2(998 знак., 08.12.2021 06:03)
- Смущает то, что вместо символа замещения escape-символа используется сам escape-символ. - Samx(08.12.2021 01:32)
- Кстати, этот документ скорее всего, не то, что было посоветовано выше. Вчитавшись можно обнаружить расшифровку: Smiley ® Secure Protocol (SSP). Тем не менее, что не устраивает в описании этого байт-стаффинга? В википедии описано аналогично. Argon(130 знак., 07.12.2021 12:44)
- И что смущает. Типичный прием. - RxTx(07.12.2021 16:24)
- Вариант от Максим. -> ir0407(1 знак., 07.12.2021 09:55, ссылка)
- Там про SSI, не SSP. Наверное что-то другое, и слова stuffing нет в
тексте. - Argon(07.12.2021 10:02)
- Зато простенько, со вкусом и с исходниками, которые под свои
хотелки завсегда
паламатьподправить можно.:) - ir0407(07.12.2021 10:35)- Да я уже на байт-стаффинг нацелился, уж очень не хочется учитывать
паузы при приеме. - Argon(07.12.2021 11:05)
- Паузы при приеме в протоколах типа "запрос-ответ" получаются
естественным путем, мастер вынужден ждать ответа, особенно в
каналах с общей средой, типа RS-485. Байт-стаффинг может быть
интересен, когда есть отдельные каналы для передачи и передаваемая
информация, в основном, формируется не в стиле запрос-ответ. - AlexBi(07.12.2021 12:12)
- Я, может, сгущаю краски, но один из моих девайсов теоретически
может взять паузу на середине своей передачи или приема. Так что
некоторые паузы не будут "естественными". - Argon(07.12.2021 12:21)
- Заложите эту паузу в свой протокол, т.е. пусть в протоколе будет
пауза больше чем может быть из-за особенностей девайса. А если
такие события редкие, то паузу можно не увеличивать, а такие
событие обрабатывать как дефекты связи. Все равно пауза при приеме
приведет к потере данных и это надо как-то обрабатывать. - AlexBi(07.12.2021 16:02)
- Предполагаю, что пауза не приведет к потере данных, а приведет к
лагу внутри пакета. Точные диапазоны этих пауз не знаю, допустим
порядка 300-500 мс, если в протокол закладывать такой порядок, то
это будет как-то совсем печально. Лучше уж я попытаюсь вот эти
относительно редкие события купировать "на лету" с помощью
паузоустойчивого протокола. Argon(95 знак., 07.12.2021 18:02)
- Пауза при передаче приведет к лагу, пауза при приеме приведет к
потере принятого у приемника. Или должен быть какой-то механизм,
останавливающий передатчик, пока приемник занят чем-то своим. Но
такого не планируется, как я понимаю, поэтому потери неизбежны и к
этому надо быть готовым. AlexBi(405 знак., 07.12.2021 19:29)
- Неа, пауза при приеме не должна привести к потере принятого у
приемника (одноплатник с ОС Android), ибо если я верно понимаю, то
данные таки примутся драйвером, который является частью ядра Linux.
В то время как сборщик мусора работает в среде dalvik (аналог Java
runtime) и тормозит мое приложение, которое и обрабатывает
прием-передачу. Argon(652 знак., 07.12.2021 20:38)
- А когда одноплатник будет передатчиком и будет сливать большой
объем данных (100К и более), то приемником можем наловить
нерегулярных пауз по той же самой причине с более чем нулевой
вероятностью. И лучше бы эти паузы победить логикой самого
протокола. Байт-стаффинг, по-моему то самое. - Argon(07.12.2021 20:54)
- Если там такой умный драйвер, то и при передаче пауз не будет, т.к. скорее всего передача делается так: в буфере готовится что надо передать, потом активируется драйвер, который передает весь буфер подряд, без пауз. AlexBi(386 знак., 07.12.2021 22:07)
- Я бы все же ввел какой-либо критерий по длительности паузы в передаче, как признак "битого" пакета данных. Для надежности. - rezident(07.12.2021 21:43)
- А когда одноплатник будет передатчиком и будет сливать большой
объем данных (100К и более), то приемником можем наловить
нерегулярных пауз по той же самой причине с более чем нулевой
вероятностью. И лучше бы эти паузы победить логикой самого
протокола. Байт-стаффинг, по-моему то самое. - Argon(07.12.2021 20:54)
- Неа, пауза при приеме не должна привести к потере принятого у
приемника (одноплатник с ОС Android), ибо если я верно понимаю, то
данные таки примутся драйвером, который является частью ядра Linux.
В то время как сборщик мусора работает в среде dalvik (аналог Java
runtime) и тормозит мое приложение, которое и обрабатывает
прием-передачу. Argon(652 знак., 07.12.2021 20:38)
- Пауза при передаче приведет к лагу, пауза при приеме приведет к
потере принятого у приемника. Или должен быть какой-то механизм,
останавливающий передатчик, пока приемник занят чем-то своим. Но
такого не планируется, как я понимаю, поэтому потери неизбежны и к
этому надо быть готовым. AlexBi(405 знак., 07.12.2021 19:29)
- Предполагаю, что пауза не приведет к потере данных, а приведет к
лагу внутри пакета. Точные диапазоны этих пауз не знаю, допустим
порядка 300-500 мс, если в протокол закладывать такой порядок, то
это будет как-то совсем печально. Лучше уж я попытаюсь вот эти
относительно редкие события купировать "на лету" с помощью
паузоустойчивого протокола. Argon(95 знак., 07.12.2021 18:02)
- Заложите эту паузу в свой протокол, т.е. пусть в протоколе будет
пауза больше чем может быть из-за особенностей девайса. А если
такие события редкие, то паузу можно не увеличивать, а такие
событие обрабатывать как дефекты связи. Все равно пауза при приеме
приведет к потере данных и это надо как-то обрабатывать. - AlexBi(07.12.2021 16:02)
- Я, может, сгущаю краски, но один из моих девайсов теоретически
может взять паузу на середине своей передачи или приема. Так что
некоторые паузы не будут "естественными". - Argon(07.12.2021 12:21)
- Паузы при приеме в протоколах типа "запрос-ответ" получаются
естественным путем, мастер вынужден ждать ответа, особенно в
каналах с общей средой, типа RS-485. Байт-стаффинг может быть
интересен, когда есть отдельные каналы для передачи и передаваемая
информация, в основном, формируется не в стиле запрос-ответ. - AlexBi(07.12.2021 12:12)
- Да я уже на байт-стаффинг нацелился, уж очень не хочется учитывать
паузы при приеме. - Argon(07.12.2021 11:05)
- Зато простенько, со вкусом и с исходниками, которые под свои
хотелки завсегда
- Там про SSI, не SSP. Наверное что-то другое, и слова stuffing нет в
тексте. - Argon(07.12.2021 10:02)
- Какой-то лютый студенческий самопал. На первых же страницах: il-2(241 знак., 07.12.2021 12:35)
- Где? - Kpoк(07.12.2021 09:30)
- Спасибо, да, похоже на то что нужно. Многабукаф -> Argon(1 знак., 07.12.2021 09:52, ссылка)
- COBS гляньте, пакеты до 255 байт - sav6622(07.12.2021 09:52)
- спасибо, тоже интересно - Argon(07.12.2021 12:32)
- Спасибо! - Dingo(07.12.2021 12:09)
- Есть похожий simple serial protocol (SSP) - misyachniy(07.12.2021 09:26 - 10:06)
- спасибо, интересно! краем глаза пробежал по описанию, байтстаффинг
- прикольная штука ) Я как раз не мог сообразить как
синхронизировать кадры, если буду изобретать велосипед ) - Argon(07.12.2021 06:23)
- чем модбас не нравится? - LordN(07.12.2021 05:47)
- Плохо определять конец пакета по паузе между байтами. Если запускать программу из под виртуальной системы, то там могут возникать задержки между байтами внутри пакета, что может быть ошибочно воспринято подчинённым устройством, как конец пакета. - Ale3000(07.12.2021 06:59)
- ничего о нем не знаю. посмотрю, спасибо - Argon(07.12.2021 05:58)
- См. протоколы X-/Y-/Z-modem. Только непонятно, почему от дуплекса
отказались? rezident(1 знак., 06.12.2021 21:40, ссылка)
- Спасибо! Не отказался, просто пока не сообразил как его применить в
системе запрос-ответ. - Argon(07.12.2021 04:48)
- Во взрослых протоколах запросы и ответы не обязательно синхронны:
мастер кидает запросы, слэйв отдает по мере готовности. - VLLV(07.12.2021 09:45)
- у нас на АЗС вроде ситуация вполне взрослая. Потому как вопрос
денег - отпуска топлива. И везде во всех протоколах никакого
дуплекса. Мастер ждет ответа слэйва всегда. По таймауту прекращает
ждать. Разница в протоколах только по уровню контроля посылок
(стартовые и стоповые байты, уровень CRC и проч.) - Лaгyнoв(07.12.2021 13:00)
- Да, из трех десятков протоколов оборудования на заправках, с
которыми мне пришлось работать, большинство такие. Но есть и
протоколы от IFSF или EPSI. - VLLV(07.12.2021 16:34)
- это где такое? - Лaгyнoв(07.12.2021 18:32)
- В Европе и Америке. Я занимался подключением ценовых табло от
немецкого производителя к контроллерам/кассам на заправках. - VLLV(08.12.2021 06:28)
- Ну в Россию не попадали значит. Я (по крайней мере) не натыкался.
:-) - Лaгyнoв(08.12.2021 08:53)
- IFSF LonWorks точно был, по крайней мере в Москве - VLLV(08.12.2021 11:17)
- я офонарел. Плата связи IFSF\LON - 42938.54 Р. Недавно колонку можно было купить за эти деньги. :-) Лaгyнoв(1 знак., 08.12.2021 14:25, ссылка)
- где Москва, а где я. :-) Между нами Урал - Лaгyнoв(08.12.2021 14:21)
- IFSF LonWorks точно был, по крайней мере в Москве - VLLV(08.12.2021 11:17)
- Ну в Россию не попадали значит. Я (по крайней мере) не натыкался.
:-) - Лaгyнoв(08.12.2021 08:53)
- В Европе и Америке. Я занимался подключением ценовых табло от
немецкого производителя к контроллерам/кассам на заправках. - VLLV(08.12.2021 06:28)
- это где такое? - Лaгyнoв(07.12.2021 18:32)
- Да, из трех десятков протоколов оборудования на заправках, с
которыми мне пришлось работать, большинство такие. Но есть и
протоколы от IFSF или EPSI. - VLLV(07.12.2021 16:34)
- Пока не соображу как это обеспечить асинхронность в моем случае.
Иногда мастер должен отправлять сообщение о некоем одноразовом
событии, например, нажатии кнопки. Что он должен делать, не получив
ответа или подтверждения? Повторы сообщения не катят, ибо слэйв
может несколько раз обработать это однократное событие. Argon(99 знак., 07.12.2021 09:57)
- Не надо зарываться в абстракции. Если мастер может проигнорировать отсутствие подтверждения без жутких последствий, так и надо делать. И вообще, если в вашем применении можно решить, что связь всегда надёжная, то подтверждения вообще не нужны. Предлагаю отталкиваться от реальных задач, потому что теоретических можно придумать оч. много и решать их всю оставшуюся жизнь. - SciFi(07.12.2021 10:06)
- В тело сообщения добавляется инкрементируемый идентификатор
(token). Слейв делает все с привязкой к этому токену. Сообщение о
новом нажатии придет с другим токеном. - VLLV(07.12.2021 10:01)
- спасибо, обмозгую - Argon(07.12.2021 10:05)
- Т.е. речь о том, что мастер и слейв шлют друг другу сообщения
асинхронно и полнодуплексно, не дожидаясь подтверждения? А если
какое-то сообщение не было получено? Ну там ошибка связи. Пока не
въеду, как работать без подтверждения. - Argon(07.12.2021 10:09)
- Несинхронность не означает отсутствие подтверждения, а означает всего лишь очередь (массив) сообщений и у мастера, и у слейва. Мастер послал сообщение №5, пометил, что оно ждет ответа, и послал еще десять сообщений. Пришел ответ на сообщение 5, вычеркнул из очереди и пилит дальше. Но наверно я увел в сторону, это было актуально для систем 20-30 давности, когда каналы были медленными. Теперь таких проблем нет. - VLLV(07.12.2021 10:17)
- Т.е. речь о том, что мастер и слейв шлют друг другу сообщения
асинхронно и полнодуплексно, не дожидаясь подтверждения? А если
какое-то сообщение не было получено? Ну там ошибка связи. Пока не
въеду, как работать без подтверждения. - Argon(07.12.2021 10:09)
- спасибо, обмозгую - Argon(07.12.2021 10:05)
- у нас на АЗС вроде ситуация вполне взрослая. Потому как вопрос
денег - отпуска топлива. И везде во всех протоколах никакого
дуплекса. Мастер ждет ответа слэйва всегда. По таймауту прекращает
ждать. Разница в протоколах только по уровню контроля посылок
(стартовые и стоповые байты, уровень CRC и проч.) - Лaгyнoв(07.12.2021 13:00)
- Во взрослых протоколах запросы и ответы не обязательно синхронны:
мастер кидает запросы, слэйв отдает по мере готовности. - VLLV(07.12.2021 09:45)
- Спасибо! Не отказался, просто пока не сообразил как его применить в
системе запрос-ответ. - Argon(07.12.2021 04:48)
- Нашёл таки! Спецификация протокола WAKE от ЛИ Dingo(1 знак., 08.12.2021 14:48, ссылка)