FTDIchip er FT2232 USB til SPI converter: grunnleggende spørsmålet

[vandelay]

Jeg bruker en FT2232 chip å gi en SPI interface via USB. Når du leser opp på forutsatt SPI.dll dokumentasjon, ble jeg overrasket over å finne de to funksjonene SPI_Read og SPI_Write. Siden SPI er en full dupleks overføring, hvordan kan det være at det er separate lese og skrive funksjoner gitt? Kan det være at (siden USB kommuniserer i pakker), er kommandoen sendt til SPI på skrive og samtidig mottatte data dumpet, så forventet respons data (et gitt nr byte som skal leses) leses ved å skrive dummy data på samme størrelse, overføre hele buffer tilbake i en enkelt USB-pakke? Det ville være fornuftig som data kan overføres mye raskere enn USB, men i mitt tilfelle (lesing svært få respons byte av gangen, mange kommandoer til mange SPI slaver) Jeg sitter igjen med mye mindre effektiv båndbredde enn det FT2232 dataarket først dukket opp å indikere .. Jeg leste den kunne gjøre 6MHz SPI (IIRC), men jeg begynner å mistenke at det er en klokke nummer jeg kan ikke basere min båndbredde regnestykket på .. Enhver avklaring på dette ville være flott ..

 

[coros]

Det er sant at det å sende noen bytes over USB er veldig treg. Jeg vet ikke funksjonene i spi.dll, fordi jeg bruker FT2232 med linux, men jeg har skrevet min egen SPI funksjoner for programmering avr opp med denne brikken. I begynnelsen sendte jeg og fikk hver 4 byte med separat FT_write og FT_read kommandoer, og det var veldig treg. Programmering av 32KB flash tok ca 5 minutter!. Så jeg laget en bufret skriver og leser: skriv alle data inn i en buffer, og deretter sende hele bufferen med én FT_write. Økningen i hastighet var enorm - programmering nå tok ca 3 fettsyrer. Og det er mulig å lese og skrive data samtidig, fordi dataene lagres i en buffer, som kan leses med en FT_read kommandoen etter at overføringen er fullført. USB har blitt utviklet for å sende pakker med data ikke enkelt byte. En pakke består av 64 data. Hvis du skriver mindre data, så kontrolleren venter en bestemt tid - typisk 16 ms (for øvrig), og kun etter at tiden har gått sender data. Tiden kan endres med FT_SetLatencyTimer. Så sende noen bytes en av gangen er veldig treg - enda mindre enn 1kbBs. Hilsen

 

[vandelay]

Enn mye for å dele dine erfaringer, Coros. Jeg skal bare revidere min krets med en ekstra MCU innsamling av data, sender alt tilbake over USB, bufret i én pakke. Et spørsmål, jeg trenger bare å samle 24 bytes .. burde jeg kanskje programmere MCU å svare med 64 bytes hvorav 40 bytes er dummy, for å unngå latency problemet?

 

[coros]

Du kan også skrive egendefinerte funksjoner for å lese og skrive som jeg gjorde. Så jeg tror det er ikke nødvendig å bruke ekstra MCU. Da jeg skrev den avr programmig først jeg likte dette - svært langsom versjon: For å lese en byte fra blitsen på avr jeg trenger å sende tre bytes kommandoen da jeg leste en byte respons, så jeg brukte FT_write med 3 byte kommandoen for AVR, så med FT_read fikk jeg en byte. Det var treg. Nå bufrede versjonen: for eksempel ønsker jeg å lese 256 byte fra avr (overføringen til avr er fortsatt 3 bytes kommando og adresse og en byte respons). Det jeg trenger å sende til FT2232: 0x11, 0x02, 0x00, 3 bytes kommandoen for AVR, 0x20, 0x00, er 0x00 0x11 0x02 0x00 kommandoen for FT til å sende tre byte data, er 0x20 0x00 0x00 kommandoen for FT å lese én byte fra AVR. Så jeg sender 9 * 256 byte med ett FT_write, så leste jeg 256 byte med ett FT_read. Den diffrence er at jeg ikke leser en byte data umiddelbart etter sendig de 3 byte av kommandoen, så FT2232 lagrer den i sin interne buffer og sender den når den er full. Så jeg får alle 256 bytes med én FT_read. For mer beskrivelse lese MPSSE kommandoene beskrivelse på FTDI stedet.

 

[IamnotJunk]

hvorfor ikke bruke microchip USB-løsning? Det er demoer og programmer leste å gå.

 

[vandelay]

[Quote = IamnotJunk] hvorfor ikke bruke microchip USB-løsning? Det er demoer og programmer leste å gå. [/Quote] Fordi USB hastighet vil fortsatt være en flaskehals hvis sendingen individuelle bytes, og du blir nødt til å programmere din egen PC drivere. Personlig har jeg en FT2232 DIP modul, den kommer med drivere, DLL biblioteker, kildekode eksempler og driver dokumentasjon .. Enkelt valg for meg .. [Size = 2] [color = # 999999] Lagt etter 24 minutter: [/color] [/size] coros, emballasje alle data på en enkelt "side" er fortsatt veien å gå for meg tror jeg, og jeg vil forklare hvorfor: Dataene leses av en real-time-programmet på PC krever en oppdatering hvert 0,05 sekunder eller så (jeg vil variere med ulike oppdatere frekvenser). Én oppdatering trenger alle data, så ferske som mulig (sensor avlesninger). Ved å lese alle data inn i MCU og sende dem i en enkelt USB-pakke, tror jeg at jeg har den beste løsningen for min søknad. Dessuten har jeg allerede laget et styre med ombord MCU (dsPIC30F6012). Den bruker nå noen analoge sensorer også, så jeg vil bruke interrupt-drevet A / D-konvertering og IIR filter målingene, i tillegg til å gi en buffer for SPI sensorene jeg har programmert mye dsPIC i det siste og jeg har alt MCU kode jeg trenger innebygd i tidligere prosjekter jeg er alt bra, takk for tilbakemeldingen!

 

[Fruity]

Hei, jeg har faktisk et lignende spørsmål om FT2232 (jeg bruker FT2232H men prinsippet er det samme). Jeg prøver å bruke toveis funksjonen i SPI. Jeg ønsker å sende en byte via Mosi mens du mottar en byte via miso, så alle at i 8 SPI CLK. Jeg har søkt og søkte i flere timer, og kan ikke gjøre det arbeidet. Det er om alt var alltid halv dupleks. Forhåpentligvis noen på denne listen vil kunne hjelpe!

 

[andrepepino]

Hei folkens! Vel, jeg tenker å kjøpe en FT2232D for å kontrollere åtte lydkanaler, individualy, ved hjelp av SPI Protocol. USB -> FT2232D - CH1 -> AD8801 # 1 - CH1, CH2, CH3, CH4 -> Forsterkere | --- CH2 -> AD8801 # 2 - CH5, CH6, CH7, CH8 -> Forsterkere MEN, jeg ønsker å generere hver kanal signal, så min oppdateringshastighet trenger å bli fortere jeg kan! (Ca: 0,5 ms) Jeg trenger ikke å lese ingenting! Bare å sende data! Tror du det er mulig? Takk!