FTDI / Brtchip EVE FT800 / FT813 CMD_GETPTR

[Eckhard T. (etik)]

Ich versuche gerade mein Programm mit dem Emulator von FTDI/Brtchip 
laufen zu lassen. Das funktioniert soweit ganz gut. Wenn ich allerdings 
nach dem Expandieren von komprimierten Bitmaps mit CMD_INFLATE versuche, 
mit CMD_GETPTR die nächste freie RAM-Adresse zu ermitteln, erhalte ich 
keine plausiblen Werte (0/viel zu groß/unverändert).

CMD_GETPTR funktioniert auf realer Hardware ohne Probleme.

Zum Testen habe ich in der Beispiel-App
http://brtchip.com/SoftwareExamples-eve/#Sample%20App(+EVE2)
folgende Funktion eingebaut und in App_Show_Logo() aufgerufen:

uint32_t GetNextRamAddr(Gpu_Hal_Context_t *phost)
{
  Gpu_Hal_WaitCmdfifo_empty(phost);
  Gpu_Hal_CheckCmdBuffer(phost, CMD_SIZE * 2);
  Gpu_Hal_StartCmdTransfer(phost, GPU_WRITE, CMD_SIZE * 2);
  Gpu_Hal_Transfer32(phost, CMD_GETPTR);
  Gpu_Hal_EndTransfer(phost);
  Gpu_Hal_Updatecmdfifo(phost, CMD_SIZE * 2);
  printf("0x%8.8lx 0x%8.8lx 0x%8.8lx\n",
    Gpu_Hal_Rd32(phost, RAM_CMD + ((phost->cmd_fifo_wp - 8) & 0xffc)),
    Gpu_Hal_Rd32(phost, RAM_CMD + ((phost->cmd_fifo_wp - 4) & 0xffc)),
    Gpu_Hal_Rd32(phost, RAM_CMD + ((phost->cmd_fifo_wp - 0) & 0xffc)));
  return Gpu_Hal_Rd32(phost, RAM_CMD + ((phost->cmd_fifo_wp - 4) & 0xffc));
}

Erwartungsgemäß klappt's nicht.

Der Code in GetNextRamAddr ist so länglich, weil die FTDI-Library je 
nach Konfiguration die Befehle sonst erst in einen Puffer schreibt.

Die Ausgabe am Ende der Funktion gibt den Inhalt des CMD FIFO um den 
Befehl herum aus. Der Befehl selbst taucht auch bei wp-8 auf, bei wp-4 
steht allerdings nichts Brauchbares.

Die negativen Offsets sind erforderlich, weil der Schreibzeiger nach dem 
Befehl bereits inkrementiert ist.

[Eckhard T. (etik)]

Mein Fehler: Nach dem Übertragen des Befehls CMD_GETPTR fehlt 
Gpu_Hal_WaitCmdfifo_empty().


Vermutlich sind die Verzögerungen durch die SPI-Übertragung zumindest 
bei meiner Hardware lang genug, so dass der FT8xx das Ergebnis bereits 
in das FIFO geschrieben hat.


Bei der Emulation kostet die simulierte SPI-Übertragung kaum Zeit. 
Deshalb steht das Ergebnis beim Lesen einfach noch nicht im FIFO.


Das bedeutet auch, dass das interne Timing des FT8xx sinnvollerweise 
simuliert wird.