В общем, есть устройство, и есть протокол к нему. И нужно его реализовать.
Устройство работает по принципу: 

«Устройство запрашивает у меня данные, я ему отвечаю «Получил твой пакет, сейчас отправлю данные», потом «Отправляю данные».
И наоборот.

Соединяюсь с устройством по COM порту.

В общем, какие будут советы? Кто сталкивался с реализацией протоколов? 
Как это лучше сделать? Может, какая литература есть?
Т.к. мой вопрос не конкретный, а абстрактный, поэтому и жду таких же ответов!

Док + исходники 

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

Желательно на русском языке...

Вот на русском, ток код на С++

Alkash не то.

Ладно слегка конкретизирую...

С COM порта читаю данные. Кадр начитаются и заканчивается определенным байтом.

В пакетах содержаться какие то команды, размер пакета заранее тоже не известен.
И не известно что придет в этом пакете... Толи это будет опрашивающий пакет, толи пакет с командой.
Если с командой то нужно ответить что я ее получил. потом обработать и отправить ответ.

А в чём затруднения?



Это сообщение отредактировал(а) Alkash - 25.7.2008, 11:43

Alkash - ну раз тебе кажется все просто дай хотя бы пару советов!

В какой области тебе нужны советы?  Как данные обработать?

Угу. 

По спецификации и смотри, как разобрать то, что пришло на порт. А как инфу с порта получить\отправить - глянь в ДКРБ

Если применительно к существующим системам, то подобные протоколы применяются для передачи телеметрии. До конца прошлого века каждый производитель писал свой протокол. Где то с 1996 года и далее стали приходить к международным стандартам. Поэтому сейчас для передачи данных используют, наиболее часто, протоколы IEC 60870-5-101/104 (в обиходе МЕС101/104). Про них можешь читать из поисковиков. В общем, структура довольно сложная. Для передачи данных используется ЕХЕ-шник, который по запросу к базе данных формирует пакеты согласно протокола. Передача их в порты вывода зависит от назначения. МЕС101 - для RS232. МEC104 - для ETHERNET.
Думаю, конкретный код навряд ли здесь тебе сообщат. 

Magik ссылку не подкинешь, а то искал но про описание протокола, нашел только в википедии на англиском языке ((

Вот можно почитать здесь: http://telemex.nm.ru/library_05.htm
Обобщённый стандарт на русском языке - ГОСТ Р МЭК 870-5-101 ,  ГОСТ Р МЭК 870-5-104. Они опираются на ранее принятые   ГОСТ Р МЭК 870-5-1(2,3,4,5)-95(96). 
У  программистов , владеющих технологией применения МЕС , это считается "высшим пилотажем".

Magik а средним пилотажем что считается?

Думаю, что, если знать - что и почему в этих цифрах, за средний - с лихвой!
А в общем , это обмен (трасировка) по 101 протоколу, асинхронная, небалансная передача.
Пакеты постоянной (10), и переменной длины (68). Да это всё описано в ссылке, что я давал. Ну, а что внутри, тоже можно там же прочитать. Но эти вопросы для обсуждения не на этом форуме. Да и , думаю за эти посты модератор может дать по кумполу.
28-07 19:01:20.928 <10 5B 7E D9 16
28-07 19:01:21.021 >10 09 7E 87 16
28-07 19:01:41.178 <10 7B 7E F9 16
28-07 19:01:41.225 >68 26 26 68 08 7e  0d 86 01 7e e9 03 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 48 42 00  8e 16 
28-07 19:03:21.225 <10 09 7E 87 16 

RinOSpro, 
отвечай на вопросы по пунктам;
.1.есть ли описание протокола?
.2.допускает ли канал связи потерю/искажение данных
.3. есть ли девайс работающий по данному протоколу?
.4.есть ли лог обмена девайса с чем либо по данному протоколу?

и подумаем как ковырять данное

Очень ценная статья есть здесь http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1126 с приложенным файлом. Лично мне очень нравится, и можно применять на прктике для тестирования каналов передачи данных с разными скоростями и паритетами. Протокол простой, но работает чётко. 

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

Кстати Magik тот лог что ты мне показываешь


Я уже такой реализовывал... это было довольно просто нежели сейчас... У предыдущего устройства протокол был 2 A4 )) и все нормально реализовал работает. а у нового протокол 150 A4 ((( и продвигаюсь как черепаха...


Virtuals 
1. Да 150 стр. англ. текста.
2. Да есть контроль правbльности пакетов достигается через CRC16
3. Да девайс есть и есть уже небольшие продвижения )
4. Лог обмена есть причем от родной программы этого девайа.

Вот не понимаю как в родной программе так все красиво и без глюков работает ) а у меня не получается ((

RinOSpro, 
ну так как мне нереально читать доки ваши то могу дать несколько советов, по крайне мере как я поступаю!

итак:
1. забудте что данные приходят пакетами кусками и т.д. представте что это непрерывный поток
2. нам нужно гдет хранить данные пока мы их полностью непримем, и не обработаем
3. для начала определимся что есть начало БЛОКА а что конец (именно набор условий)
(сдесь и далее буду приводить свой пример)
//набор спецификаций: 
блок начинается на 10 01 
кончается на 10 02
если в блоке встречается 10 то она меняется на 10 10
--
отсюда выводим правила
начало: 10 01 если перед ними нет нечетного количества десяток
конец: если было начало и если есть 10 02 и перед ними нет нечетного количества десяток

4 так научились выделять из потока нужные нам блоки, тепер структура обработки

процедура приема данных:
принимаем байты неважно как, и побайтово выкидываем в процедуру буфера
конец

процедура буфера:
принимаем по одному байту в раз
проверяем размер буфера на предмет возможного переполнения (если переполнение то сбросить флаги начала блока...)
пихаем байт в хвост буфера
отдаем буфер на дешифровку
конец

процедура дешифровки:
анализируем буфер сначала и ищем начало блока (условия известны) если нашли то сдвигаем буферт так чтобы первым было начало буфера /10 01/ дыбы выкинуть мусор и взводим флак начала
если флаг начала анализируем буфер на предмет конца блока если ненашли то свалить
иначе из буфера выдераем весь БЛОК, что осталось смещаем на первую поз, сбрасываем флаги
а блок передаем в процедуру анализа
конец

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

  
ЗЫ удачи в этом нелегком деле

Это сообщение отредактировал(а) Virtuals - 29.7.2008, 12:22

Virtuals помоему это нереально сложно... 

Я так подумал, почитал и наверно буду делать в потоке через статусы... 

К примеру когда я отправил пакет ставлю статус скажем st_read_response, и в потоке смотрю если этот статус, то ждать ответа получил ли девайс мой пакет, устройство мне может вернуть или ошибку или данные, к примеру если ошибка, то заного ставлю статус который выполнит повторно эту команду, а если получил данные и CRC верно тогда ставлю статус st_write_response.

Примерно так... Как вам такая схема?

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

Это сообщение отредактировал(а) Virtuals - 31.7.2008, 21:07