Подскажите пожалуйста как сделать такую схемку:

По ком-порту приходят пакеты размером 10-20 байт, такого вида <02><n><data_byte_0><...><data_byte_n><crc><03>. Мне надо их как-то выдергивать из буфера и переводить каждый пакет в отдельную строку, чтобы легче было потом обрабатывать. Я так понимаю, надо взять массив, тип элементов которого беззнаковый int8 (0-255), скидывать туда все, потом перебирать и ловить начало пакета (02), потом отсчитывать n байт и ловить конец пакета (03). После этого перевести его в строку и удалить из массива. На си это выглядело бы примерно так:

code_25627.txt
а как сделать это на элементах в хай-асме пока не могу понять. Киньте плиз пару идеек.

wasp, пакеты идут хаотично-резанно или: <02><n><data_byte_0><...><data_byte_n><crc>, <03><n><data_byte_0><...><data_byte_n><crc>...?
------------ Дoбавленo в 19.06:
В примере не понятно идут ли они строками по 10-20 байт, или строго отдельными пакетами?
------------ Дoбавленo в 19.14:
Каждый пакет начинается с <0#* и заканчивается <crc>?

wasp, СОМ порт уже выдаёт строку, нет необходимости переводить её в байты, а потом в строку начало и окончание блока <02> и <03> -- это символы или два байта цифр? Есть компонент в Строках BlockFind

Если все так - на выходе из порта ставите эдакую заморочку:
code_25628.txt

Загонять полученные результаты можно в обычный список строк StrList и сохранять в файл (если нужно).
В примере первая кнопка - начало передачи пакетов, а вторая - продолжение передачи (если пакеты рваные).

Neo, пакеты могут идти как угодно, с большими или маленькими паузами, или вообще без пауз - сразу друг за другом. Но каждый пакет всегда начинается байтом 02 и заканчивается 03 (Т.е. это не аски, а хекс). Эти 02 и 03 могут также встретиться и внутри пакета.



Не, не строками, а просто набором байт и длина может варьироваться от 10 скажем до 20 байт, не суть важно.

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


два байта цифр, все что в скобках <...> - по одному байту

[offtop]Леонид, а как этим BlockFind тут развернуться? Эти же <02> и <03> будут меняться. [/offtop] Подумал, что 02-03-04-05 считает счетчик. Если бы BlockFind поддерживал маску...
------------ Дoбавленo в 19.34:
Так ловите сразу <crc><03> как конец пакета. Считать байты - как-то муторно.
------------ Дoбавленo в 19.36:
Хотя, возможно, считать здесь надежнее всего, но и затратнее всего.

Neo, crc - это проверочная сумма, как ее поймаешь, ее считать надо. Надо по-любому ловить 02, потом отсчитывать н байт, и тогда уже ясно где конец пакета.

wasp, если и внутри пакета есть <0><2> и <0><3>, то как ловить начало/окончание , а n уж не количество-ли байт данных (неужели так трудно представить незнающего Ваших проблем и обрисовать задачу для него, чтобы было "необходимо и достаточно" )

Снимать целый дамп в поток, преобразовывать в HEX. Начиная со второго пакета можно "ловить" 03,02,n , отсчитав n убедиться, что дальше, (отступая на размер суммы), идёт 03 (а если за ним идёт ещё и 02...) , делать вывод о нахождении пакета и т.д. по циклу. Затратно, но можно считать и сумму для (n) байт сразу после 02,n и сравнивать с тем, что нашли перед 03. В общем, из-за слабой ориентированности базовых компонентов на бинарные данные, работать, видимо, придётся с дампом.

попробую еще раз.
В угловых скобках стоит один байт информации. Первым байтом в пакете всегда идет STX (Start of Text). Последним - ETX (End of Text):

Dec Oct Hex Binary Value
--- --- --- -------- --------------------------
002 002 002 00000010 STX (Start of Text)
003 003 003 00000011 ETX (End of Text)

Вторым байтом всегда идет позиция, где стоит чексумма, но она всегда на предпоследнем месте (перед ETX), поэтому из нее легко узнается длина пакета, или количество полезных байт. Все что между вторым и предпоследним байтом - полезная информация. Ее длина может варьироваться. Никаких строк, ASCII, все в цифре.

Короче все вышесказанное выглядит так:
<02><n><data_byte_0><...><data_byte_n><crc><03>

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

Надеюсь щас стало немного понятней
------------ Дoбавленo в 20.13:
1nd1g0, все правильно, так я себе в уме и представляю, но в дескретных элементах - напряг. В сях бы без проблем...

Я же сказал, у нас есть один из самых удобных способов работы с бинарными данными тут - работать с полученной после конвертирования строкой. Бинарные данные обрабатывать не так удобно, к сожалению.
------------ Дoбавленo в 20.24:
Если ну очень хочется именно с бинарными работать (и героически изображать на дискретных элементах с циклами простейшие операции вроде поиска сигнатуры), то, вероятно,

я тоже сначала переводил в HEX, но остановился на поиске символов "02" и "03", правда в моей задаче это были единственные символы в блоке - содержимое содержало только текст, никаких нелитерных символов. простой blockfind справился..

Andrey, а как вы боролись с разрывами пакетов при приеме?
или у вас их не было?

Кстати, была у меня подобная идея, но в другом направлении. Нужно было перебирать массив данных и находить логические цепочки по маскам, но с допусками по времени записи данных. Эдакий примитивный мозг. Но пока решил окольными путями и всячески пытаюсь уйти от проблемы - чувствую тщетно, она когда-то меня настигнет и придется мне пройти Ваш,wasp, путь
------------ Дoбавленo в 00.17:
wasp, ну так оставшиеся после обработки (рваные окончания данных) склеивайте через это, после конвертации в строку
------------ Дoбавленo в 00.18:
И, опять же, если я понял проблему склейки верно, то в первом моем сообщении пример именно со склейкой оставшейся после разделения строки.
------------ Дoбавленo в 00.19:
Вместо остатка разделения вставляйте свой остаток и получите склейку при поступлении новых данных.
------------ Дoбавленo в 00.21:
Или и вовсе склеивайте пока строка не примет целый вид (закончится байтами окончания передачи) - тогда отправляйте на обработку заведомо правильную строку целых пакетов.
------------ Дoбавленo в 00.22:
Хотя с байтами сильно не дружу и советы даю в силу моего понимания проблемы.

wasp,
СОМ порт выдаёт СТРОКУ и незачем переводить её в другой формат.
Вот как я понял условия задачи (и как изложил бы): "На СОМ порт поступают данные в формате -- первые два байта символы "0" и "2" начало блока, третий байт содержит количество байт данных от 1 до 255, далее обозначенное количество байт данных, далее ещё один байт с контрольной суммой, и последние два байта символы "0" и "3" окончание блока".
Под это понимание схемка: com_data.rar
1. Данные с СОМ склеиваются в строку (пустую строку из СОМ блокируем) и дважды запоминаются
2. Перебираем в цикле запомненную в первой ячейке строку в поиске "02"
3. Есть "02" -- читаем следующий байт и превращаем его в число n (1--255) и сохраняем
4. Читаем n следующих байт и сохраняем в памяти
5. Читаем следующий байт и превращаем его в число -- контрольную сумму, сохраняем
6. Читаем следующие два байта
7. Если это "03"
7.1 Запомненные данные склеиваем как хочется и выдаём куда нужно
7.2 Копируем часть строки после найденых "03" во вторую ячейку памяти
8. По окончании перебора строки копируем вторую ячейку памяти в первую.