Опять COM-USB

asdvas

Вот я понимаю что эта тема порядком всех подзадолбала

Подсажите пожалуйста что делать:
Есть контроллер AT89C52 с физич USART все это дело с помощью МАХ232 прекрасно общалось с РС через СОМ порт. Но вот возникла необходимость использовать вместо СОМ -а USB. Взял я первую схему с http://www.radiokot.ru/circuit/digital/pcmod/05/ купил микруху (за 112р. :))

) и собрал все это дело. (сделал общий 0 для усб и сом, а то как то странно без общего нуля)

При подключении вот что выяснилось: на передачу все работает нормально. Сканом порта сравниваю то что отправлялось с физического и с виртуального ком порта - все совпадает(да и железо управляемое контроллером работает как надо).
А вот при приеме данных с контроллера возникают проблемы:
1) данные скана порта виртуального и физич кома не совпадают, ну так то бог с ним, можно установить закономерность и вычислить интересующие данные. - хотя очень странно, я думал что должно быть тоже что и при использовании физического ком-а
2)

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

Подскажите пожалуйста в чем может быть проблема ??

asteroid7

Есть такая фигня, как USB латентность. Обычно программы на стороне компа ею управляют. У вас, похоже, по умолчанию стоит (16 мс).
Попробуйте в свойствах устройств в дополнительных параметрах данного СОМ порта закрутить время ожидания на минимум. И при посылке данных с контроллера ожидайте их после FTDI, как минимум, через 2 мс.

asdvas

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

стоит именно 16. Попробую 1 и 2. Завтра напишу результат. еЩЕ раз СПАСИБО

А вот еще вопрос: надоли устанавливсть таймауты ?? и на что они будут влиять ?

asteroid7

asdvas писал(а):надоли устанавливсть таймауты ?? и на что они будут влиять ?

Для просмотра сигналов ни на что влиять не будут. Установкой таймаутов программа-обработчик на стороне компа должна заниматься при приёме/передачи блоков.

asdvas

Вот проверил как будет работать с 2 и 1 мс вместно 16мс и.................. ничего не изменилось. Данные как принимались какие то "левые" так и принимаются

ПОЧЕМУ они не такие же как при использовании физического КОМ порта ???????????????? :cry:

asteroid7

Посмотрите программой "COM Port Toolkit".
Что передаёте, что принимает?

asdvas

Ну и за кого вы меня принимаете

"Посмотрите программой "COM Port Toolkit"."

Ну не этой программой, но смотрел и смотрю. Из чего и делаю вывод что между принятыми данными с физического КОМ порта и виртуального - огромная разница. Завтра (29.04) выложу для сравнения то что принимается .

Аксель

Протокол передачи RS232? Или другое, как организорвана передача данных?

Какие параметры при передаче (если RS232 )?

(Проверка работоспособности преобразователя через терминал методом закорачивания RXd TXd была? )
(Любой рабочий дата-кабель с usb-to-rs232 есть?

- для проверочки )

На заметку: если смотреть передаваемые данные снифером то показывает только то, что уходит в микросхему-преобразователь, и никак не то, что именно выходит с микросхемы-преобразователя к МК.

asteroid7

asdvas писал(а)::) Ну и за кого вы меня принимаете

Я вас принимаю за человека, который за три дня не смог сделать то, что делается за 15-30 минут.
Нужно было всего то, отделить в каком месте происходит сбой. Три варианта: софт на компе, ftdi, контроллер.
А гадать можно бесконечно. Это может быть и питание, неправильное подключение ftdi, не подтянутые входы/выходы, корявый провод, старые ftdi дрова, софт на компе использующий не стандартные функции порта. В принципе, всё что угодно...

DeltaQ

У меня тоже щас некая проблема с Портами.
Может что посоветуете?
Ситуация в следующем:
Есть устройство на микросхеме FT232RL (имитация Компорат через USB) использую библиотеку Async32 в Borlond C++.
Устройство передает данные со скоростью 4 байта в 1мс, Битрейт соединения стоит 115200.
Латентность в драйверах устройства ставил с 16мс до 1мс ну чуть быстрей работать начинало не более.
Но реально получается что программа со стороны компа не успевает опрашивать... Я слыхал что операционная система обращается к портам 1раз в 5 миллисекунд или около того... возникает вопрос какже тогда реализуют передачу данных на скоростях 256000 ... 2М ? Потому что щас мне надо получать данные со скоростью 4 байта за 1мс, а чутка позже понадобиться принимать данне от 12 разрядного АЦП со скоростью дискретизации до 100кГц.

З.Ы. на данный момент скорость приема такова что принимаю где-то 50 4 байтных числе в секунду.

С Портами в таком режиме работаю впервые поэтому как бы в неком замешательстве.

asdvas

"Протокол передачи RS232? Или другое, как организорвана передача данных?" - протокол RS232.
8 бит, 1 стоповый, контроля четности и управления - нет, скорость 1200 б/с

попробовал закоротить RXd TXd и в общем что отсылаю то и приходит

....... во блин. :idea:

это ,что значит ?? типа все косяки похоже на контроллере ?? или я не прав ?

"(Любой рабочий дата-кабель с usb-to-rs232 есть? - для проверочки )" - к большому сожалению нет

а Аксель, что вы имели в виду под проверить ?? просто посмотреть как с ним будет работать ? или что то более хитрое :wink:

"На заметку: если смотреть передаваемые данные снифером то показывает только то, что уходит в микросхему-преобразователь, и никак не то, что именно выходит с микросхемы-преобразователя к МК." - к заметке

, там блок стоит (анахронизм так сказать) и если его подключить мона смотреть что пришло на контроллер и что он там считает

а снифером смотрел конеш что принемаю

asdvas

А вот я правильно делаю, что соединяю напрямую выходы RXd TXd на переходнике с RXd TXd выходами на контроллере at89c52 ??? ну и землю делаю общую ?

at89c52 datasheet
www.datsi.fi.upm.es/docencia/Micro_C/atmel/doc0313.pdf

asteroid7

DeltaQ писал(а):У меня тоже щас некая проблема с Портами.
Может что посоветуете?
Ситуация в следующем:
Есть устройство на микросхеме FT232RL (имитация Компорат через USB) использую библиотеку Async32 в Borlond C++.
Устройство передает данные со скоростью 4 байта в 1мс, Битрейт соединения стоит 115200.
Латентность в драйверах устройства ставил с 16мс до 1мс ну чуть быстрей работать начинало не более.
Но реально получается что программа со стороны компа не успевает опрашивать... Я слыхал что операционная система обращается к портам 1раз в 5 миллисекунд или около того... возникает вопрос какже тогда реализуют передачу данных на скоростях 256000 ... 2М ? Потому что щас мне надо получать данные со скоростью 4 байта за 1мс, а чутка позже понадобиться принимать данне от 12 разрядного АЦП со скоростью дискретизации до 100кГц.

З.Ы. на данный момент скорость приема такова что принимаю где-то 50 4 байтных числе в секунду.

С Портами в таком режиме работаю впервые поэтому как бы в неком замешательстве.

Посоветую забросить библиотеку Async32 куда подальше. Скачать с сайта FTDI набор функций для работы с библиотекой под builder. А лучше, напрямую обращаться к dll. Подробное описание всех точек есть в pdf-e.
Выжать максимальную скорость можно только через аппаратный UART в FTDI используя буферы. Загрузить/считать из них – одна команда. И если буферы не успеют очистится за минимальное время обращения, то получится непрерывный поток. Дрыганье другими ногами, т.е. при подачи любой новой команды в м/с задержка будет 2 мс минимум.
В Вашем случае нужно протокол сделать так, чтобы как можно больший блок данных передавался/принимался.
Например, у меня есть устройства, который через эту FTDI нормально работают на скорости ~1M с обычной мегой. Блоки гоняю по 540 байт.

DeltaQ

asteroid7 писал(а):Посоветую забросить библиотеку Async32 куда подальше. Скачать с сайта FTDI набор функций для работы с библиотекой под builder. А лучше, напрямую обращаться к dll. Подробное описание всех точек есть в pdf-e.
Выжать максимальную скорость можно только через аппаратный UART в FTDI используя буферы. Загрузить/считать из них – одна команда. И если буферы не успеют очистится за минимальное время обращения, то получится непрерывный поток. Дрыганье другими ногами, т.е. при подачи любой новой команды в м/с задержка будет 2 мс минимум.
В Вашем случае нужно протокол сделать так, чтобы как можно больший блок данных передавался/принимался.
Например, у меня есть устройства, который через эту FTDI нормально работают на скорости ~1M с обычной мегой. Блоки гоняю по 540 байт.

Я чето найти на могу где у них есть документашка с библиотеками для работы под Борланд?
У них линк сюда ведет на Мелкософтовский МСДН..
http://msdn.microsoft.com/en-us/library/ms810467.aspx
По сути я так понимаю они предлагают работать через стандарные функции: CreateFile ReadFile WriteFile

А вот это?
http://www.ftdichip.com/Projects/CodeEx ... uilder.htm

asteroid7

Ошибся. Под С++ нету у них, только хедер можно взять из примеров. Для delphi они написали D2XXUnit, не применял его, но для понимания помог.

На всякий случай документация: Documents -> Programming Guides -> ftdichip.com/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf

DeltaQ

asteroid7 писал(а):Ошибся. Под С++ нету у них, только хедер можно взять из примеров. Для delphi они написали D2XXUnit, не применял его, но для понимания помог.

На всякий случай документация: Documents -> Programming Guides -> ftdichip.com/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf

А использование CreateFile ReadFile WriteFile не поможет? стоит мне переписывать программу под работу этих функций? (просто не хочется тратить время если это не спасет ситуацию )

з.ы.
Вообще то у них в дровах лежат библиотека в CDM 2.04.16 WHQL Certified\i386\ftd2xx.lib и CDM 2.04.16 WHQL Certified\ftd2xx.h я так понимаю как раз работу с этой библиотекой и подразумевает тот Документ.

asteroid7

Документ работает с ftd2xx.dll. Что такое ftd2xx.lib - я не вкурсе.

А использование CreateFile ReadFile WriteFile не поможет?

Делайте как знаете...

Вся работа с этой длл в вашем случае сводится:
FT_OpenBy.. - открыть. FT_SetBaudRate, FT_SetDataCharacteristics - настроить. Передача блока FT_Purge (TX) + FT_Write. Приём блока FT_Purge (RX) + FT_SetTimeouts + FT_Read. FT_Close - закрыть.

Аксель

asdvas писал(а): попробовал закоротить RXd TXd и в общем что отсылаю то и приходит Smile ....... во блин. Есть идея!!! это ,что значит ?? типа все косяки похоже на контроллере ??

походу - да.
(кабель нужен был бы при нерабочем преобразователе)

Исчите - мк: фузы, код, железо мк.

DeltaQ

asteroid7 писал(а):Документ работает с ftd2xx.dll. Что такое ftd2xx.lib - я не вкурсе.
А использование CreateFile ReadFile WriteFile не поможет?
Делайте как знаете...

Вся работа с этой длл в вашем случае сводится:
FT_OpenBy.. - открыть. FT_SetBaudRate, FT_SetDataCharacteristics - настроить. Передача блока FT_Purge (TX) + FT_Write. Приём блока FT_Purge (RX) + FT_SetTimeouts + FT_Read. FT_Close - закрыть.

Кстати спасибо твои вектор мысли правильно меня направил.
Я уже подрубил ее к своему проекту, щас разбираюсь как оптимальней сделать.

А ты работал с этими библиотеками?
Просто в том же описании они как бы говорят о возможности работы и через FT-Win32 API Functions функций типа ( FT_W32_CreateFile FT_W32_ReadFile и т.д.) чем они по сут отличабться от (FT_Open FT_Read) ?

З.Ы. ftd2xx.lib нужна для того чтобы при подключении #include "ftd2xx.h" файла в программе она могла работать с dll модулем. Там необходимо подключить эту библиотеку к проекту.
Кстати библиотеки есть разные одни для Мелкософта другие Борлондовские.

asteroid7

Да, работал и не плохо разобрался. Если что, спрашивай.
На все функции с префиксом W32_ я забил. Без них всё летает. Их для там какой то совместимости ввели. А если присмотреться, то большинство из основных дублируются W32_.
На счёт ftd2xx.lib я не знал. Тут у меня пробел. Так издавна сложилось, что под контроллеры пишу на C/C++, а под win в delphi. Показалось, что в связке удобнее проекты отлаживать. При открытие окна сразу видно для чего открыл. Так и повелось.

К тому же, на delphi все основные компоненты в тексте, а под borland они же откомпилированные.
Ну и ещё один плюс за delphi, как в данном случае, ему тупо нужна только одна dll.