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 так просто дополнительній бонус получился.

[zombi]

Аглицкий со словарём и то со скрипом.

Пакетная передача с 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мс