У меня есть проект с использованием FTDI FT201X в качестве ведомого устройства USB для i2c, а ведущим устройством i2c является микроконтроллер AVR. Я использую WPF Core 3.1 C # на компьютере с Windows 10. В принципе, все с микросхемой FTDI работает нормально, за исключением того, что я не могу успешно получить данные, отправленные с ПК на микросхему FTDI, что бы я ни пытался. Функция записи D2XX сообщает, что она была успешной и не возвращает ошибок, но когда я пытаюсь прочитать, в буфере никогда нет данных.
С тех пор я написал небольшую тестовую программу, пытаясь изолировать проблему, но проблема остается. В основном, когда нажимается кнопка, мы открываем устройство по серийному номеру, мы записываем команду в буферы устройства, связываемся с AVR, чтобы дать ему знать о чтении, а затем ждем, пока AVR установит низкий уровень на контакте квитирования, что означает, что он получил данные.
public class USBLibrary
{
byte targetDeviceCount = 0;
FTDI.FT_STATUS ftStatus = FTDI.FT_STATUS.FT_OK;
public FTDI connectedUSBDevice;
// Called from button click event
public void ConnectUSB()
{
bool isOK = true;
byte numOfBytes = 1;
uint bytesWritten = 0;
bool usbInPinIsHigh = false; // Tracks USB In Pin
byte lowMask = 0b00010000; // CBUS 0 is output (4-7), all pins low (0-3) (Default Setting)
byte highMask = 0b00010001; // CBUS 0 is output (4-7), CBUS 3 is high
byte inPinMask = 0b00001000; // AND with pin states to get input pin value (Bus3)
byte pinStates = 0; // Used to get the current pin values
double timeout = 0;
// Create new instance of the FTDI device class
connectedUSBDevice = new FTDI();
// Determine the number of FTDI devices connected to the machine
ftStatus = connectedUSBDevice.OpenBySerialNumber("P00001");
/*** Write to Device ***/
byte[] firmwareCmd = new byte[numOfBytes];
firmwareCmd[0] = 128; // 128 is Get Firmware Command
// firmwareCmd[1] = 61; // Just Testing
// Write Firmware Command to Tx buffer
ftStatus = connectedUSBDevice.Write(firmwareCmd, numOfBytes, ref bytesWritten);
Trace.WriteLine(bytesWritten);
// Handshake with Device
isOK = DeviceHandshake(lowMask, highMask, inPinMask);
// Check if handshake failed
if (isOK == false)
{
return;
}
Task.Delay(10);
// Wait until message is sent
while ((usbInPinIsHigh == false) && (timeout <= 1000))
{
Task.Delay(1);
// Check for USB In pin to go high. Signals FW transfer is complete and to retrieve.
ftStatus = connectedUSBDevice.GetPinStates(ref pinStates);
// Is input pin high or low?
if ((pinStates & inPinMask) == inPinMask) // In pin high
{
usbInPinIsHigh = true; // Means uC finished sending data
}
timeout++;
}
// TEST: displays timeout amount for testing
Trace.WriteLine("Timeout=" + timeout);
ftStatus = connectedUSBDevice.Close();
}
}
ПРИМЕЧАНИЕ. Для этого кода я вырезал много кода проверки ошибок для ясности. Кроме того, код квитирования не показан, потому что он не должен иметь отношения: поднять выходной контакт, ожидать, что AVR поднимет выходной контакт, опустить выходной контакт, прослушать AVR, чтобы снизить выходной контакт.
На стороне AVR мы просто запрашиваем высокий уровень на выводе FT201X, а затем подтверждаем соединение с чипом. Потом просто читаем. Функция чтения всегда возвращает 0.
Я сомневаюсь, что проблема связана с i2c, поскольку есть 3 микросхемы IO Expander, управляющие светодиодами и кнопками, и мы можем читать и писать в них нормально. Кроме того, микросхема FT имеет функцию под названием Get USB State, где вы можете проверить состояние устройства, отправив команду и прочитав результат через i2c. Когда я это делаю, я всегда получаю правильное состояние 0x03 Configured. Так что мы можем читать с чипа через i2c.
Также есть функция, которая возвращает количество байтов в буфере, ожидающем чтения ... когда я это делаю, всегда отображается 0 байтов.
И на всякий случай заменил чип на новый, если он был плохим, и мы снова получили те же результаты.
Есть ли что-то, что мне не хватает в плане настройки чипа помимо использования FT_Prog, например, процедура инициализации или установка регистров или что-то в этом роде? Или мне нужно как-то протолкнуть записываемый мной байт в начало очереди или что-то еще, прежде чем его можно будет прочитать? Кто-нибудь видел что-нибудь подобное раньше?
Учитывая, что я не повлиял на результаты, мне либо не хватает ключевой части процесса, либо что-то не так с их драйвером / версией чипа. Прошло 3 недели, у меня закончились идеи, и мои волосы покрыты пятнами из-за выпадения больших кусков. Пожалуйста, спаси мои волосы.