Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.146.255.127] |
|
Сообщ.
#1
,
|
|
|
Необходимо передать довольно много данных через COM-порт. Решил использовать CPortLib, как отправлять строку я разобрался, а как отправить 1000?
Если делать так while not eof(txt) do begin Readln(txt,Str); Str := Str + #13#10; ComPort.WriteStr(Str); end; CloseFile(txt) и выводить в мемо procedure TForm1.ComPortRxChar(Sender: TObject; Count: Integer); var Str: AnsiString; begin ComPort.ReadStr(Str, Count); Memo.Text := Memo.Text + Str; end; то получается что вместо 56кб отправляется всего 7кб. Чую что порт не успевает передавать и надо где-то то ли задержку сделать, то ли еще что-то. Подскажите, как сделать, а еще лучше где прочитать как сделать. В хелпе CPortLib не нашел ничего... |
Сообщ.
#2
,
|
|
|
Цитата Malicious @ то ли еще что-то Общие соображенияю 1. Выходной буфер увеличить. 2. Отправлять следующую строку после передачи предыдущей. С данной библиотекой не работал, но у всех известных мне компонент по работе с СОМ-портом есть событие типа данные переданы, выходной буфер пуст и т.п. |
Сообщ.
#3
,
|
|
|
Извиняюсь за свою неразумность, но никак не могу найти, как отловить событие о том, что данные отправлены в этом компоненты :-( А есть другие бесплатные библиотеки, которые работают в Delphi 2010?
|
Сообщ.
#4
,
|
|
|
Цитата Malicious @ никак не могу найти, как отловить событие о том, что данные отправлены в этом компоненты Разве у него нет события OnTxEmpty? |
Сообщ.
#5
,
|
|
|
Спасибо northener, разобрался. Действительно, по событию OnTxEmpty передаю данные и все приходит.
|
Сообщ.
#6
,
|
|
|
Подниму старую тему. Читаю по событию ComPort1RxChar
unsigned char *buffer = new unsigned char[1024]; void __fastcall TForm1::ComPort1RxChar(TObject *Sender, int Count) { String message=""; ComPort1->Read(buffer, Count); for (int i = 0; i < Count; i++) message += ByteToHex(buffer[i]) + " "; Memo1->Lines->Add(Now().TimeString()+" <- " + message); } [CODE=pas] [/CODE] В Memo наблюдаю следующее: 17:20:02 -> 03 03 00 00 00 0A C4 2F 17:20:02 <- 03 03 14 00 17:20:02 <- 01 00 16 00 1E 00 02 00 07 00 00 17:20:02 <- 00 01 00 00 00 00 00 00 17:20:02 <- 7A 78 При запуске стороннего приложения. Когда спрашиваю такую команду, приходит так: Tx:03 03 00 00 00 0A C4 2F Rx:03 03 14 00 01 00 16 00 1E 00 02 00 07 00 00 00 01 00 00 00 00 00 00 7A 78 Т.е. вроде бы все нормально, и у меня. Все байты пришли. контрольные crc совпадают. Но почему кусками !!?. Мануалов толковых не нашел. Может где-то какие настройки. |
Сообщ.
#7
,
|
|
|
А в чем проблема-то? Это ж не датаграммный протокол, а поточный порт.
|
Сообщ.
#8
,
|
|
|
Не могу придумать, как ждать, стоп бит или конец посылки, по таймаутам.
|
Сообщ.
#9
,
|
|
|
А это уже зависит от содержания данных. В общем случае всегда предпочтительней сигнатура окончания либо префикс с длиной, но в твоем случае все зависит от источника данных
|
Сообщ.
#10
,
|
|
|
Если я спрашиваю устройство на чтение/запись одного регистра(8байт), то и ответ приходит 8байт. Все нормально, на скорости 9600, без провалов приходит вся посылка. Если спрашиваю, чуть больше, 2-4 регистра, например состояние входов, то каждый по два байта, и как бы не успеваю в одну посылку получить... 8 байт ответа +количество регистров *2байта данных
|
Сообщ.
#11
,
|
|
|
В этом чудо компоненте, есть чудо приблуда ComDataPacked и событие onPacked, которая в свою очередь ждёт начала и конца пакета и возвращает сам пакет. Теперь внимание вопрос, как ей дать стартовый и стоповый бит
Добавлено Или не ждёт, тогда придется работать с тайм-аутами. Что сильно не надёжно |
Сообщ.
#12
,
|
|
|
Для таких мизерных объемов данных таймаут в общем-то сойдет. Но да, лучше без него. А что мешает вообще не отслеживать концов пакета? Собирай по событию в буфер и пробуй разбирать ответ. Получилось - окей, пакет целый. Не получилось - ждем еще какое-то время.
|