Problema de retraso de bytes SPI consecutivos FT232HL FTDI

Por lo general, trabajo con el chip FT2232H, pero saqué un chip FT232HQ solo para poder verificar este problema que estaba teniendo. Es el mismo chip que el chip FT232HL que tiene, solo que en un paquete QFN en lugar de un QFP.

Intenté recrear el problema que describes, pero no pude hacerlo exactamente. Así es como se veía en mi analizador lógico cuando emitía 6 bytes a la vez a una velocidad de reloj de 5 MHz. Hay un pequeño retraso entre bytes, pero no tan grande como 64us.

Aquí hay algunas cosas para comprobar.

• El temporizador de latencia realmente no debería importar porque es simplemente un tiempo de espera antes de que el USB envíe un paquete incompleto. Lo tengo configurado en 255, pero a menudo para cosas sensibles al tiempo, lo tengo más bajo (2 -10)
• Pruebe primero con una velocidad de reloj más lenta solo para probar y asegurarse de que el dispositivo se esté comunicando correctamente (supongo que lo hizo, solo estoy agregando esto en caso de que alguien más no lo haya intentado todavía).
• Las direcciones de los pines no importan, excepto para GPIO, ya que la biblioteca SPI las sobrescribe.
• En lugar de p_SPI_Write(), use SPI_Write(). Si realiza una sola llamada, agregue el chip apropiado, seleccione las banderas de activación y desactivación (consulte a continuación). Si realiza varias llamadas, asegúrese de agregar las banderas de selección de chip a la primera y última llamada de la serie.
• Asegúrese de pasar el número de bytes para transmitir y establezca la SPI_TRANSFER_OPTIONS_SIZE_IN_BYTESbandera.
• Si se trata de un diseño de placa personalizado, o si compró una placa adaptadora FT232H con descuento, asegúrese de que tenga la frecuencia de reloj del sistema correcta. Ese retraso entre bytes se basa en cuánto tarda el chip en mover el siguiente byte desde su búfer interno a los registros de desplazamiento de salida. Si el reloj del chip es lento, esto se mostrará en las frecuencias más altas como una brecha más grande entre los bytes. Tenga en cuenta que para SPI no importa si el reloj se estira un poco aquí y allá, ya que se basa en los bordes de la señal del reloj (leer en un borde, propagarse en el otro). Pruebe el cristal o el chip de cristal CMOS y asegúrese de que esté recibiendo 12 MHz.

Aquí hay un código de ejemplo rápido sobre cómo enviar múltiples bytes de datos en caso de que ayude.

uint32 sizeToTransfer = 0;
uint32 sizeTransfered = -1;
uint8 buffer[256]; //Must be large enough for what you are sending.
FT_STATUS status;

//add data
buffer[sizeToTransfer++] = 0x20; //First data byte (can be what you need)
/*
 * More bytes added....
 */
buffer[sizeToTransfer++] = 0x00; //Last data byte (can be what you need)

status = SPI_Write(*handle, buffer, sizeToTransfer, &sizeTransfered,
    SPI_TRANSFER_OPTIONS_SIZE_IN_BYTES |
    SPI_TRANSFER_OPTIONS_CHIPSELECT_ENABLE |
    SPI_TRANSFER_OPTIONS_CHIPSELECT_DISABLE);

//Don't forget to check status. It should equal FT_OK if everything went well

Descargo de responsabilidad: utilizo el FT2232H y no estoy 100 % seguro de si todas las declaraciones se pueden transferir a este caso.

Que yo sepa, ftdi mpsse spi no está realmente optimizado para un alto rendimiento de datos. Esto se vuelve obvio si uno mira más de cerca la fuente. En la versión actual (revisada el 24.04.2019) hay una llamada INFRA_SLEEP(2) dentro de la función SPI_ToggleCS que provoca un retraso de 2 ms cada vez que cambia el estado de la línea CS. Entonces, si necesita pulsar CS para cada palabra, está condenado. Incluso sin la llamada de suspensión, la latencia USB probablemente ralentizará severamente las cosas. Incluso sin esta llamada, el rendimiento máximo cae por debajo de las expectativas durante mis pruebas. Supongo que la razón de esto es la arquitectura de mpsse en sí. Así que, personalmente, recomendaría seguir con los protocolos admitidos de forma nativa como UART, opto rápido o FIFO para aplicaciones de alto rendimiento si es posible.

Por curiosidad (si este caso aún está abierto): ¿comprobó también si había diferentes controladores? ¿Puedes observar el mismo comportamiento para una PC diferente también?

Detrás de cada llamada a libMPSSE hay una llamada a FT_Write() que en realidad escribe un marco de datos en un USB de alta velocidad. Al usar las funciones de la biblioteca, por lo tanto, está restringido por la capa de comunicación USB (según lo informado por el soporte de FTDI).

La solución para obtener la máxima velocidad es bajar el nivel y almacenar los comandos en un gran FT_Write() para que los datos se empaqueten en un marco de transmisión USB:

{
Add to buffer: GPIO Write for CS lo
Add to buffer: Clock N bytes command
Add to buffer: N bytes of data
Add to buffer: GPIO write for CS hi
Add to buffer: Send immediate command (0x87) – only if you read bytes from the LTC device, not if you only write them
++ Repeat for other commands as much as possible for your use-case …
}
FT_Write of the above buffer

Solo para hacerle saber que creo que los controladores FTDI FT232HL tienen errores porque los errores desaparecen/aparecen según el concentrador/marca USB que se usa y la longitud del cable USB y la forma en que la computadora está "preparada". Al final compré una computadora específica y me quedé con ella para la producción en masa.

Algunos ayudantes:

1. Tiempo de llamadaBeginPeriod(4); antes de cargar los controladores FTDI ayuda mucho, solo tiene que verificar después de que se configuró el período de tiempo porque a veces Windows no puede actualizar el período (por cualquier motivo). Consulte el siguiente código para verificar si timeBeginPeriod(4) funcionó.

   t1d=reloj(); BITBANG_usleep(5*1000);//5ms t2d=reloj(); tgastado=(((float)t2d-(float)t1d) / (CLOCKS_PER_SEC/1000)); if((int)tgastado > 8){ falló, ¡salga o vuelva a intentarlo! }

   void BITBANG_usleep(unsigned int usdelay) { clock_t t1,t2; if(usdelay<16*1000)//16ms {t1=reloj(); while(1){t2=reloj(); if(((t2-t1)/ (CLOCKS_PER_SEC/(1000)))>usdelay/1000){break;}}} else {usleep(usdelay);} }

2. Use un cable corto y eventualmente use un HUB USB en el camino, mejora en gran medida la estabilidad, puede funcionar directamente durante cientos de horas sin problemas.

Espero que ayude, no es la mejor solución, ¡pero funcionó para mí!