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
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.
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.
> Ich will lesen und nichts schreiben.
SPI liest und schreibt gleichzeitig.
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
@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
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.
Gast
#1490404
Der Slave braucht den Takt, nicht die MOSI-Daten.
Gast
#1490406
Man schickt dem Slave Dummy-Daten, weil dadurch eine Kommunikation aufgebaut wird.
Gast
#1490424
@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.
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
Gast
#1490439
Schau dir mal http://www.ftdichip.com/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf an.
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
Gast
#1490902
Liegt vermutlich am JIT von .NET. Ansonsten kann ich mir das Delay nicht vorstellen. Ruf einmal ngen.exe auf, bevor du dein Programm startest.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.