XMega - FT232RL - PS Опции

[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]

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

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

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

Не фантастика сам лично через виртуальный COM порт загонял в компьютер 1 ГБайт за 90 секунд

Как же это возможно? Ведь скрость должна быть ~120Mb/s!

Эскизы прикрепленных изображений

 

[ReAl]

Поставил 1 и задержка действительно стала 1мс, правда иногда скачет до 2-х мс, но это видать винда чудит.

Я делал пакетный протокол (в рамке SLIP, которой и Wake пользуется), так установкой EventChar на символ разделителя пакетов обошёлся, не хуже было точно.
Если FTDI-шному драйверу виртуального COM-порта задать EventChar, то не только поток программы в Win не дёргается по каждому байту и спокойно спит, пока в буфере драйвера не появится этот символ, но в при передаче драйвер, и при приёме сама микросхема FTDI отправляет недозаполненный буфер по приходу этого символа.
Дело было давно с FT232BM, точных времён не помню, но я в дальнейшем даже не трогал в настройках те 16 мс по умолчанию.
Без прописывания EventChar все те милисекунды, которые должны быть.

Кажется я поторопился с предсказуемостью
Если устанавливаю скорость больше чем 2Mb/s то, ниче не работает
Токи комп не понимает толи проц чегото не успевает

Года три назад — та же FT232BM, завалявшаяся в столе + Cyclone EP1C3.
По ТЗ на мой кусок был UART 2 Mbps (и не от компа), но я c заглушкой в альтерине, которая принятый байт тут же отдаёт в UART на передачу (заменяя по дороге '?' на '!') гонял и на 3 MBps.

[zombi]

...установкой EventChar на символ разделителя пакетов обошёлся

Но у меня и на приём и на передачу могут быть любые байты 0..FF как использовать EventChar ?

Уже 10 лет чип на рынке и неужели ни укого не возникло необходимости начать передачу не полностью заполненного буфера?
Неужели разработчики не заложили такую возможность? или заложили но почемуто скрывают?
А может всё на столько элементарно что об этом никто не упоминает?
Пол для в гугле искал хоть что то подобное, но ничего не нашел.
КАПЕЦ!

[ReAl]

Но у меня и на приём и на передачу могут быть любые байты 0..FF как использовать EventChar ?

Пакетная передача с byte-stuffing. Выделенный байт используется для отмашки границ пакета и при наличии в сообщении подменяется парой других байт.
В данном конкретном случае использовалась рамка SLIP (почти эта подстановка используется в Wake, но в спецификации от Леонида Ивановича байт FEND не передаётся в конце пакета, что делает бессмысленной установку его как EventChar).

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

Уже 10 лет чип на рынке и неужели ни укого не возникло необходимости начать передачу не полностью заполненного буфера?
Неужели разработчики не заложили такую возможность? или заложили но почемуто скрывают?

У FT2232D на каждом канале есть нога SI/WU - SendImmediate/WakeUp
То, что надо. Но это побольше байда, чем FT232R
Никогда не пользовался, мне EventChar хватало. Причём он был еще для обычного RS232 использован и там тоже был полезен, а с переходом на FT232/FT245 так просто дополнительній бонус получился.