реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
BSACPLD
сообщение Jan 28 2015, 10:39
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 371
Регистрация: 24-07-05
Из: Москва
Пользователь №: 7 056



Пишу кроссплатформенную программу на Qt.
Столкнулся с весьма необычным поведением FTDI под Linux.
При частом обращении к FTDI иногда не срабатывает функция FT_Write.
Функция для настройки FTDI:
CODE
bool MainWindow::OpenPort(int nPort, bool msgbox)
{
if(ftPort != 0)
{
FT_Purge(ftPort, FT_PURGE_RX | FT_PURGE_TX);
FT_Close(ftPort);

ftPort = 0;
}

if(FT_Open(nDevIndex[nPort], &ftPort) != FT_OK)
{
ftPort = 0;

if(msgbox)
QMessageBox::critical(0, "Ошибка!", "Ошибка при открытии USB порта.");

return false;
}

FT_ResetDevice(ftPort);

FT_SetBitMode(ftPort, 0, FT_BITMODE_RESET);
FT_SetDtr(ftPort);
FT_SetRts(ftPort);
FT_Purge(ftPort, FT_PURGE_RX | FT_PURGE_TX);
FT_SetUSBParameters(ftPort, 65535, 0);
FT_SetTimeouts(ftPort, TIMEOUT + 10, TIMEOUT + 10);
FT_SetLatencyTimer(ftPort, 1);
FT_SetDivisor(ftPort, FTDIVISOR);
FT_SetDataCharacteristics(ftPort, FT_BITS_8, FT_STOP_BITS_1, FT_PARITY_NONE);
FT_SetFlowControl(ftPort, FT_FLOW_NONE, NULL, NULL);

FT_Purge(ftPort, FT_PURGE_RX | FT_PURGE_TX);

return true;
}

Код для записи в FTDI:
Код
nb = 0;
ftStatus = FT_Write(*ftPort, ft_data, i, &nb);
if(ftStatus != FT_OK)
{
    emit ft_msg("ftStatus FT_Write() != FT_OK");
    continue;
}
if(i != ((uint32_t)nb))
{
    char st[256];
    sprintf(st, "Ошибка при записи данных.\nЗаписано %u bytes, передано %u bytes.", i, ((uint32_t)nb));
    emit ft_msg(st);
    continue;
}

Причём при возникновении ошибки функция всегда возвращает ftStatus == FT_OK и nb == 0.
На Windows (XP x32, Win7 x64) такая ошибка не возникает никогда.
Пробовал разные версии Linux.
На Red Hat вываливается раз в пол минуты.
На Gentoo почти сразу.
На Debian запись работает нормально, а вот чтение всегда возвращает неправильные данные.
Драйвер самый последний с ftdichip.com.
Кто-нибудь сталкивался с подобной проблемой?
Go to the top of the page
 
+Quote Post
BSACPLD
сообщение Jan 28 2015, 17:11
Сообщение #2


Местный
***

Группа: Свой
Сообщений: 371
Регистрация: 24-07-05
Из: Москва
Пользователь №: 7 056



В общем удалось частично решить проблему.
Если не вызывать FT_SetUSBParameters и FT_SetLatencyTimer, то FT_Write перестаёт глючить.
Правда не везде.
На Red Hat работает стабильно.
На Debian всё равно иногда подглючивает.
Go to the top of the page
 
+Quote Post
SM
сообщение Jan 28 2015, 18:00
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881



Вообще, это признак таймаута, что данных передано меньше, чем хотелось, а ошибки нет. Так что, смотрите, что Вы там назадавали по этому поводу.
Go to the top of the page
 
+Quote Post
BSACPLD
сообщение Jan 28 2015, 18:06
Сообщение #4


Местный
***

Группа: Свой
Сообщений: 371
Регистрация: 24-07-05
Из: Москва
Пользователь №: 7 056



TIMEOUT = 1000
Неужели за 1 секунду не успевает передаться пакет размером 11 байт на скорости 125000?
Период посылки пакетов > 10 мс. Пока не придёт ответ на предыдущий пакет, программа не отсылает новый.
Go to the top of the page
 
+Quote Post
Timmy
сообщение Feb 1 2015, 11:16
Сообщение #5


Знающий
****

Группа: Участник
Сообщений: 835
Регистрация: 9-08-08
Из: Санкт-Петербург
Пользователь №: 39 515



Цитата(BSACPLD @ Jan 28 2015, 20:11) *
В общем удалось частично решить проблему.
Если не вызывать FT_SetUSBParameters и FT_SetLatencyTimer, то FT_Write перестаёт глючить.
Правда не везде.
На Red Hat работает стабильно.
На Debian всё равно иногда подглючивает.

Под виндой тоже наблюдается подобное. Было экспериментально установлено, что для стабильной работы при непрерывном чтении SPI потока через MPSSE на скорости 33мб/с требуется ставить LatencyTimer не менее примерно 10(точную цифру не помню), иначе данные чтения иногда теряются без сообщения об ошибке. По умолчанию LatencyTimer не менее 8, а вы его переставляли на 1. Возможно, для Debian нужно поставить ещё больше, чем для Red Hat sm.gif.
Go to the top of the page
 
+Quote Post
BSACPLD
сообщение Feb 2 2015, 13:07
Сообщение #6


Местный
***

Группа: Свой
Сообщений: 371
Регистрация: 24-07-05
Из: Москва
Пользователь №: 7 056



Цитата(Timmy @ Feb 1 2015, 15:16) *
Под виндой тоже наблюдается подобное. Было экспериментально установлено, что для стабильной работы при непрерывном чтении SPI потока через MPSSE на скорости 33мб/с требуется ставить LatencyTimer не менее примерно 10(точную цифру не помню), иначе данные чтения иногда теряются без сообщения об ошибке. По умолчанию LatencyTimer не менее 8, а вы его переставляли на 1. Возможно, для Debian нужно поставить ещё больше, чем для Red Hat sm.gif.

Что интересно, такое поведение наблюдается только под VirtualBox.
На живой машине работает стабильно.
Насколько я помню, LatencyTimer по умолчанию вроде равен 16.
Похоже, правильнее всего будет сделать отдельный пункт в меню для настройки LatencyTimer.
Если VirtualBox, то ставить побольше, если живая система, то поменьше sm.gif.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 29th June 2025 - 21:40
Рейтинг@Mail.ru


Страница сгенерированна за 0.01381 секунд с 7
ELECTRONIX ©2004-2016