Сериальное

[ex0_planet]

Нужен отдельный котёл для эмбеддеров, делающих фрейминг в serial link (будь то uart или еще что-то) тупо на счётчике байтов, без какого либо стаффинга. Зато там црц есть. Если удастся его найти в потоке-то.

This entry was originally posted at https://ex0-planet.dreamwidth.org/102228.html. Please comment there using OpenID.

Comments

[bigmaxx]

Я бы сказал, там проблема только в синхронизации начала кадра (и то лишь при бинарной передаче). Конец, на крайняк, можно и на счётчике, если есть грамотно реализованный тайм-аут и обработка прочих ошибок физического уровня. Но вообще-то, всё это должно быть описано в спецификации протокола, самодеятельностью в таких вопросах лучше не заниматься.
ЗЫ: вообще упустил, что сейчас в большинстве случаев Serial не физический, а эмулированный. Сам я, когда что-то делаю, всегда по старинке подразумеваю, что он физический.

[ex0_planet]

Это именно что самодеятельный бинарный протокол. Без оглядки на всё что делалось в индустрии предыдущие N лет.

Таймауты... ну, я бы сказал что грамотный фрейминг не сложнее плясок с таймаутами. Можно и на таймаутах, конечно, и в большинстве случаев всё будет работать потому что пакет скорее всего пролезет в буфер целиком и прочее в таком духе, но вообще это наслоения текущих абстракций. И когда это сломается, никто не будет разбираться - "просто передёрните питание".

[bigmaxx]

Я имел в виду, тайм-аут не для определения окончания пакета, а для выявления нештатной ситуации, когда надо прервать его прием.

[ex0_planet]

А какой здесь должен быть таймаут?
Ну вот послали мы заголовок "щас пришлю картинку", потом полезли за картинкой в память, а она возьми да и засвопься. Вот и таймаут. А потом утилита наваливает в ничего не подозревающую стейт машину какие-то байты.

Сам дурак и надо было ставить ssd?

[bigmaxx]

Ну и передаст её в повторе кадра, когда будет готов. А текущий прервётся по тайм-ауту.
А вообще, такого заголовка на уровне канального протокола быть не должно. На его выходе должно быть N байтов, свободных от ошибок, и точка. С тем, картинка это или её фрагмент, должен разбираться протокол более высокого уровня.

[ex0_planet]

А как _передающая_ сторона узнает о том, что приёмник считает что наступил таймаут?

Это по большому счёту та же проблема что и в TCP, когда молодые программисты считают что сколько write() вернул, столько и передано. Не-а. Эти байты могли вообще потеряться в эфире; приёмник должен сам сказать сколько он услышал.

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

[bigmaxx]

По отсутствию квитирования приема, видимо. Или по переспросу пакета в квитировании. Это всё должно содержаться в спецификации протокола канального уровня. Здесь лучше ничего не выдумывать, и реализовывать готовый. Таких бинарных открытых, которые были бы ещё и корректными, я навскидку, кроме соотв. разновидности Modbus, и не назову. Сам я некогда сделал реверс-инжиниринг одного весьма серьёзного проприетарного многоточечного протокола с физическим каналом RS-485. Там всё было сделано по уму, но для маркировки особых байтов, которые требовалось выделять из потока бинарных данных, использовался дополнительный бит. Писюк с таким работать не умеет, только микроконтроллеры. К тому же скорость они выбрали нестандартную, и по всему по этому на писюк ставили заказной контроллер.

[ex0_planet]

HDLC и основанный на нём PPP хотя бы. Все это уже триста лет есть и используется, но эмбеддерам ж никто не указ.

Девятый бит вкупе с нестандартной скоростью это редкая пидерсия, я б за такое выступающие части отрывал.

[bigmaxx]

Там одной из основных задач была секьюрность, в понимании 80-х годов, когда всё это разрабатывалось (под 8032). Там ещё и шифрование данных на канальном уровне есть, правда, очень примитивное. Потом, когда канальный протокол вскрыли, они на более высоком, логическом, уровне протокола добавили настоящее шифрование. Но эта линейка оборудования уже лет 15 как снята с производства, протокол сдох, и сейчас там звездообразная конфигурация на USB. Впрочем, этот протокол по своей организации уже заметно напоминал USB.