Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: XMega - FT232RL - PS
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
zombi
Господа помогите. Мозг уже плавится.
Схема: Xmega <-> FT232RL <-> PS.
Нужно по запросу от PS (путём посылки байта 0x40) получить от иксмеги 32MB данных.
Прогу на PS пишу на Delphi.
Передавать решил пачками по 512 байт (т.е. 65536 транзакций).
Скорость сом порта 2Mb/s.
Всё вроде работает, но есть один нюанс (напишу позже).
Вот так открываю порт:
Код
var h:thandle;
...
h:=fileopen('COM7',fmOpenReadWrite);
...

Вот процедура вычитки сом порта (максимально упростил для наглядности):
Код
procedure BUF_read;
var i,k:dword;B:byte;
    BUF:array [0..511] of byte;
begin
  B:=$40;
  for k:=0 to $FFFF do begin
    _hwrite(h,@B,1);
    for i:=0 to 511 do _hread(h,@buf0[i],1);
  end;
end;

RXD и TXD наблюдаю осциллографом.
Сразу после передачи писишкой байта 0x40 иксмега передаёт в ответ 512 байт затем пауза примерно 17ms и цикл повторяется.
Откуда эта пауза берётся?
Как от неё избавиться?
_Артём_
Цитата(zombi @ May 15 2012, 23:51) *
Сразу после передачи писишкой байта 0x40 иксмега передаёт в ответ 512 байт затем пауза примерно 17ms и цикл повторяется.
Откуда эта пауза берётся?
Как от неё избавиться?

Может watchdog сбрасывает?
zombi
Цитата(_Артём_ @ May 16 2012, 00:08) *
Может watchdog сбрасывает?

watchdog в мк выключен.
Проблема в том что писишка следющий байт запроса (0х40) передаёт после паузы.
Задержка именно в писишке.
мк отвечает сразу и нужным количеством байт, писишка их успешно принимает но следующий запрос передаёт после паузы!
Пробывал играться с таймаутами но ниче не меняется crying.gif
@Ark
Цитата(zombi @ May 16 2012, 01:17) *
... Задержка именно в писишке...

Вы ничего не сказали про управление потоком. Какие настройки для COM-порта в PC?
И как управляете этими сигналами со стороны UART FT232?
zombi
Цитата(@Ark @ May 16 2012, 00:25) *
Вы ничего не сказали про управление потоком.
Наверное никак не управляю. Тупо сижу и жду когда придут все 512 байт.
Цитата(@Ark @ May 16 2012, 00:25) *
Какие настройки для COM-порта в PC?
Getcommstate(h,DCB);
DCB.BaudRate:=2000000;
Setcommstate(h,DCB);
Цитата(@Ark @ May 16 2012, 00:25) *
И как управляете этими сигналами со стороны UART FT232?
Какими сигналами? и как оными управлять?
@Ark
Цитата(zombi @ May 16 2012, 01:32) *
Наверное никак не управляю. Тупо сижу и жду когда придут все 512 байт.
Getcommstate(h,DCB);
DCB.BaudRate:=2000000;
Setcommstate(h,DCB);

На счет Дельфи я Вам не подскажу, но желательно выставить режим порта 'без управления потоком', если этот механизм никак не используете.
В принципе, винда (если речь о ней) может давать задержки от 10мс до 300мс (иногда и более), Вас ни спрашивая ни о чем, и ни о чем
не уведомляя... Не реал-тайм эта система - имеет право, как говориться...
zombi
Цитата(@Ark @ May 16 2012, 00:42) *
В принципе, винда (если речь о ней)
О ней родимой. windows 7
Цитата(@Ark @ May 16 2012, 00:42) *
На счет Дельфи я Вам не подскажу, но желательно выставить режим порта 'без управления потоком', если этот механизм никак не используете.
Надо будет поискать что это за режим.
Цитата(@Ark @ May 16 2012, 00:42) *
В принципе, винда (если речь о ней) может давать задержки от 10мс до 300мс (иногда и более), Вас ни спрашивая ни о чем, и ни о чем
не уведомляя... Не реал-тайм эта система - имеет право, как говориться...
Настораживает завидное постоянство задержки ~17ms. Хотя небольшая девиация имеется ~0.4ms.
При общем периоде транзакций ~20ms.
Не может ли это быть как-то связано с RTC писишки? что то когдато слышал про какието вродебы 18ms?
@Ark
Цитата(zombi @ May 16 2012, 01:57) *
Настораживает завидное постоянство задержки ~17ms. Хотя небольшая девиация имеется ~0.4ms.
При общем периоде транзакций ~20ms.
Не может ли это быть как-то связано с RTC писишки? что то когдато слышал про какието вродебы 18ms?

Насчет таймера - не знаю, его период когда-то был порядка 18,2 мс (точная частота 1193180/65536).
Но нужно принимать, как данность, задержку между пакетами в 20мс, как среднестатистическую, если имеете дело с виндой.
И быть готовым к задержкам порядка 100-300мс - время от времени. И, очень редко, - к 'зависаниям' на пару-другую секунд.
Все это - по опыту общения с виндой, вплоть до ХР. Что там дальше- не ведомо...
zombi
Цитата(@Ark @ May 16 2012, 01:11) *
Но нужно принимать, как данность, задержку между пакетами в 20мс, как среднестатистическую, если имеете дело с виндой.
И быть готовым к задержкам порядка 100-300мс - время от времени. И, очень редко, - к 'зависаниям' на пару-другую секунд.
Все это - по опыту общения с виндой, вплоть до ХР. Что там дальше- не ведомо...

Дык, сама то задержка не напрягает. Напрягает время за которое, с учётом оной, писишка прочитает 32МB.
По идее без задержки (на скорости 2Mb) должно быть ~167 сек, а с задержкой получается 1310 сек!!! wacko.gif в восемь раз дольше!!!
Наверно надо размер буфера увеличивать.
@Ark
Цитата(zombi @ May 16 2012, 02:28) *
Дык, сама то задержка не напрягает. Напрягает время за которое, с учётом оной, писишка прочитает 32МB.
По идее без задержки (на скорости 2Mb) должно быть ~167 сек, а с задержкой получается 1310 сек!!! wacko.gif в восемь раз дольше!!!
Наверно надо размер буфера увеличивать.

На сколько помню, передаваемый по USB пакет имеет ограничение. Выше него не "прыгните".
Давайте подождем комментариев более компетентных в этом вопросе коллег. sm.gif
V_G
А вы попробуйте какой-нибудь терминалкой принять файл 32 метра с другого компа через 2 адаптера USB-COM (или через две FT232). Получите опорное время, вокруг которого можно будет прыгать
@Ark
Цитата(V_G @ May 16 2012, 02:55) *
А вы попробуйте какой-нибудь терминалкой принять файл 32 метра с другого компа через 2 адаптера USB-COM (или через две FT232). Получите опорное время, вокруг которого можно будет прыгать

Да вот и не факт, что получите, оказывается! Я вот сталкивался с ситуациями, когда передача идет в одну сторону на скорости порядка 2Мбит/сек (от камеры). И винда такой поток прекрасно "переваривает". Именно через FT232! А вот когда нужно часто переключаться с приема на передачу - скорость падает до 18 пакетов в секунду, не зависимо от их размера. Опять же из опыта... laughing.gif
V_G
Так у топикстартера и есть двусторонний обмен, хоть и несимметричный: 1 байт запроса - 512 байт ответа. Протокол передачи файла вроде как (не знаю точно) более симметричен, т.е. предполагает больший поток запросных и проверочных байтов. Но все-таки будет какая-то опорная цифра, не зависящая от аппаратуры и программы топикстартера. Боюсь, потребные ТС 167 сек на 32 Мбайта по компорту (даже виртуальному) - это фантастика.

PS. Там еще какие-нить таймауты в дровах или в FT232 надо подкручивать, ведь по USB идут свои пачки и на гораздо более высокой скорости. Оптимально и размеры пачек COM и USB надо тоже как-то согласовывать.
AHTOXA
Я может, что-то не понял, но при чём тут винда вообще? Задержки-то в передаче у меги?
Цитата(zombi @ May 16 2012, 02:51) *
RXD и TXD наблюдаю осциллографом.
Сразу после передачи писишкой байта 0x40 иксмега передаёт в ответ 512 байт затем пауза примерно 17ms и цикл повторяется.

V_G
Нет, как раз пауза 17 мс может быть вызвана как тормозами винды, так и таймаутом заполнения буфера USB в FT232. Если знать точно размер этого буфера и подогнать размер пакета UART под него, ожидания таймаута не будет. То же самое с запросным байтом, надо как-то сразу после его помещения в буфер, без таймаутов, инициировать передачу по USB.
dimka76
Цитата(V_G @ May 16 2012, 04:07) *
....... Боюсь, потребные ТС 167 сек на 32 Мбайта по компорту (даже виртуальному) - это фантастика.


Не фантастика сам лично через виртуальный COM порт загонял в компьютер 1 ГБайт за 90 секунд wink.gif
zombi
УРА! Нашел эту самую злополучную задержку!
В доп. настройках ком порта FTDI.
В параметре "Время ожидания (мсек)" стояло именно 17!
Поставил 1 и задержка действительно стала 1мс, правда иногда скачет до 2-х мс, но это видать винда чудит.
В результате удалось получить скорость приёма ~278сек. Далеко от идеала но всёже лучше чем не 1310с biggrin.gif
Кстати, уменьшение параметра "Буфер приёма/передачи (Байты)" с 4096 до 512 не даёт ни какого эффекта.

Сейчас думаю как ещё уменьшить время приёма.
1. Увеличить скорость до 3Mb/s - эффект предсказуем.
2. Увеличить размер передаваемой пачки до 1024,2048 или 4096 байт.

Как думаете существенно ли повлияет увеличение размера буфера на время передачи?
Т.к. изменение буфера довольно кропотливый процесс и не хочется зря время тратить.

Цитата(dimka76 @ May 16 2012, 08:04) *
Не фантастика сам лично через виртуальный COM порт загонял в компьютер 1 ГБайт за 90 секунд wink.gif

Как же это возможно? Ведь скрость должна быть ~120Mb/s!
V_G
Цитата(zombi @ May 16 2012, 16:27) *
Кстати, уменьшение параметра "Буфер приёма/передачи (Байты)" с 4096 до 512 не даёт ни какого эффекта.

У вас в одну сторону буфер должен быть 512 байт, а в другую - 1 байт. Возможно, сейчас тормозит именно передающая команды сторона
zombi
Цитата(V_G @ May 16 2012, 08:37) *
У вас в одну сторону буфер должен быть 512 байт, а в другую - 1 байт. Возможно, сейчас тормозит именно передающая команды сторона

Дык, гадюка, буфер меньше 64 байт ни на прём ни на передачу поставить не даёт!
Но даже если ставлю буфер передачи 64 байта, эффекта никакого.
И потом, приём в ПК это всего лишь один из режимов. Позже нужно будет и обратно 32МБ гнать.
Как размеры буферов менять на лету?
Я бы лучше "Время ожидания (мсек)" поставил в 0 но меньше 1 тоже не даёт.
XVR
Вы когда отправляете запрос с ПС на МК пишете 1 байт в FT. Драйвер FT берет байт и ждет, пока вы еще что нибудь в него запишите. Не дождавшись - отправляет этот 1 байт, и только потом МК начинает гнать ответ. Вот это время ожидания и есть "Время ожидания (мсек)". Попробуйте подключиться к FT через его родной интерфейс (из .dll), там может быть функция принудительной отправки буфера.
zombi
Цитата(XVR @ May 16 2012, 08:51) *
Вы когда отправляете запрос с ПС на МК пишете 1 байт в FT. Драйвер FT берет байт и ждет, пока вы еще что нибудь в него запишите. Не дождавшись - отправляет этот 1 байт, и только потом МК начинает гнать ответ. Вот это время ожидания и есть "Время ожидания (мсек)".
Оооо Спасибо!!! Теперь становится понятно что к чему.
Цитата(XVR @ May 16 2012, 08:51) *
Попробуйте подключиться к FT через его родной интерфейс (из .dll), там может быть функция принудительной отправки буфера.
А где искать эту .dll и описание её функций?
XVR
Цитата(zombi @ May 16 2012, 10:13) *
А где искать эту .dll и описание её функций?

тут и тут
zombi
Цитата(XVR @ May 16 2012, 09:28) *

OK. beer.gif
XVR
Еще тут посмотрите
zombi
Цитата(XVR @ May 16 2012, 09:28) *
Цитата(XVR @ May 16 2012, 09:48) *
Еще тут посмотрите

Шото не нашёл функции принудительной выдачи буфера crying.gif
V_G
Как вариант, настроить буфер на 64 байта и плюнуть туда 64 байта.
А проц пусть обрабатывает первый, а остальные игнорирует. На будущее и они пригодятся
zombi
Цитата(V_G @ May 16 2012, 10:07) *
Как вариант, настроить буфер на 64 байта и плюнуть туда 64 байта.

Ну да, 64 байта уйдут то быстрее чем 1 мс, а если позже нужно будет увеличить выходной буфер как это сделать на лету?
dimka76
Цитата(zombi @ May 16 2012, 08:27) *
Как же это возможно? Ведь скрость должна быть ~120Mb/s!


Вертуальный СОМ порт это мост USB<->UART.
Т.е. с одной стороны у вас ножки USB, а стругой - ножки UART.
Эта кортинка справедлива только если вы реально что-то выдаете на ножки UART. И в этой картинке (окне) вы задаете с какой скоростью будут идти данные на ножках UART.
И значение этой скорости передается в микросхему в дескрипторах USB.
Если использовать аппаратный мост (типа FT232) то получается, что не возможно выйти за рамки этих настроек.
Если виртуальный СОМ порт реализовать на микроконтроллере, то эти настройки (передаваемые в дескрипторах) можно проигнорировать и сделать все по-своему.
У меня так и было сделано. А данные гнались из внутреннего ОЗУ микроконтроллера по HIGH-SPEED USB.
zombi
Цитата(dimka76 @ May 16 2012, 12:06) *
Если виртуальный СОМ порт реализовать на микроконтроллере, то эти настройки (передаваемые в дескрипторах) можно проигнорировать и сделать все по-своему.
У меня так и было сделано. А данные гнались из внутреннего ОЗУ микроконтроллера по HIGH-SPEED USB.
Аааа, ну тогда конечно. А мне приходится с мс FT232R бороться.


Цитата(zombi @ May 16 2012, 08:27) *
1. Увеличить скорость до 3Mb/s - эффект предсказуем.

Кажется я поторопился с предсказуемостью biggrin.gif
Если устанавливаю скорость больше чем 2Mb/s то, ниче не работает crying.gif
Токи комп не понимает толи проц чегото не успевает laughing.gif
XVR
Цитата(zombi @ May 16 2012, 11:07) *
Шото не нашёл функции принудительной выдачи буфера crying.gif

Я тоже, но там есть функции Purge,Clear и EventSymbol в настройках. Возможно что то из этого может помочь. Еще там есть настройки таймаутов для read/write (отдельно). Тоже может помочь (если в 0 выкрутить). Еще там есть возможность принудительно отправить пакет от FT к PC (если изменить состояние любой из управляющих ног на RS232 стороне FT), к сожалению не описанна возможность принудительно отправить что либо в обратную сторону crying.gif
zombi
Цитата(XVR @ May 16 2012, 12:53) *
Я тоже, но там есть функции Purge,Clear и EventSymbol в настройках. Возможно что то из этого может помочь. Еще там есть настройки таймаутов для read/write (отдельно).
FTшные функции которые хоть както могут влиять на буфер практически такие же как обычные WINIP.
WINIPшные все перепробывал, безрезультатно.
Таймауты как только не крутил всё в пустую.

ReAl
Цитата(zombi @ May 16 2012, 08:27) *
Поставил 1 и задержка действительно стала 1мс, правда иногда скачет до 2-х мс, но это видать винда чудит.
Я делал пакетный протокол (в рамке SLIP, которой и Wake пользуется), так установкой EventChar на символ разделителя пакетов обошёлся, не хуже было точно.
Если FTDI-шному драйверу виртуального COM-порта задать EventChar, то не только поток программы в Win не дёргается по каждому байту и спокойно спит, пока в буфере драйвера не появится этот символ, но в при передаче драйвер, и при приёме сама микросхема FTDI отправляет недозаполненный буфер по приходу этого символа.
Дело было давно с FT232BM, точных времён не помню, но я в дальнейшем даже не трогал в настройках те 16 мс по умолчанию.
Без прописывания EventChar все те милисекунды, которые должны быть.

Цитата(zombi @ May 16 2012, 12:48) *
Кажется я поторопился с предсказуемостью biggrin.gif
Если устанавливаю скорость больше чем 2Mb/s то, ниче не работает crying.gif
Токи комп не понимает толи проц чегото не успевает laughing.gif
Года три назад — та же FT232BM, завалявшаяся в столе + Cyclone EP1C3.
По ТЗ на мой кусок был UART 2 Mbps (и не от компа), но я c заглушкой в альтерине, которая принятый байт тут же отдаёт в UART на передачу (заменяя по дороге '?' на '!') гонял и на 3 MBps.
zombi
Цитата(ReAl @ May 16 2012, 13:34) *
...установкой EventChar на символ разделителя пакетов обошёлся
Но у меня и на приём и на передачу могут быть любые байты 0..FF как использовать EventChar ?

Уже 10 лет чип на рынке и неужели ни укого не возникло необходимости начать передачу не полностью заполненного буфера?
Неужели разработчики не заложили такую возможность? или заложили но почемуто скрывают?
А может всё на столько элементарно что об этом никто не упоминает?
Пол для в гугле искал хоть что то подобное, но ничего не нашел.
КАПЕЦ! wacko.gif
ReAl
Цитата(zombi @ May 16 2012, 21:01) *
Но у меня и на приём и на передачу могут быть любые байты 0..FF как использовать EventChar ?
Пакетная передача с byte-stuffing. Выделенный байт используется для отмашки границ пакета и при наличии в сообщении подменяется парой других байт.
В данном конкретном случае использовалась рамка SLIP (почти эта подстановка используется в Wake, но в спецификации от Леонида Ивановича байт FEND не передаётся в конце пакета, что делает бессмысленной установку его как EventChar).

Есть ещё COBS.
SLIP в катастрофически неудачном случае может удвоить длину пакета, у COBS удлиннение максимум байт на пакет (при пакетах короче 254 байт).
SLIP мне когда-то был навязан необходимостью работы с радиомодемом, после чего исходники копировались в несколько других проектов. Про COBS узнал позже и пока не было куда приткнуть.



Цитата(zombi @ May 16 2012, 21:01) *
Уже 10 лет чип на рынке и неужели ни укого не возникло необходимости начать передачу не полностью заполненного буфера?
Неужели разработчики не заложили такую возможность? или заложили но почемуто скрывают?
У FT2232D на каждом канале есть нога SI/WU - SendImmediate/WakeUp
То, что надо. Но это побольше байда, чем FT232R
Никогда не пользовался, мне EventChar хватало. Причём он был еще для обычного RS232 использован и там тоже был полезен, а с переходом на FT232/FT245 так просто дополнительній бонус получился.
zombi
Аглицкий со словарём и то со скрипом.
Цитата(ReAl @ May 16 2012, 22:49) *
Пакетная передача с byte-stuffing. Выделенный байт используется для отмашки границ пакета и при наличии в сообщении подменяется парой других байт.
А что делать если в сообщении уже есть такая пара байт?
Или оную нужно определить и сообщить принимающей стороне?

ЗЫ. Ага всё сам нашел. всё понятно. Спасибо ReAl, буду пробывать.
Цитата
Он использует специальные символы для ограничения кадра данных в последовательном канале. SLIP определяет следующие два символа, служащие для этой цели: End и Esc. Символом End служит символ с кодом ASCII 192 (ОхСО), символом Esc - символ с кодом 219 (OxDB). Компьютер с протоколом SLIP передает символ End в конце каждого пакета данных. Символ Esc используется для обозначения данных, имеющих тот же номер, что и символы Esc и End внутри пакета данных. В том, что для Esc и End выбрали именно указанные коды, нет особого скрытого смысла. Просто они были выбраны, и все. Поэтому почти наверняка в потоке данных пользователя будут встречаться как символы Esc, так и End. Когда это происходит, SLIP использует Esc, чтобы сообщить приемнику, что следующий символ с кодом End на самом деле не является концом кадра. Например, когда в пакете данных попадается байт с номером ОхСО (код символа End), SLIP подставляет двухбайтную Esc-последовательность Esc OxDC. Если байт имеет код самого символа Esc, SLIP вставляет двухбайтную Esc-последовательность Esc OxDD.

ЗЫ.ЗЫ. Обидно только что придётся заниматься паковкой/распаковкой блоков , тратить на это ресурсы мк и всё только потому что FTDIшники поленились реализовать функцию принудительной выгрузки буфера или хотябы сделать задержку меньше 1мс maniac.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.