Это в принципе понятно, только он делав 256 байтный массив и дальше как вы пишите. Но для этого необходимо прокрутить три цикла, перевый для начального обнуления 256 байтного (битного) массива,
второй для обозначения присутствующий символов, третий для поиска первого нулевого.

Делать это в ПВЭМ и отправлять в МК можно, а вот крутить эти циклы в МК для обратной передачи пакетов может быть накладно.

А вот если-бы существовал не слишком сложный алгоритм: в начале сброс какого-то значения (байта/слова), а дальше добавляется очередной байт и тут-же получаем значение байта, которого еще небыло.

"Кривизна" протокола вносит ограничение на допустимые комбинации данных в пакете. То есть случайно попавшаяся 20-байтная (100-байтная) последовательность в пакете, совпадающая с синхронизацией введёт канал передачи в ступор.

2 sKWO
Измени структуру кадра передачи. Например, на такую
1. длина 2 байта
2. поле данных (0...65531 ) - присоединяемый твой пакет
3. CRC 2 байта

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

Конечно есть мнение что Чак Норрис достчитал до бесконечности дважды!

Но применительно к байтстаффинг протоколу - в худшем случае (если все байты данных в пакете будут равны управляющему символу, размер пакета увеличится всего лишь вдвое). Делать "strip" тобишь отцеплять лишние данные можно прямо в обработчике прерывания УАРТа нехитрой проверкой



добавлять избыточность, аналогично просто:

посмотрите в сторону битстаффинга. Пример - сигнализация MTP CCITT 7. Номер рекомендации не помню но можно и по поиску найти.

Не до бесконечности, а максимум в два раза. При всей на первый взгляд неприятности - используется массово.

Смотрите PPP http://www.faqs.org/rfcs/rfc1171.html - там этих подставновок вообще немеряно, не только ограничитель пакета подставляется, а ещё куча байтов. И ничего.


Я сам использую рамку SLIP http://www.faqs.org/rfcs/rfc1055.html - там подставляется два байта, ограничитель пакетов и тот, который используется как флаг подстановки. Работал лет 10 назад с каким-то радиомодемом, ему нужно было в этой рамке посылать пакеты, так и привык с тех пор :-)
Очень удобно в WIN32 байт-ограничитель пакета задать как EVENT CHARACTER и буфер запросить гарантированно больше максимального пакета - и не дёргаться по каждому байту, а ждать только этого события и выгребать потом весь пакет.


Кстати, вопрос к автору вопроса - а что будете делать, если вдруг все 256 байт будут разные, все байты есть во входном потоке? Возьмёте как флаговый произвольный? Ну так и делайте это сразу "без этих хлопот".


Всё хорошо, максимальная растяжка пакета в худшей ситуации на 12.5%, а не вдвое, как у байт-стаффинга, но бит-стаффинг настолько муторно делать ручками до/после аппаратного UART, ориентированного на передачу байтов...

ну пускай тогда символьно передает, или сделает фреймовую синхронизацию как в G703)

Полагаю, что для Вас в самый раз будет алгоритм byte stuffing'а Consistent Overhead Byte Stuffing. В этом алгоритме всегда добавляется только 1 байт при длине пакета не более 254 байт, еще плюс 1 байт - признак начала (или конца) пакета. Т.е. не нужно выделять память под буферы с большим запасом, расчитывая на наихудший случай. Реализация его тоже очень простая. Сам давно пользуюсь и доволен.
Ссылка на описание: http://www.stuartcheshire.org/papers/COBSforToN.pdf

Ценю чувство юмора!
А пока рассбираюсь с COBSforToN.pdf

Сообщение отредактировал sKWO - Jun 1 2007, 19:39

Если я верно Вас понял, то может быть поможет WAKE протокол? Он на основе SLIP'a, довольно прост в реализации... Ссылка на описание WAKE протокола

а про контрольную сумму забыли? чтоб еще и она совпала.:-) это уже слишком.:-)

Да не забыл я про кс. Просто пакет со случайно оказавшейся в нем синхронизацией (хоть 20, хоть 100 байт) не сможет быть передан через канал как ни извращайся. КС позволит обнаружить то, что что-то передано неправильно и потребует повторить передачу этого пакета. Но и во второй раз передача накроется, и в третий. Содержимое же пакета нельзя заменить на другое. Оно как совпадало, так и будет совпадать с синхронизацией.

Согласен, никто так не делает.

Можно предложить расширенную версию байтстаффинга, ниже краткое описание того что должно быть:
1 - упр символ.
2 - символ старта пакета (распознается как старт только если идет после упр. символа)
3 - символ завершения пакета (распознается как конец пакета, только если идет после упр символа)
4 - два упр. символа подряд трактуются как символ данных равный упр. символу.
5 - одиночный упр. символ - не сопровождаемый ни старотовым символом, ни символом завершения - трактовать как сбой передачи - и прием пакета прекращать.

6 - CRC пакета очень желательно.

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

Народ давно уже придумал способы передачи двоичных данных таким образом, чтобы оставалась возможность использовать управляющие символы для старт/стопа. Например BASE64. Среднее увеличение пакета в 1,4 раза максимум. Сам алгоритм прост и быстр (наверное не медленнее сканирования пакета в поисках чего-то).

Используйте пакетную передачу данных.
Например


1. Преамбула.
2. Преамбула2.
3. Код команды (или назначение пакета..., опционально).
4. Размер данных.
5. КС. (опция)
6. Данные.
7. CRC16
8. Признак конца пакета.


Это всего лишь пример. У меня в проектах используется чуть более сложная структура (зато более гибкая), но Вы можете выбрать поля как Вы считаете нужным. Размер каждого поля тоже.

Вот пример команды (вытянул из старого проекта) чтения системного времени устройства (МК шлет ответ ПК, в поле данных системное время, все hex):

55 AA 01 07 55 07 06 01 03 17 57 18 83 9A FE