Пишу это, чтобы другие на эти грабли не наступили.
Надо было древний программатор запустить. Вот купил это самое Г. Часа 3 дровами в компьютере шевелил - не работает.
Потом взял осциллограф, посмотрел и прослезился.
Вместо уровней RS-232, на разъеме уровни UART-а 3,3v.

В прикрепленных файлах фотографии девайса.
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

мин.рабочее напряжение ресиверов RS232 -3 и 3В, так что адаптер в пределах нормы. Копайте схему программатора, скорее всего там проблема с уровнями, если простейшая схемка типа Ponyprog или JDM то конечно не заработает. Поможет внешняя MAX232

Это не главная проблема таких изделий, гораздо хуже, что они часто вообще не определяются, как USB-устройство.

ukpyr, там от 0 до 3 вольт уровни. А не от -3.

san822, ну если пропаять - то определяются =)

0..-15В допустимо в качестве низкого уровня, а 1ца - от 3В (напр.даташит на HT6571)и определяются как prolific, а драйвера нужны родные китайские

Хватит спорить об уровнях. Там был чистый TTL сигнал. Если его подать на UART любого поца, он был бы туда как родной. Очевидно китайцы МАХ забыли припаять.
Дрова работали (USB устройство распознавалось), но только до тех пор, пока не соединишь с RS232 клиентом. После чего устройство сразу становилось не известным.

Сегодня еще разок съездил на радио базар. Тот вернул в зад, тому у кого взял и притащил новый.
Внешний вид такой же. Другая упаковка и начинка. Сквозь полупрозрачный корпус просматривается две многоногие мелкосхемы. По одной с каждой стороны. Вот и все визуальное отличие. Тоже китайский.
На скорости 115200 работал как часы. В винде отображался как обычный COM порт.

Фотографии прилагаются.

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

данные на TX передавались нулём ? у меня похожий адаптер ( http://www.dealextreme.com/details.dx/sku.24799 ), там данные передаются единицей, но уровнями TTL. Для связи с другими портами RS232 покатит, но для программаторов - нет.

Точно так, купил эту фигню. Слегка офигел, когда увидел такое безобразие, но с большинством трансиверов RS-232 работает вполне нормально...

Уважаемые, а ответье кто нибудь на такой вопрос

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

А чем передаете?

Передаю из Матлаба в цикле. На осциллографе вижу пачку передач, а затем программная задержка в 80-100мс, потом следующая пачка.
При передаче средствами С++ такой задержки не возникает?

А вы галочку "Enable RTOS" при установке Windows не забыли поставить?

А что, можно было? :-)

Если серьезно, то я не понимаю вот чего
Я использую виртуальный RS-232 - на отладочной плате стоит преобразователь USB->RS232, в системе существует виртуальный КОМ-порт. Почему я не могу использовать его скорость по максимуму?

Ведь когда я записываю файлы на флэшку, то делаю это с нормальной скоростью в несколько мегабит. А у меня передача идет короткими пакетами с высокой скоростью, а потом паузы. Значит дело все таки поправимо?

ИМХО "115200" - это скорость среды. Фактическая передача всегда будет с меньшей скоростью. В том числе и за счет пауз между байтами/посылками. Величина этих пауз определяется возможностями передающей стороны + старт/стоп условиями.

Вот именно так у меня и происходит. Битовая скорость внутри посылок 1.5Мбита, так как физически RS232 не существует нигде, то и ограничение на скорость от USB. А вот изза пауз реальная скорость передачи данных составляет 30 кБит/сек

Скорее всего, дело в вашей программе.
Вы точно пакетами данные передаёте или побайтно?
Дело в том, что ваш пакет (или байт) должен упаковаться во фрейм USB, передаться (с возможными задержками в несколько мс), потом распаковаться и выйти наружу в виде RS-232.
Если вы передаёте пакет, он просто упакуется в фрейм и передастся.
Если каждый байт по отдельности - получите отдельный фрейм для каждого байта и соответственно, задержки тоже.

MrYuran пакетами по 1024 байта по 6 бит. Да, пакетная передача работает нормально. При больше длине пакета возникают некоторые задержки внутри пакета (появляются промежутки между байтами), но все в пределах нормы.
То есть если я выполняю запись в порт s
>>fwrite(s,STR)
Где STR - строка на 1024 символа, то на осциллографе я увижу пакет из 1024 байт, с битовой скоростью 1.5 МБита

Если же я запущу
fwrite(s,STR1)
fwrite(s,STR2)
То между пакетами будет интервал в 100мс, а внутри пакетов все по прежнему хорошо. Условно говоря возникает задержка при переходе от строчки к строчке

Так что вас собственно удивляет? Между вызовом fwrite и реальной передачей может пройти неопределенное количество времени (кто знает как их драйвер устроен и чем сейчас система занята)

А меня и не удивляет, меня интересует как решить эту проблему
1) Как устроен драйвер и в какую сторону нужно копать?
2) Как разгрузить систему? Пробовал работать в безопасном режиме, но не дает открыть ком-порта.

Вообще, реальная скорость передачи - это ответственность программиста, который это написал. Передающая сторона сваливает данные в передающий буфер, вполне реального размера. Дальше передающий драйвер дует этот буфер, на скорости стремящейся к максимальной, в канал. А там заполняется приемный буфер. Драйвера как правило пишут профессионалы и тут все в порядке. А вот сколько времени нужно передающей программе, чтобы сформировать буфер. И приемной стороне, чтобы обработать принятый массив. В 95% случаев, которые я встречал, тормозило именно здесь. И многозадачность винды тоже добавляет тормозов.

Вообще, самая тяжелая ситуация, когда данные идут из примитивно девайса (типа меги или TMS) в персоналку. Тут приходится контролировать, что все данные приняты. А иначе можно не только байты, а целые пакеты потерять.