Всем доброго времени суток.

Упали мне в руки два блюгиговских кита с WT32. Потребовали наскоро (ха-ха) испытать чип на пропускную способность при использовании UART/USB (USB временно отпал в связи с врожденной инвалидностью iWRAP).

Оба кита подключил к ПК под Win7 через Prolific-овские адаптеры PL2303X, драйвер 3.4.36.247 (июль 2012). Пробую под терминалами (PuTTY, Hyperterminal от хрюши, т.к. блюгиговский BGTerm упорно не желает работать). Flowcontrol аппаратный. WT32 прошит iWRAP 4, билд 317.

1. Опробовал обмен путем передачи на WT32 файла с заведомо быстрого BT-устройства, профиль OPP.

Настройка UART WT32 - 115кбод, измеренная скорость передачи близка к теоретическому максимуму (~80кбит/c).
Настройка UART WT32 - 56кбод, скорость передачи ~40кбит/c.
Настройка UART WT32 - 230кбод, скорость передачи ~110кбит/c...?
Настройка UART WT32 - 460кбод, скорость передачи ~110кбит/c...?!

2. Два WT32, обмен друг с другом, немультиплексированный SPP, скорость UART-ов 460кбод, аппаратный flow control. Проверяю путем выбрасывания в терминал одного из модулей текстовика (после установления "прозрачного" режима).

Скорость обмена катастрофическая (ниже 25кбит/c).

Явно что-то делаю очень не так, но что? Поискал по форуму и в инете вообще - проблема встречается, но не в столь мрачном виде.

В тесте с SPP на подозрении программы терминала (не успевают пропихивать байтовый поток из файла в COM-порт?).
В тесте с OPP не знаю на что думать. Формально последний датащит на iWRAP обещает Но вот что мешает выбросить данные на достаточной скорости при профиле OPP - не понимаю. В userguide на iWRAP встречал цифру в максимум 50 кбит/c при использовании OBEX - очевидно, что это не совсем так, но и потолок в 110кбит/с выглядит престранно.

З.Ы. Конечно, следовало бы или прикрутить к обеим китам по платке с контроллерами (для управления и передачи данных по UART) и обойтись без такой непрозрачной вещи, как виртуальный COM-порт и программный терминал. Или браться за xIDE и программировать BlueCore, стоящий на модуле.

Да, интересные результаты. Причина снижения пропускной способности при повышении скорости UART может быть в том, что в связи с помехами в радиоэфире растет количество ошибок при передаче. Модуль пытается бороться с этими ошибками путем повтора сообщения ,что в итоге приводит к снижению скорости передачи данных. Если Вы передавали файл через обычный Гипертерминал Windows, то там во время передачи в одном из окошек отображается количество ошибок при передаче. Посмотрите внимательно на этот параметр. Он как-то меняется при изменении скорости UART? Понятно, что количество ошибок при передаче - параметр случайный. Но передав один и тот же файл несколько раз при одной и той же скорости UART, можно оценить его в среднем. Лично я встречал такой эффект. Теоретически с ростом скорости UART должна расти итоговая пропускная способность канала. Но на практике всегда есть некая оптимальная скорость UART для каждой задачи.

Кстати, а в чем проявляется неработоспособность Блюгиговского терминала? У меня вроде все работало.

Забыл отписать - проблема оказалась стара как мир, но я по серости узнал о ней случайно, и только с помощью осцилла.

Втыкаю осцилл в шину и сразу же вижу, что из UART-а в блюгиговскую плату данные идут коротенькими пакетами с огромной паузой в 1 мс. Изредка проскакивают моменты, когда 1мс интервал заполнен передаваемыми словами очень густо. Стало ясно, что WT32 не виноват - просто ему не приходит достаточно данных для передачи. Нет данных - нет и потока в SPP-соединении. Ну, соответственно, и приема с нужной скоростью на другом конце.

Как оказалось, мосты USB-COM в принципе не могут дать приличного потока данных из-за драйвера, т.к. у них обращение к регистрам USB-устройство драйвер привязывает к таймеру на 1 КГц. А буфер у Prolific-овского чипа, на котором сделана львиная доля ширпотребных переходников, крохотный (по 16 байт в одну и в другую сторону). Вот он и выдает поток в десятки кбит/c.

Заменил переходники USB-COM на PCI-платы (брал первые попавшиеся Orient) - поток подпрыгнул раза в три (270-310 кбит/c). При этом видно, что в принципе беда у адаптеров та же (паузы в потоке передаваемых слов) - просто больше буферы (по 128 байт и на TX, и на RX) и расторопнее драйвер.



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