Forum: Mikrocontroller und Digitale Elektronik FTDI FT4232H - SPI_AddHiSpeedDeviceReadCmd(.) langsam


von Florian E. (Firma: keine) (fnet)


Lesenswert?

Hallo,

ich bearbeite ein FTDI MiniModule mit Ft4232.

Ich will die SPI -> USB Funktion benutzen.

Ich benutze mit Channel A die FTCSPI.dll von FTDI in C# ueber

 [DllImportAttribute("ftcspi.dll", CallingConvention = 
CallingConvention.Cdecl)]
    static extern uint SPI_AddHiSpeedDeviceReadCmd(IntPtr ftHandle, ref 
FTC_INIT_CONDITION pReadStartCondition, bool 
bClockOutControBitsMSBFirst, bool bClockOutControBitsPosEdge, uint 
numControlBitsToWrite, byte[] pWriteControlBuffer, uint 
numControlBytesToWrite, bool bClockInDataBitsMSBFirst, bool 
bClockInDataBitsPosEdge, uint numDataBitsToRead, ref 
FTH_HIGHER_OUTPUT_PINS pHighPinsReadActiveStates);

Parameter:

FtdiHighSpeedDevices[0].AddReadCommand(myFtHandle,
                                       ref ReadStartCondition,
                                       true,
                                       true,
                                       0,
                                       WriteControlBuffer,
                                       true,
                                       true,
                                       8,
                                       ref HighPinsReadActiveStates);

Ich kann bis zu 0x4000 Commands hinzufuegen.

Mehr Commands werden mit der Fehlermeldung 
FTC_COMMAND_SEQUENCE_BUFFER_FULL abgelehnt.

Problem: Die 0x4000 Commands hinzufuegen dauert ca. 600 ms.

Das SPI-lesen dauert dann 16 ms, hier setzt der Latency Timer vermutlich 
ein.

Ich will nur Daten von einem Atmel xmega lesen.
Daten werden fehlerfrei uebertragen.

Problem: Wie kann ich die Zeit zum hinzufuegen der Commands senken?

Danke,
Florian

von Christian R. (supachris)


Lesenswert?

Kannst du nicht gleich mehr als 1 Byte pro Anfrage übertragen lassen? 
Das macht´s sicherlich effizienter. Ich nehme an, die arbeiten intern 
mit dynamischen Listen und das hinzufügen eines neuen Listeneintrags 
dauert dann seine Zeit.

von Florian E. (Firma: keine) (fnet)


Lesenswert?

Ich werde aus der Funktionsbeschreibung nicht richtig schlauer...

Ich will lesen und nichts schreiben. Fuer mein Verstaendnis 
initialisiert der SPI Master (FT4232H) die Kommunikation und liest ein 
Byte.
Dann noch ein Byte... .. .

Dies geht auch schnell genug.

Mit welchen Parametern kann ich mehrere Commands auf einmal in die 
Command-Queue anfuegen... ?

Jegliche Erklaerung ist willkommen.

Florian


2.1.30  SPI_AddHiSpeedDeviceWriteCmd / Seite 45

http://www.ftdichip.com/Documents/ProgramGuides/AN_111_Programmers_Guide_for_High_Speed_FTCSPI_DLL.pdf



This function adds a write command and associated data to the internal 
command buffer(size 131070 ie 128K bytes) of a FT2232H dual hi-speed 
device or FT4232H quad hi-speed device. This enables a programmer to 
build up a sequence of commands ie write and read, before executing the 
sequence of commands.

ftHandle
   Handle of a FT2232H dual hi-speed device or FT4232H quad hi-speed 
device.

pWriteStartCondition
   Pointer to the structure that contains the start output states(low or 
high) of the clock, data out and signal out/chip select pins of the 
FT2232H dual hi-speed device or FT4232H quad hi-speed device.

bClockOutDataBitsMSBFirst
   Clock out control and data bits Most Significant Bit(MSB) 
first(TRUE), clock out control and data bits Least Significan Bit(LSB) 
first(FALSE)

bClockOutDataBitsPosEdge
   Clock out control and data bits on positive clock edge(TRUE), clock 
out control and data bits on negative clock edge(FALSE)

dwNumControlBitsToWrite
   Specifies the number of control bits to be written to an external 
device. Valid range 2 to 2040. 2040 bits is equivalent to 255 bytes.

pWriteControlBuffer
   Pointer to buffer that contains the control data to be written to an 
external device. Listed below are three examples of control and address 
bytes: Two Control bytes Control Address byte 1, Control Address byte 2 
Two Control bytes, Control Address byte 1, Control Address byte 2

dwNumControlBytesToWrite
   Specifies the number of control bytes in the write control buffer, 
which contains all the specified bits to be written to an external 
device. Valid range 1 to 255 bytes.

bWriteDataBits
   Write data bits to an external device(TRUE), do not write any data 
bits to an external device(FALSE)

dwNumDataBitsToWrite
   Specifies the number of data bits to be written to an external 
device. Valid range 2 to 524280. 524280 bits is equivalent to 64K bytes.

pWriteDataBuffer
   Pointer to buffer that contains the data to be written to an external 
device.

dwNumDataBytesToWrite
   Specifies the number of data bytes in the write data buffer, which 
contains all the specified bits to be written to an external device. 
Valid range 1 to 65535 ie 64K bytes.

pHighPinsWriteActiveStates
   Pointer to the structure that contains which of the 8 general purpose 
higher input/output pins (GPIOH1 – GPIOH8) of a FT2232H dual hi- speed 
device, are to be used during a write to an external device. Each GPIO 
pin that is to be used during a write to an external device must have 
been
previously configured as an output pin.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

> Ich will lesen und nichts schreiben.

SPI liest und schreibt gleichzeitig.

von Stefan M. (celmascant)


Lesenswert?

Rufus t. Firefly schrieb:
>> Ich will lesen und nichts schreiben.
>
> SPI liest und schreibt gleichzeitig.

Richtig!
Wenn der Master Daten zum Slave schickt, werden mit den gleichen 
Clockcycles Daten vom Slave zum Master übertragen.
Wenn der Master nix schreibt, kann der Slave auch nichts senden.
Wenn du also nichts zu schreiben hast, musst du ein Dummybyte schreiben.
Damit sagst du dem Slave quasi "Hey, ich hab nix für dich, aber gib mal 
deine Daten raus!"^^

Gruss Stefan

von Florian E. (Firma: keine) (fnet)


Lesenswert?

@Stefan: Wenn ich die MOSI Leitung abziehe, sollte der Slave demzufolge 
keine Daten rausgeben koennen und der Master nichts bekommen.

Dem ist aber nicht so.

Ob ich die MOSI Leitung an den Slave anstecke oder nicht, hat keinen 
Einfluss, ich bekomme in beiden Faellen die Daten.

Florian

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Das stimmt zwar, ändert aber am Prinzip nichts. Der Slave empfängt 
Daten, nur nicht die, die der Controller absendet, sondern halt das, was 
am offenen Eingang des Slaves so anliegt.

Die Übertragung erfolgt synchron zum Takt - und den erzeugt der Master 
nur bei Schreibvorgängen.

von STK500-Besitzer (Gast)


Lesenswert?

Der Slave braucht den Takt, nicht die MOSI-Daten.

von STK500-Besitzer (Gast)


Lesenswert?

Man schickt dem Slave Dummy-Daten, weil dadurch eine Kommunikation 
aufgebaut wird.

von Mars (Gast)


Lesenswert?

@Florian

Vergiss die FTCSPI.dll schnell wieder und programmiere die MPSSE selber. 
Für SPI ist das nicht sonderlich schwer.
Dann kannst du auch nur lesen, ohne Dummy Daten über USB schicken zu 
müssen.

von Florian E. (Firma: keine) (fnet)


Lesenswert?

Ist halt zu verlockend, wenn einem die dll angeboten wird....

Kann ich die MPSSE ueber die Funktionen der FT2DXX_NET.dll 
programmieren?

Mir fehlt hier der Ansatzpunkt.

Tips... Danke im voraus

Florian

von Mars (Gast)


Lesenswert?


von Florian E. (Firma: keine) (fnet)


Lesenswert?

Situation nochmal ganz kurz, mit C# ueber FTCSPI.dll ueber FT4232H einen 
SPI Slave auslesen.

FTDI Device open ...
FTDI Device init ...
FTDI Device set clcok ...

FTDI Device SPI_ClearCommandSequence(...)
FTDI Device SPI_AddHiSpeedDeviceWriteCmd(...) braucht viel Zeit.
FTDI Device SPI_ExecuteDeviceCmdSequence(...)

Stimmt, aber nur beim ersten Mal...

Wird die Funktion auf ein initialisiertes und geoeffnetes FTDI Device 
ein zweites Mal angewandt, sehr viel schneller.

FTDI Device open ...
FTDI Device init ...
FTDI Device set clcok ...

FTDI Device SPI_ClearCommandSequence(...)
FTDI Device SPI_AddHiSpeedDeviceWriteCmd(...) braucht viel Zeit.
FTDI Device SPI_ExecuteDeviceCmdSequence(...)

FTDI Device SPI_ClearCommandSequence(...)
FTDI Device SPI_AddHiSpeedDeviceWriteCmd(...) braucht wenig Zeit.
FTDI Device SPI_ExecuteDeviceCmdSequence(...)

Erster Aufruf dauert 100 mal laenger als zweiter Aufruf...

Florian

von Mars (Gast)


Lesenswert?

Liegt vermutlich am JIT von .NET. Ansonsten kann ich mir das Delay nicht 
vorstellen.
Ruf einmal ngen.exe auf, bevor du dein Programm startest.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.