Perché FTDI e non AVR con controller USB integrato?

Ho creato un semplice programma in Visual C # che comunica con AVR tramite il chip FT232RL.

PC <-> FTDI <-> MCU.

Sto usando FTD2XX_NET.dll per l'accesso diretto al dispositivo USB.

Mi chiedo, qual è la differenza tra una coppia di FTDI-AVR e un singolo AVR con controller USB integrato? Penso che ci debba essere qualche differenza nella velocità di comunicazione. Cos'altro è diverso?

Ci sono alcune ragioni, ma sono, almeno per la maggior parte delle persone, abbastanza di nicchia.

I motivi che vedo e ho vissuto

• La scelta di AVR abilitati USB è piuttosto limitata, in particolare la famiglia TINY. Se per qualche motivo è richiesto un AVR che non ha una combinazione di USB e qualche altra periferica, questa è un'opzione facile. Un esempio che viene in mente sono gli AVR abilitati per PLL.
• Anche se la periferica USB è implementata nell'hardware, è comunque necessario inserire uno stack USB nel firmware. Questo richiede molte risorse (ad es. LUFA richiede almeno 6kB di flash e 1,5kB di RAM per un'implementazione CDC completa, e questa è una delle librerie più leggere)
• Gli interrupt USB e gli eventi del bus USB occupano risorse che possono interferire con il firmware critico per i tempi. Ad esempio: le misurazioni ADC ad alta velocità possono incasinarsi molto gravemente quando un'attività USB si interrompe.
• Non tutte le implementazioni di librerie USB funzionano anche con tutti gli AVR abilitati USB. Ad esempio: i bootloader USB che utilizzano LUFA non funzionano con i dispositivi XMEGA.
• FTDI utilizza driver firmati che si installano automaticamente tramite Windows Update, mentre molte librerie USB, ad esempio ASF e LUFA, non lo fanno. Ciò rende più ingombrante la distribuzione agli utenti finali.
• Alcune implementazioni hanno prestazioni inferiori, ad esempio FT2232H è in grado di collegare un FIFO a USB a 8 MiB / s, cosa impossibile con un AVR.
• Molti progetti non hanno il pieno controllo su hardware e software, ad esempio le stampanti 3D hanno progetti hardware e firmware completamente separati. Al fine di mantenere il livello di interoperabilità il più alto possibile, le funzioni USB e microcontrollore sono separate.

Tuttavia, con le librerie USB pronte per l'uso, il costo significativo dei bridge USB FTDI (di solito costano di più anche degli AVR di fascia molto alta) e nessuna penalità di prestazione nella maggior parte delle applicazioni, è molto difficile giustificare i chip FTDI al giorno d'oggi se si avere il pieno controllo su hardware e firmware.

Ci sono vantaggi nell'usare un chip USB separato e nel far comunicare l'AVR tramite il suo UART.

Uno stack USB deve rispondere al polling dal PC host. Questo succede almeno ogni millisecondo. Ciò significa che è ancora più difficile garantire una risposta dura in tempo reale agli eventi, poiché l'MCU potrebbe essere interrotta per rispondere al sondaggio USB degli host.

Quando non c'è nulla da comunicare o l'MCU vuole concentrarsi completamente su un'attività in tempo reale, deve comunque rispondere ad alcuni eventi di polling USB dell'host, altrimenti l'host "perderà" il dispositivo. Quindi è difficile ignorarlo. Un chip USB dedicato, come un FTDI, scarica tali compiti dall'AVR.

Un piccolo problema è che lo stack USB consumerà una quantità ragionevole di memoria flash e RAM, quindi il chip ha bisogno di più risorse di un semplice AVR.

Inoltre, le due parti possono essere separate su due schede, quindi l'USB non è un costo fisso, ma potrebbe essere condiviso su più schede.

D'altro canto, il vantaggio principale dell'utilizzo di un AVR con una periferica USB integrata e uno stack USB è che c'è solo una parte da acquistare e assemblare.

Non ho verificato di recente, ma credo che i chip FTDI più recenti abbiano fornito una velocità di trasferimento dati USB superiore rispetto a quella dell'AVR. Tuttavia, gli UART AVR erano così lenti che un AVR con USB è un trasferimento più veloce della combinazione di FTDI (o qualsiasi interfaccia USB) che comunica tramite l'UART dell'AVR a causa del lento UART AVR.

Modifica: FTDI crea interfacce diverse da UART. Ad esempio SPI. Non ho esperienza con loro. Alcuni AVR supportano il trasferimento SPI da 9 (forse 12) megabit. FTDI è il master SPI, che non è l'ideale. Se l'AVR sta trasmettendo, potrebbe andare bene, visto che gli FTDI hanno dei buffer, ma ricevere potrebbe essere "come bere da una manichetta antincendio". AFAIK, dovrai fare un lavoro sul PC host per farlo funzionare.

Il trasferimento ad alta velocità potrebbe avvenire tramite una scheda figlia Ethernet da 100 MB, ma non ho visto le misurazioni della velocità effettiva.

Sono felice di usare altri microcontrollori diversi dall'AVR. Quindi potrei usare qualcosa con un UART veloce e un controller DMA che potrebbe spostare i personaggi senza il coinvolgimento della CPU. Se questo è un approccio utile, forse guardate l'Arduino Due, o il mbed, il mbed ST si chiama nucelo che è a basso costo.