Я пишу для микроконтроллеров. Но пришлось написать и программу для компьютера, хоть я почти и не понимаю в C++. Она должна передавать и принимать данный от микроконтроллера через COM порт. Вставил чужой код, который должен принимать данные с COM порта, а он не пропускает коды 11h и13h. Я понимаю, что это символы перевода каретки, но сам исправить положение не могу. Помогите, кто знает.



Это сообщение отредактировал(а) ZPavel - 1.4.2007, 18:58

Помогите кто нибуть, пожалуйста.

Вызов ReadFile можно записать проще:


Я не знаю, что делает функция caserbyte, возможно эти символы просто не отображаются в Memo.
Поставь breakpoint на ReadFile и смотри значение RecByte в отладчике.

Проверил 
аналогично, RecByte значений 11h, 13h не получает.

Может открыл файл как-то не так. Поверь на слово: спокойно можно гнать любые байты через RS232 в любом количестве.

Символы перевода каретки это 10 и 13, в шестнадцатеричном виде 0xA и 0xD, соответственно.

И вообще, читать данные лучше в асинхронном режиме.

А мы использовали компонент ApdComPort - просто и удобно работать с ним

Я пользуюсь компонентой TComPort. Визуальная компонента, событийная система, очень удобно.

а где его взять, этот Ваш ApdComPort

Поискал в интернете tcomport, и нашел только за деньги, что делать, где найти даром? И еще, есть ли, описание tcomport на русском?

Как ищем: смотри здесь

Вот пример реботы с ком портом, можете посмотреть, маленький, говый проект. Я брал его за основу. И он не принимает эти коды, почему. Может кто-то поймет по реальному примеру.

Присоединённый файл ( Кол-во скачиваний: 28 )
 rs232cpp.zip 7,34 Kb

Что, никто не в состоянии понять куда деваются 11h, 13h, в примере?

Если ты ничего не получаешь на ком порт, может быть туда ничего и не приходит?   А если серьёзно, что означет, что эти байты не приходят? Что ты ожидаешь от своего куска кода (в первом посте)?
Для тестирования подобного рода программ рекомендую связку программ Virtual Serial Ports Driver XP от Eltima Software (эмулирует пару или даже больше, если требуется ком портов, соединных нуль модемным кабелем) и какую нибудь терминальную прогу (я юзаю Com watcher Дмитрия Васильева) которая просто принимает и отсылает на ком порт байты.

Да я так и делаю, на 1 сом порт свою прогу, на 2 сом порт терминальную, и нуль-модемный кабель. Это именно моя прога не принимает 11н, 13н. Тот пример, что я выложил, я брал за основу его, он  на функциях api, ведет себя аналогично. Я думаю, что наверно никто раньше не обращал внимание на то, что функция API ReadFile, не пропускае парочку кодов. Или тогда дайте кто нибуть готовый пример, где пропускает все коды.

Еще раз: что ты ожидаешь, когда прийдут эти самые коды? Что делает функция caserbyte? TMemo не может отобразить 11h и 13h. ReadFile читает все, что приходит на ком порт.

Пиши в файл все что ловишь, и там смотри, если по-другому у тебя не получается. Стопудова там увидишь, если передаешь. Файл естественно смотри в двоичном режиме, а не в текстовом. Или еще лучше редактором шестнадцатиричным. Не первый год занимаюсь подобными вещами и смею тебя уверить, что ком-порт передает и принимает любые коды. Просто не туда куда-то смотришь. 
Если хочешь, выложи именно свой исходник и расскажи как конкретно ты не видишь свои заколдованные символы, попробую помочь.

ЗЫ: Интересно, как люди с модемами в нет лазят, когда    

Это сообщение отредактировал(а) black_priest - 14.4.2007, 10:09

Вот тебе простейший искуственный пример:



На форме кнопка и TMemo. Функцию PortInit() взял из своего проекта, что не нужно из нее выкинуть, что нужно - добавить. Пример рабочий - проверял.

Пока искал наткнулся на новую версию:
http://kent.dl.sourceforge.net/sourceforge.../cport-3.10.zip
Возможны проблемы с компиляцией, Пишите объясню.
Библиотека с открытым кодом, в прошлых версиях нужно было немного подправить, в этой незнаю.

Все, ничего не понимаю. Выкладываю свой проект. только сильно не смейтесь, это моя первая программа на си++. В ней все работает, что мне нужно, только вот нет приема 11н и 13н. Кодировка для передачи символов у меня своя, мне так удобней. Под кодами 11 и 13 у меня находятся символы 'г' и 'д'. Чтобы включить прием текста, нужно нажать кнопку - читать текст, программа пошлет число 252 микроконтроллеру, а он в ответ передаст текст, во время приема, программа его перекодируети выводит в мемо. те для проверки нажимаете - перадать текст - и можете посылать коды на ком порт.

Присоединённый файл ( Кол-во скачиваний: 9 )
 10strwin.zip 85,72 Kb

Да, сорри. Мой пример тоже не принимает 11h и 13h :( Перепутал системы счисления.

Это сообщение отредактировал(а) Usper - 15.4.2007, 18:09

Вывод, функция API ReadFile, не пропускает коды 11h и 13h, грусно.

Погоди паниковать, возможно еще не все потеряно. Порой справку на предмет DCB. К сожалению мои знания английского не позволяют разобраться :(. 

У меня или глюки, или одно из двух   Сегодня мой пример работает   (то есть принимает 11h и 13h).

А может глюки? 11Н и 13Н принимает, а 0DH и 0AH нет?   

Спокуха, все принимает. 11 в десятичной с.с. = 0Bh   


Это сообщение отредактировал(а) Usper - 16.4.2007, 20:33

Да я прикололся - просто символы конца строки 0d и 0A   
очень рад за вас, что мучения закончились.

первое что пришло в голову: в структуре DCB установи fBinary = TRUE; а ты все-таки установи 

что-то похожее было лет 8 назад ;) попытаюсь посмотреть архивы своих трудов ;)

уже не помню почему было сделано так черех tmp ;) но ключевое тут DCB_BINARY.

а вообще есть подозрение что ихнеправильно смотришь или они не приходят, смотри отладчиком ...

fBinary и так по умолчнаию равно true.

Взято здесь: http://www.firststeps.ru/

Так что делать? Я слежу за советами.

>fBinary и так по умолчнаию равно true

поэтому я и написал: а ты всеравно поставь!

>Так что делать?

Работать!

Все пропускается, я вообще данные гонял в двоичном режиме, т.е. передавал float с контроллера как четыре байта на компе их выворачивал и склеивал. Данных было огромное количество, заполнялась база данных - и ничего все работает!

1. проверь а отправляются ли они с контроллера, влоть до того что шли только этих два символа в цикле, а осцилом смотри что уходит ...
2. принимаемые данные смотри в своем массиве или что там у тебя, смотри в двоичном режиме, а не текстовом ...
3. проверь соответствие количества отправленных и принятых байт, может ты просто их не видишь ;) т.е. смотришь средствами, которые не отображают символы ...

Смотрите о я нашел:
В структуре DCB есть поля XonChar и XoffChar равные по умолчанию соответственно 0x11 и 0x13 это не символы перевода каретки (10[0x0A] и 13[0x0D]) их то вы и не можите принять. эти поля связаны с флагами fOutX и fInX.

Сейчас буду разбираться дальше (зачем они нужны).

2ZPavel: убери из строки LPCTSTR lpDef="2400,n,8,1,x" символ "x" в конце и будет тебе счастье, если только в этом причина. Действительно, как заметил Ivan, при установленных битах  fOutX и fInX символы  XonChar и XoffChar используются для программного управления потока, и поэтому не могут быть приняты. Если параметр fInX true, сигнал XoffChar посылается , когда входной буфер находится в пределах XoffLim байтов, а сигнал XonChar посылается в случае, если входной буфер находится в пределах XonLim байтов или является пустым. Параметр fOutX
определяет, используется ли управление потоком XON/XOFF  в течение передачи потока порту. Если параметр true, передача останавливается, когда получен сигнал XoffChar и возобновляется в случае если получен сигнал XonChar. Насчет твоего "x' в mode-строке читаем MSDN:

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

Ура, получилось. Убрал "x", и заработало. Большое, огромное спасибо. Пошел праздновать.  

Это сообщение отредактировал(а) ZPavel - 25.4.2007, 17:59

Слава Богу.

Это сообщение отредактировал(а) black_priest - 24.4.2007, 08:51