Потеря байт при работе с COM портом

[bee]

to dadreamer настроено все одинаково, проверил. С МК информация на терминал и в LV приходит. Получаю "1" от МК, но на попытки послать число/ASCII-символ в МК ответа нету.

to anda55 как проверить символ который получает МК?
Через встроеную отладку в прогу Flowcode прошивка МК работает и на передаваемый символ "1" шлет свой ответ, который кстати тоже корректно отображается при отладке.

Я все же склоняюсь к несоответствию кодировок между посылками МK и LV.

[dadreamer]

на попытки послать число/ASCII-символ в МК ответа нету.

А через терминал отправляли в МК? Если не доходит, то дело не в LabVIEW. Попробуйте стандартным HyperTerminal'ом в винде.

[bee]

К сожалению, стандартного терминала не имею, использую прогу RealTerm для реализации терминала.
Определил, что МК, когда ничего не передается с СОМ-порта считывает байт 0хFF (опять вернулся к процедурам send/receive char). Сделал тестовую прогу на МК, если на входе не 0хFF то передать в СОМ-порт, то что на входе.

в итоге терминал на передачу чисел 0,1,2,4 выдал ответ В0, а на 3,5 выдал F0.
LV на передачу 0,2,3,4 получил F0, на 1 получил 8C, 5 без ответа.

Я в замешательстве

фрагмент С кода в МК

while (1)
{
FCV_RECIVE_BYTE = FCD_RS2320_ReceiveRS232Char(100);
if (FCV_RECIVE_BYTE == 0xFF)
{
} else {
FCD_RS2320_SendRS232Char(FCV_RECIVE_BYTE);
delay_s(1);
}
}

[anda55]

как предложили, скачай Hyper Terminal и посмотри, что передает МК в LV

[dadreamer]

Вы принимаете и передаете данные на МК в виде числа типа char. Целый тип char занимает в памяти 1 байт (8 бит) и позволяет выразить в двоичной системе счисления 2^8 значений=256 (от 0 до 255 (FF)). А в LabVIEW вы отправляете/принимаете через Визу строку, содержащую "1","2" и т.д. Хотя, если бы в этом было дело, то на отправку "0" МК бы отправлял 0x30, что соответствует коду символа "0"... Сделайте в МК бесконечный цикл, отправляющий в порт какое-нибудь число, например 0x30, с некоторой задержкой. В гипертерминале посмотрите, что приходит. Скачать можно, например, отсюда.

В гугле находятся какие-то темы, вдруг помогут: 1, 2.

[bee]

Спасибо всем за помощь.
Прога выложенная ранее функционирует нормально, загвоздка была в МК.
Как ни странно помог переход на другую оболочку программирования МК. Сначала пользовался Flowcode потом перешел на CodeVision и получилось

на отправку "0" МК бы отправлял 0x30

как подсказал dadreamer.
В общем проблема решена.

[dadreamer]

bee, наверно, во включаемом через #include файле были не те определения (typedef'ы) функций FCD_RS2320_ReceiveRS232Char и FCD_RS2320_SendRS232Char.

[bee]

Функции FCD_RS2320_ReceiveRS232Char и FCD_RS2320_SendRS232Char реализованы только во Flowcode и они закрыты для редактирования.
В CodeVision аналогичные функции getchar и putchar, я немного изменил на Receive и Send.

Внизу приложу код С, может кому понадобиться.
При загрузке проги в МК происходит мигание светодиода на PORTB.0 и в СОМ порт передается 1. Далее в цикле при получении байта с СОМ порта он перенаправляется обратно в СОМ в случае прихода 1 опять моргнуть PORTB.0.

Причем есть нюанс (пока не разобрался в причине), прога заработала только после перезагрузки ПК. А так на передачу из LV 1, МК отправляет 31 без срабатывания светодиода.

С гипертерминалом так и не разобрался. Для аудита СОМ порта использовал Realterm_2.0.0.70.

[sirQWERTY]

Всем привет. Вопрос задавался, но решения, как я понял, так и не публиковалось тут. Опишу суть вопроса в свете своей задачи. Задача у меня не сложная: я принимаю 8 байт от МК по COM порту. Мне необходимо принимать эти 8 байт в нужной последовательности. Сначала я пробовал принимать по 8 байт, но тут возникали сложности с синхронизацией - я мог начать прием пакета с 3 байта а закончить 2-м, соответственно, информация интерпретируется не верно. Пробовал работать с терминатором - работает более стабильно. Но так как полезные байты изменяются в очень широком диапазоне - не редок они принимают значение стоп байта, и тогда посылка прерывается раньше необходимого момента. Подскажите, как мне принять мои 8 байт в нужной последовательности? У меня есть вариант, установить в качестве стоп байта 0x00, силами МК проверять равенство байтов полезной информации этому числу и если это равенство есть, просто увеличивать на 1 это число. Но мне видится это решение не очень элегантным.

[dadreamer]

sirQWERTY, прочтите вот это сообщение: http://www.labviewportal.org/viewtopic. ... 865#p65865 Ну, или тут в несколько иной форме: http://www.labviewportal.org/viewtopic. ... 859#p65859

[sirQWERTY]

Спасибо. Это я понимаю на уровне интуиции. Я в новичок, возможно не вижу простейшие алгоритмы. Подскажите, как определить код начала посылки и после него принять нужные мне 8 байт?

[Vitekkz88]

sirQWERTY писал(а):Сначала я пробовал принимать по 8 байт, но тут возникали сложности с синхронизацией - я мог начать прием пакета с 3 байта а закончить 2-м, соответственно, информация интерпретируется не верно.

На стороне МК данные в порт по одному байту приходят что ли!? Какое расточительство...Формируйте пакеты на стороне МК, а не отдельные байты. Хотя бы 5 пакетов выгружайте в COM-порт из МК - это всего 40 байт. На стороне LabVIEW так же заказывайте 40 байт. И не будете страдать. Ах да, перед тем как начинать работу с COM-портом - делайте очистку буфера, чтоб там мусора не было.

sirQWERTY писал(а):Подскажите, как определить код начала посылки и после него принять нужные мне 8 байт?

А как у Вас определен код начала посылки? Это какой-то спец.символ или группа символов?
Чудес не бывает, без определенного уникального идентификатора Вам не обойтись. Терминатор на то и вводится в сообщения, чтоб быть уникальным, а не встречаться через раз в полезных данных.
Вводите символ начала пакета из двух байт, а если будет мало - то используйте 4 байта. В общем тот размер, который будет перекрывать диапазон значений полезных данных. Недостаток - будет больше служебной информации. Мы в своих протоколах обязательно вводим заголовок с полями, которые однозначно позволяют интерпретировать где начало пакета, а где конец, добавляем инкрементацию пакетов и контрольную сумму. Естественно на стороне железа никто не занимается какими-то сравнениями и т.д. Просто данные либо отправляются, либо нет. В момент моего подключения я заказываю, к примеру 64 байта, а дальше работает алгоритм парсинга и анализа данных в LabVIEW.
Либо инициируйте передачу с помощью события в LabVIEW: кнопку нажали - данные посыпались.

[dadreamer]

В общем-то, уже всё сказано. Вам нужно придумать формат пакета данных, а потом уже работать по этому формату. Раз у вас в самих данных может встретиться какой угодно символ, в т.ч. и терминатор, то используйте такой формат:

В случае с бинарной посылкой формат используется следующий:
голова - код начала посылки, код тела посылки и/или длина посылки + другие данные, которые имеют одинаковое значение для всех посылок данного устройства. Размер головы посылки также фиксирован для устройства
тело посылки - содержит изменяемые по формату данные. Формат непротиворечиво соответствует коду посылки
хвост - контрольная сумма (если надо) тела посылки+головы и код конца посылки
Для приема бинарной посылки терминальный символ отключается. Производится чтение головы посылки, ее разбор. На основании разбора головы посылки вычисляется длина тела посылки. После чего вычитывается тело посылки известной длины и хвост. Проверяется соответствие кодов начала и конца посылки.

[sirQWERTY]

Данные идут пакетами по 8 байт, но они валятся постоянно, интервал времени между конкретными байтами и между пакетами одинаковый. В данных идут значения с гироскопа, датчик выдает угловую скорость, поэтому, чтобы получить угол поворота, мне необходимо эти данные интегрировать. Поэтому я не могу особо играть задержками между пакетами и байтами в пакетах. Как вариант, можно конечно эту математику в МК реализовать и выдавать на ПК уже готовые значения углов.
Сейчас в пакете 9-м байтом присутствует терминатор. Я также могу сделать байт (два, три) заголовка, да собственно любой формат пакета могу сделать, но я не знаю, как на стороне идентифицировать этот заголовок и начать прием (заказать эти 8 байт) полезных данных с первого по последний. Вот в чем вопрос.
Сейчас мой прибор выглядит так:

[Vitekkz88]

Данные идут пакетами по 8 байт, но они валятся постоянно...я не знаю, как на стороне идентифицировать этот заголовок и начать прием (заказать эти 8 байт) полезных данных с первого по последний. Вот в чем вопрос.

Перед чтением делайте очистку буфера COM-порта(тем самым удалите мусор). Далее - VISA Read будет ожидать, пока в буфере порта не появится заявленное кол-во данных. Как только необходимое кол-во накопилось - происходит чтение. И если первым байтом считался какой-то левый байт(а не начало заголовка пакета, например) - то проверяйте, что в порт положили. Начните с простого: отладка на константах и на невысокой скорости. Кстати, приткнитесь осциллографом к ногам передачи данных и сравните - соответствует ли скорость передачи данных действительности.
Не может быть такого, что пакет из буфера читается с какого-то байта из середины пакета. Значит пакет так сформировали или он как-то коряво лег в буфер. Либо как-то странно данные в буфере обновляются. Проверяйте в общем.