использование управления потоком FT232BM, помогите разобраться Опции

[showone]

устройство на контроллере подключается через FT232BM к USB.
задача периодически пополнять внутренний буфер контроллера.
контроллер управляет медленным устройством.

поэтому если кидать данные без управления потоком, они теряются.
если с управлением потока, то вроде все нормально. но иногда все же теряется 1-4 байта.

использую DSR-DTR

делаю так.
в микроконтроллере.

interrupt [USART_RXC] void usart_rx_isr(void)
{
char status;
DSR=1;
status=UCSRA;
rx_d=UDR;
rx_b=1;
//DSR=0;
}

main()
{
while(1)
{
if (rx_b)
{
rx_b=0;
get_ser();
}
}
}

void get_ser(void)
{
// обрабатываю полученный байт, заполнение буфера
delay_ms(500); // задержка, вроде как устройство занято. если эту задержку убрать, то вроде как работает, но с ней, байты теряются, из 20 посланных 1-2 теряются.
DSR=0;
}


на Delphi


procedure wait_tx;
begin
repeat
Get_USB_Device_ModemStatus;
Application.ProcessMessages;
until (FT_Modem_Status and $00000020) = $00000020;
end;


..........................



if Open_USB_Device<>FT_OK then begin exit; end;
Reset_USB_Device;
FT_Current_Baud:=FT_BAUD_38400;
Set_USB_Device_BaudRate;

FT_Current_FlowControl:=FT_FLOW_DTR_DSR;
FT_XON_Value:=0;
FT_XOFF_Value:=0;
if Set_USB_Device_FlowControl<>FT_OK then showmessage('Set_USB_Device_FlowControl');

Purge_USB_Device_Out;
Purge_USB_Device_IN;


...............

for i:=1 to n do
begin
for j:=0 to 100 do FT_Out_Buffer[j]:=mas[j];
wait_tx; // ждем разрешения DSR
Write_USB_Device_Buffer(100);
end;



т.е. я выдаю в порт по 100 байт.
как мне точно узнать что все 100 байт переданы и можно передавать следующие ?


пробовал передавать по одному байту, тоже теряются байты.


может есть где пример как правильно, или кто что может посоветует.
заранее спасибо.



==========================================================

ответ zltigo
Я все исходники написанные Вами не читал, но:
1. Контроллер после выставления им неготовности обязан принять как минимум один байт
2. Нарезка на байты/порции со стороны PC - побайтовая передача с flush после каждого байта/порции.

==========================================================




есть ли где информация как построен сам процес управления потоком?
а то велосипед изобретать как-то не очень получается :-)

или где можно почитать про это.

меня интересует. точнее нужно.

есть боьшой масив данных, его нужно передать в контроллер порциями (размером с буфер контроллера 100 байт)
причем контроллер может в любой момент замереть в ожидании события почти на две секунды.

так вот.
управление потоком немного облегчило жизнь, при использовании DTR DSR.
но программа на дельфи, которая выкидывает по 100 байт, не может толком понять, кидать ей следующие 100 байт или нет.

или лучше кидать по одному байту постоянно, и ждать пока он не дойдет до контроллера и контроллер не разрешит дальнейший обмен.
но тогда получается что это уже програмный контроль, а не аппаратный.

может есть гре пример нормальной работы или алгаритма работы.

заранее спасибо.

Сообщение отредактировал showone - May 11 2007, 11:39

[Александр Куличо...]

После DSR=0 :
- Стандартный UART com-порта PC выдает еще на выход 1 байт инфомации (заканчивает текущую передачу).
- FT232BM - выдает 2 байта (заканчивает текущую передачу + выдает еще 1 байт). Проверял только на скорости 19200.

В Делфи использую компонент ComPort Library by Dejan Crnila. Ставлю тайм - аут на передачу и пишу в ком-порт в асинхронном режиме. При необходимости можно использовать событие OnTxCompleate.

Сообщение отредактировал Александр Куличок - May 11 2007, 13:35

[SasaVitebsk]

После DSR=0 :
- Стандартный UART com-порта PC выдает еще на выход 1 байт инфомации (заканчивает текущую передачу).
- FT232BM - выдает 2 байта (заканчивает текущую передачу + выдает еще 1 байт). Проверял только на скорости 19200.

В Делфи использую компонент ComPort Library by Dejan Crnila. Ставлю тайм - аут на передачу и пишу в ком-порт в асинхронном режиме. При необходимости можно использовать событие OnTxCompleate.

Это не совсем верно.

1) Всё идёт от 16550. Там фифо буфер (у первых) 16 байт. Поэтому после приостановки потока может быть отправлено десяток и более байт.

Лично я не проверял сколько, но приостанавливаю когда буфер заполнен не до конца байт 16.

2) Приостанавливать надо (если использовать аппаратное управление компьютера) сигналом CTS

Код

RxU1:
    stsx    cbufe,X    ; и сохранить
    lds        wl,cbufbl; Определить объём свободного места
    lds        wh,cbufbh
    sub        wl,Xl    ; в буфере
    sbc        wh,Xh
    brcc    RxU2
    subi    wl,low(-lBuf); Откорректировать при перехлёсте
    sbci    wh,high(-lBuf); Откорректировать при перехлёсте
RxU2:
    tst        wh        ; Осталось меньше 16 байт?
    brne    RxUE    ; если нет, то выйти
    cpi        wl,16    ; Осталось меньше 16 байт?
    brsh    RxUE    ; если нет, то выйти

    sbi        portCTS,CTS; Сбросить готовность модема

3) В обратную сторону тоже надо проверять. Компьютер может снять готовность (и делает это) RTS.

Код

    sbis    pinRTS,RTS    ; если убран RTS
    rjmp    onl31

4) При программном управлении потоком (так называемым Xoff/Xon обмене) используется два знаменитых символа

Код

es22:    .db    17; XON
es23:    .db    19; XOFF

Естественно, что при программном управлении потока надо их убирать из потока. Поток также может оборваться не сразуже. Оно и понятно. Например при работе модема байт пять где-то бродят по проводам. Это я проверял лично.

Да и ещё на последок. Если используете HARD управление потоком, то позаботьтесь о выдаче готовности модема в линию, а то передача может и не начаться. Либо закольцуйте в вашем устройстве сигналы DSR/DTR.

Код

    cbi        portDSR,DSR; постоянно выдавать готовность модема
    cbi        portMR,MR; и подсвечивать её
    sbi        portDCD,DCD; сбросить сигнал DCD