Forum: Projekte & Code FT800 / FT810 Library


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Beitrag #6091190 wurde von einem Moderator gelöscht.
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Happy new year everyone! :-)

I am still interested in expanding the supported platforms and so I have 
added GD32VF103 for RISC-V a couple of days ago.
I have not tested it though (yet), as that would require me to solder 
jumper wires to my Longan Nano.

Since the GD21VF103 is "just" a GD32F103 with a RISC-C core, basic 
support for STM32 should be almost implemented now as well.
Well, apart from DMA that is.

If you would like to see other controllers added, tell me which.
And if you already have implemented the support code for a different 
controller, please post it.

And to keep things interesting, Bridgetek and FTDI posted news in 
november that they will be showing BT817 at Embedded World in february.

I have no solid idea so far what they are up to, but I will stay on top 
of it and add whatever new registers, defines and/or functions the BT817 
may require to unlock its added functionality.

von M. B. (mokkka)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Rudolph,

erstmal vielen Dank für die Bibliothek, die Arbeit die du da rein 
steckst und  den Support den du hier gibst.

Ich habe den FT800 mit einem 4,3" Resistiven Touchdisplay an ein STM32 
Chip angeschlossen. Die Kommunikation mit dem FT800 funktioniert und ich 
kann auch Elemente auf dem Display anzeigen.

Nun habe ich folgendes Problem:

Im ersten Schritt habe ich das Beispielprojekt von GitHub genommen und 
den Teil zur Kalibrierung im tft.c File aktiviert. Die Werte werden mir 
angezeigt und ich habe sie in einen eigenen define-Block übernommen.

Danach habe ich mit dem unteren Programmteil eine neue Displayliste 
erzeugt und mir einen Button anzeigen zu lassen.
  EVE_cmd_dl(CMD_DLSTART);
  EVE_cmd_dl(CLEAR_COLOR_RGB(31, 63, 127));
  EVE_cmd_dl(CLEAR(1,1,1));
  EVE_cmd_text(240, 68, 27, EVE_OPT_CENTER, "Test Text!!");
  EVE_cmd_dl(TAG_MASK(1));
  EVE_cmd_dl(TAG(5));
  EVE_cmd_button(180, 120, 120, 36, 27, EVE_OPT_CENTER, "Test Button!!");
  EVE_cmd_dl(DL_DISPLAY);
  EVE_cmd_dl(CMD_SWAP);
  EVE_cmd_execute();

Das alles geschieht vor dem while(1)-Block in der main-Routine.

Im while(1)-Block polle ich das REG_TOUCH_TAG-Register und gebe das 
Touch-Tag mit Hilfe von UART über Putty aus.

Beim Berühren des Buttons auf dem Display wird aber weiterhin eine 0 
ausgegeben bzw. wenn ich wahrlos auf dem Display neben dem Button drücke 
erscheint manchmal die erwartete 5 manchmal die 0.

Ich hab dann wieder die Kalibrierung durchgeführt und siehe da, es 
kommen andere Werte heraus.

Jetzt ist die Frage, ob man eine Kalibrierung jedes mal beim Start 
ausführen muss und die Kalibrierungsdaten ändern sich oder ob ich 
einfach ein Montagsprodukt erwischt habe und meine Toucheinheit einen 
Schuss weg hat.

Danke schonmal im Vorraus!

Gruß
Moritz

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich will nicht ausschliessen, dass ich gerade was kaputt gemacht habe, 
ich muss mir das noch genauer ansehen.

Aber benutzt mal einen anderen TAG Wert ab 10 aufwärts, da drunter ist 
das bei mir gerade nicht so richtig stabil.
Bei 5 schwankt der Wert komischerweise die ganze Zeit zwischen 4 und 5.
Bei 9 zwischen 8 und 9.
Bei 1 zwischen 0 und 1.
2, 3, 4, 6, 7, 8, 11, 15 und 19 funktionieren - was auch immer da los 
ist.

Zumindest stelle ich das gerade mit meinem EVE3-43G fest, wobei ich mir 
die Werte anzeigen lasse.

Meine FT800 Displays bekomme ich spontan nicht reaktiviert, die sind 
schon länger nicht mehr so wirklich interessant. :-)

Das TAG_MASK habe ich auch noch nie vewendet, das bewirkt so auch nichts 
da "1" sowieso der Default Wert ist.

Ich setze einfach ein TAG(0) für kein Touch, obwohl ohne einen Tag Wert 
zu setzen erstmal 255 geliefert wird.
Aber wenn kein Touch erkannt wird ist der Wert eben auch Null.

M. B. schrieb:
> Ich habe den FT800 mit einem 4,3" Resistiven Touchdisplay

Welches?

> an ein STM32 Chip angeschlossen.

Welchen und magst Du mal den Code dafür posten?


Was die Kalibrierung angeht, die mache ich in der Regel für jedes 
Display nur einmal und bisher passt es meistens sogar für verschiedene 
Displays vom gleichen Typ.
Wichtig ist allerdings, dass man die Kalibrierung präzise ausführt.
Bei resistiv geht das ja mit irgeneinem feinen aber stumpfen Gegenstand.
Für meine kapazitiven Displays habe ich mir extra Eingabestifte gekauft 
um die Punkte besser treffen zu können.

Und beim Spielen mit dem Stift auf dem Button habe ich gerade 
festgestellt, dass meine aktuellen Kalibrierwerte einen leichten Versatz 
nach Rechts haben, die Werte sind okay, das geht aber noch besser.

von M. B. (mokkka)


Bewertung
0 lesenswert
nicht lesenswert
> Aber benutzt mal einen anderen TAG Wert ab 10 aufwärts, da drunter ist
> das bei mir gerade nicht so richtig stabil.
> Bei 5 schwankt der Wert komischerweise die ganze Zeit zwischen 4 und 5.
> Bei 9 zwischen 8 und 9.
> Bei 1 zwischen 0 und 1.
> 2, 3, 4, 6, 7, 8, 11, 15 und 19 funktionieren - was auch immer da los
> ist.

Ok implementiert und keine Besserung immernoch wird nur der Wert 0 
ausgegeben

> M. B. schrieb:
>> Ich habe den FT800 mit einem 4,3" Resistiven Touchdisplay
>
> Welches?

ConnectEVE der Firma mikroE. Display ist schwer herauszufinden ich habe 
vorne noch einen Schriftzug mit RXA-043005 das ist allerdings nur die 
Bezeichnung vom Touchpanel. Zum TFT habe ich gar nichts gefunden.

>> an ein STM32 Chip angeschlossen.
>
> Welchen und magst Du mal den Code dafür posten?

STM32F407VG

Das ist die main() ohne Initialisierung der ganzen Schnittstellen welche 
automatisch generiert werden
  /* USER CODE BEGIN 2 */ 
  LL_SPI_Enable(SPI1);

  TFT_init();

  EVE_cmd_dl(CMD_DLSTART);
  EVE_cmd_dl(CLEAR_COLOR_RGB(31, 63, 127));
  EVE_cmd_dl(CLEAR(1,1,1));
  EVE_cmd_dl(TAG(0));
  EVE_cmd_text(240, 68, 27, EVE_OPT_CENTER, "Test Text!!");
  EVE_cmd_dl(TAG(10));
  EVE_cmd_button(180, 120, 120, 36, 27, 0, "Test Button!!");
  EVE_cmd_dl(DL_DISPLAY);
  EVE_cmd_dl(CMD_SWAP);
  EVE_cmd_execute();

  /* USER CODE END 2 */
 
 

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
   touch_tag=EVE_memRead8(REG_TOUCH_TAG);
   //if (touch_tag>0){
     if(touch_tag>9){
       touch_tag_uart[1]=(touch_tag%10)+48; //zehner Stelle als ASCII
       touch_tag_uart[0]=(touch_tag/10)+48; //einer Stelle als ASCII
     } else {
       touch_tag_uart[0]=32; // ASCII Space
       touch_tag_uart[1]=touch_tag+48;
     }
     HAL_UART_Transmit_IT(&huart2, touch_tag_uart, 4);
     while(HAL_UART_GetState(&huart2)!=HAL_UART_STATE_READY);
     touch_tag=0;
      //}
  }
  /* USER CODE END 3 */

Das ist der Teil aus der target.h
#if defined (STM32F407xx)

#include "EVE_config.h"
#include "main.h"

  static inline void EVE_pdn_clear(void)
  {
    HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
  }

  static inline void EVE_pdn_set(void)
  {
    HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
  }
  static inline void EVE_cs_clear(void)
  {
    HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
  }

  static inline void EVE_cs_set(void)
  {
    HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
  }

  static inline void spi_transmit(uint8_t byte)
  {
       while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 LL_SPI_ReceiveData8(EVE_SPI);
  }

  static inline uint8_t spi_receive(uint8_t byte)
  {
       while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 return LL_SPI_ReceiveData8(EVE_SPI);
  }

  static inline void spi_transmit_async(uint8_t byte)
  {
    #if EVE_DMA
        //TODO dma implementieren
    #else

    while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 LL_SPI_ReceiveData8(EVE_SPI);

    #endif
  }

  static inline uint8_t spi_receive_async(uint8_t byte)
  {
    #if EVE_DMA
        //TODO dma implementieren
    #else

    while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 return LL_SPI_ReceiveData8(EVE_SPI);

    #endif
  }

  static inline void DELAY_MS(uint32_t delay)
  {
    HAL_Delay(delay);
  }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
        return *data;
    }

#endif


> Was die Kalibrierung angeht, die mache ich in der Regel für jedes
> Display nur einmal und bisher passt es meistens sogar für verschiedene
> Displays vom gleichen Typ.
> Wichtig ist allerdings, dass man die Kalibrierung präzise ausführt.
> Bei resistiv geht das ja mit irgeneinem feinen aber stumpfen Gegenstand.
> Für meine kapazitiven Displays habe ich mir extra Eingabestifte gekauft
> um die Punkte besser treffen zu können.
>
> Und beim Spielen mit dem Stift auf dem Button habe ich gerade
> festgestellt, dass meine aktuellen Kalibrierwerte einen leichten Versatz
> nach Rechts haben, die Werte sind okay, das geht aber noch besser.

Ja ein bisschen nach rechts oder links finde ich in Ordnung allerdings 
weichen die Werte schon sehr stark ab.

z.B.:
                         1.Durchlauf     2.Durchlauf     3.Durchlauf     

TOUCH_TRANSFORM_A:          98982 UL        33658 UL        33536 UL
TOUCH_TRANSFORM_B:            158 UL        65690 UL   4294966582 UL
TOUCH_TRANSFORM_C:     4293468776 UL   4276760870 UL   4294069736 UL 
TOUCH_TRANSFORM_D:     4294966920 UL   4294966974 UL   4294966694 UL
TOUCH_TRANSFORM_E:          20348 UL        20404 UL        86052 UL
TOUCH_TRANSFORM_F:     4293312168 UL   4293521822 UL   4276733650 UL


Daher die Überlegung dass das Panel nicht ganz in Ordnung ist.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
M. B. schrieb:
>> Aber benutzt mal einen anderen TAG Wert ab 10 aufwärts, da drunter ist
>> das bei mir gerade nicht so richtig stabil.
>
> Ok implementiert und keine Besserung immernoch wird nur der Wert 0
> ausgegeben

Seltsam.

> ConnectEVE der Firma mikroE. Display ist schwer herauszufinden ich habe
> vorne noch einen Schriftzug mit RXA-043005 das ist allerdings nur die
> Bezeichnung vom Touchpanel. Zum TFT habe ich gar nichts gefunden.

Das ist schon etwas schwer angestaubt soweit. :-)
Ich hoffe das hast Du nicht gerade erst zu dem auf Mouser immer noch 
angezeigtem Kurs von 62 Euro gekauft.
Es gibt Beispielcode von MikroElektronika und da sind die Parameter 
drin, das habe ich gerade mal verglichen und ein Profil dafür 
hinzugefügt.
/* untested */
/* MikroElektronika ConnectEVE, FT800 480x272 4.3" */
#if defined (EVE_CONNECTEVE)
#define EVE_HSIZE  (480L)
#define EVE_VSIZE  (272L)

#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (10L)
#define EVE_VOFFSET  (12L)
#define EVE_VCYCLE  (286L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (41L)
#define EVE_HOFFSET  (43L)
#define EVE_HCYCLE   (525L)
#define EVE_PCLKPOL  (1L)
#define EVE_SWIZZLE  (0L)
#define EVE_PCLK  (5L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (2000L)
#define EVE_HAS_CRYSTAL
#endif

Die Parameter sind fast die gleichen wie bei den anderen 4.3" Displays.
Seltsamerweise weichen die Werte für VCYCLE and HCYCLE ab.

Das einzubauen und dafür zu compilieren hat auf jeden Fall noch einen 
Bug in EVE_get_touch_tag() aufgedeckt - die FT80x haben ja nur ein 
TOUCH_TAG Register...

> STM32F407VG

Ah okay, das ist schon eine ordentlich fixe Kachel. :-)

> touch_tag=EVE_memRead8(REG_TOUCH_TAG);
>    //if (touch_tag>0){
>      if(touch_tag>9){
>        touch_tag_uart[1]=(touch_tag%10)+48; //zehner Stelle als ASCII
>        touch_tag_uart[0]=(touch_tag/10)+48; //einer Stelle als ASCII
>      } else {
>        touch_tag_uart[0]=32; // ASCII Space
>        touch_tag_uart[1]=touch_tag+48;
>      }
>      HAL_UART_Transmit_IT(&huart2, touch_tag_uart, 4);
>      while(HAL_UART_GetState(&huart2)!=HAL_UART_STATE_READY);
>      touch_tag=0;

Auf den ersten Blick finde ich da nichts.
Du könntest mal REG_TOUCH_SCREEN_XY lesen und per sprintf() in einen 
String werfen, am besten als Hex-Wert.

M. B. schrieb:
> Das ist der Teil aus der target.h
...

Danke, ich schaue mal das ich das einbaue.
Wie sehen die Defines für EVE_PDN und EVE_CS und EVE_SPI aus?

Und die Includes passen nicht so richtig, EVE_config.h sollte nicht 
gebraucht werden und die main.c sollte eher die EVE_target.h inkludieren 
anstatt anders herum.
Statt dessen sollte da eher nur #include "stm32f4xx.h" stehen.

Die HAL Funktionen dürften das ganze übrigens nicht nur aufblähen, die 
sind auch verhältnismäßig langsam.
Die haben das gleiche Problem wie z.B. digitalWrite() beim Arduino, 
überflüssigerweise wird zur Laufzeit ermittelt was man eigentlich tun 
will.
Immer und immer wieder.
Zusätzlich fängt man sich mit dem Funktionsaufruf auch noch eigentlich 
überflüssige Stack-Zugriffe ein, was noch mehr Zeit kostet.

Daher benutzen meine AVR und ATSAM Funktionen direkte Register-Zugriffe.
Alleine den Funkions-Aufruf zu vermeiden macht das messbar schneller.

In den spi_transmit Funktionen LL_SPI_ReceiveData8(EVE_SPI); aufzurufen 
macht das ganze dann noch mal extra langsam.

> Ja ein bisschen nach rechts oder links finde ich in Ordnung allerdings
> weichen die Werte schon sehr stark ab.
>
> z.B.:                         1.Durchlauf     2.Durchlauf
> 3.Durchlauf
>
> TOUCH_TRANSFORM_A:          98982 UL        33658 UL        33536 UL
> TOUCH_TRANSFORM_B:            158 UL        65690 UL   4294966582 UL
> TOUCH_TRANSFORM_C:     4293468776 UL   4276760870 UL   4294069736 UL
> TOUCH_TRANSFORM_D:     4294966920 UL   4294966974 UL   4294966694 UL
> TOUCH_TRANSFORM_E:          20348 UL        20404 UL        86052 UL
> TOUCH_TRANSFORM_F:     4293312168 UL   4293521822 UL   4276733650 UL

Och, die Werte weichen bei mir auch immer mehr oder weniger stark ab, 
egal wie oft ich das neu kalibriere.
Richtig erklären kann ich das auch nicht, das liegt erstmal auch daran 
wie diese Werte verwendet werden.

Du kannst Dir ja mal die Funktion EVE_calibrate_manual() ansehen.
Da sieht man wie sich die Werte ergeben.
Da das aber auch nur bestenfalls die Hälfte des Puzzles ist, habe ich 
mich lieber was anderem gewidmet als bis ins Detail zu verstehen wie das 
funktioniert. :-)

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Ich habs mal eingebaut und dabei beschleunigt:
    #if defined (STM32F407xx)
    
    #include "stm32f4xx.h"

    #define EVE_CS_PORT GPIOD
    #define EVE_CS GPIO_PIN_12
    #define EVE_PDN_PORT GPIOD
    #define EVE_PDN GPIO_PIN_13
    #define EVE_SPI SPI1
    
    #define DELAY_MS(ms) HAL_Delay(ms)
      
    static inline void EVE_pdn_clear(void)
    {
      EVE_PDN_PORT->BSRR = EVE_PDN;
//      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
    }

    static inline void EVE_pdn_set(void)
    {
      EVE_PDN_PORT->BSRR = (uint32) EVE_PDN << 16;
//      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
    }

    static inline void EVE_cs_clear(void)
    {
      EVE_CS_PORT->BSRR = EVE_CS;
//      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
    }

    static inline void EVE_cs_set(void)
    {
      EVE_CS_PORT->BSRR = (uint32) EVE_CS << 16;
//      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
    }

    static inline void spi_transmit(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
        EVE_SPI->DR = byte;
        while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      while((EVE_SPI->SR & SPI_SR_RXE) == 0); /* does most likely nothing */
      return EVE_SPI->DR;
    }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
      return *data;
    }

    #endif  /* STM32F407xx */

Ich kann das nicht bauen, ich habe mir jetzt nur mal angesehen was im 
STM32F407 Referenz-Manual so steht und was der STM32F4xx_HAL_Driver so 
treibt.

Und natürlich sind die Defines für die Ports und die Pins frei erfunden. 
:-)

Edit: okay, die Optimierung für den PowerDown Pin ist eher überflüssig, 
das wird ja kaum mal verwendet.

Edit2: das Define für DELAY_MS war falsch..

: Bearbeitet durch User
von M. B. (mokkka)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Und die Includes passen nicht so richtig, EVE_config.h sollte nicht
> gebraucht werden und die main.c sollte eher die EVE_target.h inkludieren
> anstatt anders herum.
> Statt dessen sollte da eher nur #include "stm32f4xx.h" stehen.

Ich benutze die CubeMX Oberfläche um den Chip zu initialisieren. Die 
kreiert defines in der main.h. Diese defines habe ich in der config.h 
umdefiniert damit man nur an die config.h und nicht immer wieder an die 
target.h heranmuss.

Rudolph R. schrieb:
> Ich habs mal eingebaut und dabei beschleunigt:

Ich hab einen neuen pull gemacht und es sind noch ein paar Probleme 
aufgetaucht.

Rudolph R. schrieb:
static inline void spi_transmit(uint8_t byte)
     {
       EVE_SPI->DR = byte;
       while((EVE_SPI->SR & SPI_SR_TXE) == 0);
     }
 
     static inline void spi_transmit_async(uint8_t byte)
     {
       #if EVE_DMA
         EVE_dma_buffer[EVE_dma_buffer_index++] = data;
       #else
         EVE_SPI->DR = byte;
         while((EVE_SPI->SR & SPI_SR_TXE) == 0);
       #endif
     }
 
     static inline uint8_t spi_receive(uint8_t byte)
     {
       EVE_SPI->DR = byte;
       while((EVE_SPI->SR & SPI_SR_TXE) == 0);
       while((EVE_SPI->SR & SPI_SR_RXE) == 0); /* does most likely 
 nothing */
       return EVE_SPI->DR;
     }

Soweit ich das verstanden habe wird der Indikator SPI_SR_TXE gesetzt, 
wenn das Byte aus SPI*_DR erfolgreich in den Transmit Buffer geschrieben 
wurde. Deshalb hatte ich das vor dem Schreiben in das SPI*_DR Register 
abgefragt. Ich habe es mal mit beiden Versionen versucht also vor und 
nach dem Schreiben in das DR-Register. Ich konnte jetzt keinen 
Unterschied feststellen.

Der zweite Indikator heißt SPI_SR_RXNE.

Das zweite Problem entstand in der EVE_commands.h. Ich weiß nicht wie es 
bei anderen MCUs ist allerdings musste ich für den STM32F4 zusätzlich 
inttypes.h einbinden.

Nach diesen Änderungen, konnte ich die Bibliothek kompilieren. Trotzdem 
läuft es nicht und ich bekomme bei einem Read keine anständigen Werte 
zurück. Nach meiner Vermutung liegt das daran dass der Chip zu schnell 
für den FT800 ist. Durch Delays konnte ich das Display kurzzeitig zum 
Laufen kriegen. Nach einer Kalibrierung funktionierte es aber wieder 
nicht. Mit den LL-Bibliotheken funktioniert es weiterhin.

Rudolph R. schrieb:
> In den spi_transmit Funktionen LL_SPI_ReceiveData8(EVE_SPI); aufzurufen
> macht das ganze dann noch mal extra langsam

Meinst du damit den Aufruf von mehreren Funktionen? Im Grunde macht die 
Funktion ja nichts anderes als den Register auszugeben bzw beim Transmit 
das Register mit einem Pointer zu verbinden und mit dem dann die Daten 
über den Pointer in das Register zu schreiben. Bringt das soviel 
Overhead?
__STATIC_INLINE uint8_t LL_SPI_ReceiveData8(SPI_TypeDef *SPIx)
{
  return (uint8_t)(READ_REG(SPIx->DR));
}
__STATIC_INLINE void LL_SPI_TransmitData8(SPI_TypeDef *SPIx, uint8_t TxData)
{
#if defined (__GNUC__)
  __IO uint8_t *spidr = ((__IO uint8_t *)&SPIx->DR);
  *spidr = TxData;
#else
  *((__IO uint8_t *)&SPIx->DR) = TxData;
#endif /* __GNUC__ */
}

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
M. B. schrieb:
> Rudolph R. schrieb:
>> Und die Includes passen nicht so richtig, EVE_config.h sollte nicht
>> gebraucht werden und die main.c sollte eher die EVE_target.h inkludieren
>> anstatt anders herum.
>> Statt dessen sollte da eher nur #include "stm32f4xx.h" stehen.
>
> Ich benutze die CubeMX Oberfläche um den Chip zu initialisieren. Die
> kreiert defines in der main.h. Diese defines habe ich in der config.h
> umdefiniert damit man nur an die config.h und nicht immer wieder an die
> target.h heranmuss.

Wenn Du Dir mal mein (veraltetes, okay) Beispiel ansiehst, da gibt es 
noch eine "tft.c" und eine "tft.h".

Da habe ich die High-Level Funktionen drin die von der main.c aus
aufgerufen werden, modular und so.

Die "tft.h" exportiert bei mir aktuell:

extern uint16_t num_profile_a, num_profile_b;

void TFT_init(void);
void TFT_touch(void);
void TFT_display(void);

Die beiden Zahlenwerte beschreibe ich in der Hauptschleife, dazu messe 
ich mit einem Timer wie lange die TFT_touch() und die TFT_display() 
jeweils zur Ausführung benötigen.

Die "tft.c" includiert:
#include "EVE.h"
#include "EVE_target.h"
#include "EVE_commands.h"
#include "tft_data.h"

Da nun die "EVE_target.h" wiederrum die Platform-spezifischen Includes 
einfügt ist die tft.c als solche mit jeder Plattform benutzbar.

Packt man das alles in die main.c greift das natürlich soweit nicht, da 
die main.c quasi zwindend Plattform-spezifisch ist.

Also klar, mach doch, aber das ist ein wenig anders gemeint. :-)

> Soweit ich das verstanden habe wird der Indikator SPI_SR_TXE gesetzt,
> wenn das Byte aus SPI*_DR erfolgreich in den Transmit Buffer geschrieben
> wurde. Deshalb hatte ich das vor dem Schreiben in das SPI*_DR Register
> abgefragt. Ich habe es mal mit beiden Versionen versucht also vor und
> nach dem Schreiben in das DR-Register. Ich konnte jetzt keinen
> Unterschied feststellen.

Die einfachste Anwort ist erstmal, ich mache das überall so, für jede 
Plattform, schreiben, dann warten das der Transfer durch ist.
Damit ist zum Beispiel sichergestellt, dass das Chip-Select nicht zu 
früh wieder hoch gezogen wird und der SPI kann immer Daten annehmen.
Natürlich kann man das auch anderes herum machen und erstmal testen ob 
der SPI bereit ist Daten anzunehmen, da ich das aber nirgendwo sonst 
gemacht habe, ist es anders herum konsistenter.

> Der zweite Indikator heißt SPI_SR_RXNE.

Ups, das kommt davon wenn man das nicht compiliert.

Ich muss mal schauen ob ich irgendwoher ein STM32F407 Projekt bekomme 
das ich mit PlatformIO bauen kann.

Im Datenblatt ist mir dann noch was aufgefallen, die reinen Schreiben 
Funktionen sollten besser noch das RXNE Flag löschen.
Das ist vielleicht nicht ganz so fatal wie bei den ATSAM, aber wenn man 
Lesen und Schreiben auf dem SPI aktiv hat gibt es sonst einen Überlauf.
    static inline void spi_transmit(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      (void) EVE_SPI->DR; /* dummy read-access to clear SPI_SR_RXNE */
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
        EVE_SPI->DR = byte;
        while((EVE_SPI->SR & SPI_SR_TXE) == 0);
        (void) EVE_SPI->DR; /* dummy read-access to clear SPI_SR_RXNE */
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      while((EVE_SPI->SR & SPI_SR_RXNE) == 0); /* does most likely nothing */
      return EVE_SPI->DR;
    }

> Das zweite Problem entstand in der EVE_commands.h. Ich weiß nicht wie es
> bei anderen MCUs ist allerdings musste ich für den STM32F4 zusätzlich
> inttypes.h einbinden.

Da die EVE_commands.c die EVE_target.h includiert wird damit implizit 
oder explizit auch die stdint.h mit includiert.
Für AVR, ATSAM, RISC-V und auch STM32 passiert das automatisch über die 
System-Includes.
#include "stm32f4xx.h" -> #include "stm32f407xx.h" -> #include 
<stdint.h>

> Trotzdem läuft es nicht und ich bekomme bei einem Read
> keine anständigen Werte zurück.

Oh, vielleicht habe ich das gerade schon gefixt mit dem Löschen von RXNE 
bei den Schreib-Funktionen.

> Nach meiner Vermutung liegt das daran dass der Chip zu schnell
> für den FT800 ist.

Das sollte eigentlich so gut wie nicht passieren können.

> Durch Delays konnte ich das Display kurzzeitig zum
> Laufen kriegen.

Delays an welcher Stelle?
Wie schnell hast Du den SPI laufen? Zumindest für das Init sollte das 
unter 11MHz sein, dann unter 30MHz wobei die Hardware das auch mit 
machen muss.

Wenn Du einen Logik-Analyzer hast, zieh doch mal einen Trace.

>> In den spi_transmit Funktionen LL_SPI_ReceiveData8(EVE_SPI); aufzurufen
>> macht das ganze dann noch mal extra langsam
>
> Meinst du damit den Aufruf von mehreren Funktionen? Im Grunde macht die
> Funktion ja nichts anderes als den Register auszugeben bzw beim Transmit
> das Register mit einem Pointer zu verbinden und mit dem dann die Daten
> über den Pointer in das Register zu schreiben. Bringt das soviel
> Overhead?
> __STATIC_INLINE uint8_t LL_SPI_ReceiveData8(SPI_TypeDef *SPIx)
> {
>   return (uint8_t)(READ_REG(SPIx->DR));
> }

In dem besonderen Fall macht es überhaupt keinen Unterschied,
da LL_SPI_ReceiveData8() als STATIC INLINE definiert ist, genau wie die 
Funktionen in der EVE_target.h.
Das ergibt überhaupt keinen Overhead da kein Funktionsaufruf statt 
findet.

Nett, das habe ich schon ganz anders gesehen.
Hilft halt echt wenn man das bauen und wirklich nachsehen kann, was da 
so passiert. :-)

Damit wäre das hier mein Vorschlag:
    #if defined (STM32F407xx)
    
    #include "stm32f4xx.h"

    #define EVE_CS_PORT GPIOD
    #define EVE_CS GPIO_PIN_12
    #define EVE_PDN_PORT GPIOD
    #define EVE_PDN GPIO_PIN_13
    #define EVE_SPI SPI1
    
    #define DELAY_MS(ms) HAL_Delay(ms)
      
    static inline void EVE_pdn_clear(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
    }

    static inline void EVE_pdn_set(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
    }

    static inline void EVE_cs_clear(void)
    {
//      EVE_CS_PORT->BSRR = EVE_CS;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
    }

    static inline void EVE_cs_set(void)
    {
//      EVE_CS_PORT->BSRR = (uint32) EVE_CS << 16;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
    }

    static inline void spi_transmit(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
           LL_SPI_TransmitData8(EVE_SPI, byte);
           while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
           LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         return LL_SPI_ReceiveData8(EVE_SPI);
    }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
      return *data;
    }

    #endif  /* STM32F407xx */

Das HAL_GPIO_WritePin() braucht zwar ein paar Takte mehr, das fällt aber 
nicht wirklich auf und im Gegenzug ist das auch gar nicht mehr 
STM32F407, sondern STM32F4xx.
Für EVE_pdn_clear() / EVE_pdn_set() ist der Overhead irrelevant.
Für EVE_cs_set() / EVE_cs_clear() ist das auch nicht relevant, weil man 
für eine große Display-Liste sowieso besser den Burst-Modus benutzt, ob 
nun mit DMA oder nicht, damit hat man für den ganzen Datenblock nur noch 
ein set/clear Paar und vor allem nur noch einmal am Anfang des Blocks 
die Ziel-Adresse.

Und bei einzelnen Komandos merkt man die paar Takte Overhead sowieso 
nicht.

von Rudolph R. (rudolph)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Okay, ich habe ein neues PlatformIO Projekt erstellt.
Als Board habe ich einfach eine Drucker-Platine mit STM32F407 
ausgewählt.

--------------------------------------------------------------
Das ist nicht funktional und dient nur als Test ob das baut!
This does not work, the purpose is to see if it compiles!
--------------------------------------------------------------

Da wird nichts initialisiert, weder der Controller, noch die IOs oder 
der SPI.
Und die while(1) dreht einfach frei, die TFT_display() darf nur so alle 
20ms aufgerufen werden.

Nothing gets initialised, not the Core, or the IOs or the SPI.
And TFT_display() has to be called once every 20ms or more.


Ich musste die EVE_target.h jetzt doch noch ein wenig erweitern.
Ich dachte ja eigentlich, dass die HAL gleich mit includiert wird,
das war aber nichts.
#if defined (STM32F4)
    
#include "stm32f4xx.h"
#include "stm32f4xx_hal.h"
#include "stm32f4xx_ll_spi.h"
...

Edit, ich habe gerade noch aus dem STM32F407xx ein STM32F4 gemacht, das 
müsste soweit für die ganze Familie gelten.

Edit2: jetzt wüsste ich gerne noch, wie man Anhänge löscht :-)

: Bearbeitet durch User
von M. B. (mokkka)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Da die EVE_commands.c die EVE_target.h includiert wird damit implizit
> oder explizit auch die stdint.h mit includiert.
> Für AVR, ATSAM, RISC-V und auch STM32 passiert das automatisch über die
> System-Includes.
> #include "stm32f4xx.h" -> #include "stm32f407xx.h" -> #include
> <stdint.h>

Das Problem entsteht auch nicht in der EVE_commands.c sondern 
EVE_commands.h. die EVE_commands.c ist soweit glücklich und hat alles

Rudolph R. schrieb:
> Delays an welcher Stelle?
> Wie schnell hast Du den SPI laufen? Zumindest für das Init sollte das
> unter 11MHz sein, dann unter 30MHz wobei die Hardware das auch mit
> machen muss.

Am Anfang um die 6 MHz danach würde ich gerne auf 21 MHz es funktioniert 
aber nur bis 10,5 MHz

Gegenvorschlag =). Das Problem liegt tatsächlich an dem RXNE Flag. Man 
muss mit dem Read allerdings warten bis das Flag geworfen wird. Der Chip 
rennt an dieser Stelle schneller als der SPI_Bus dementsprechend muss 
auf das
Flag gewartet werden.

    #if defined (STM32F407xx)
    
    #include "stm32f4xx.h"

    #define EVE_CS_PORT GPIOD
    #define EVE_CS GPIO_PIN_12
    #define EVE_PDN_PORT GPIOD
    #define EVE_PDN GPIO_PIN_13
    #define EVE_SPI SPI1
    
    #define DELAY_MS(ms) HAL_Delay(ms)
      
    static inline void EVE_pdn_clear(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
    }

    static inline void EVE_pdn_set(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
    }

    static inline void EVE_cs_clear(void)
    {
//      EVE_CS_PORT->BSRR = EVE_CS;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
    }

    static inline void EVE_cs_set(void)
    {
//      EVE_CS_PORT->BSRR = (uint32) EVE_CS << 16;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
    }

    static inline void spi_transmit(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
         LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
           LL_SPI_TransmitData8(EVE_SPI, byte);
           while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
           while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
           LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
         return LL_SPI_ReceiveData8(EVE_SPI);
    }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
      return *data;
    }

    #endif  /* STM32F407xx */

Bis auf die Geschwindigkeit und die inttypes in der commands.h scheint 
es zu laufen.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
M. B. schrieb:
> Das Problem entsteht auch nicht in der EVE_commands.c sondern
> EVE_commands.h. die EVE_commands.c ist soweit glücklich und hat alles

Ah okay, dagegen habe ich in EVE_target.c und tft.c erst das
EVE_target.h und dann EVE_commands.h.

Intuitiver ist aber vielleicht ein #include "EVE_target.h"
direkt in die EVE_commands.h zu packen.

M. B. schrieb:
> Gegenvorschlag =). Das Problem liegt tatsächlich an dem RXNE Flag. Man
> muss mit dem Read allerdings warten bis das Flag geworfen wird. Der Chip
> rennt an dieser Stelle schneller als der SPI_Bus dementsprechend muss
> auf das Flag gewartet werden.

Ich habs eingebaut, danke.
Die SPI Unit von zumindest dem STM32F4 ist schon ein wenig seltsam.
Alternativ bliebe noch das Busy-Flag abzufragen.
Das Kapitel 28.3.7 vom Referenz-Manual ist da aber etwas komisch.
Es gibt weder ein BDM noch ein BDOE Bit.

Das dürften BIDIMODE und BIDOE sein so vom Kontext her.
Mit MSTR = 1, BIDIMODE = 0 und BIDOE = 1 sollte das passen.

Aber dann kommt der nächste Satz:
"It is cleared:
• when a transfer is finished (except in master mode if the 
communication is continuous)"

Was soll das denn bitte heissen?
Unter welchen Umständen ist der SPI Transfer kontinuierlich?
Wenn man DMA benutzt?
Falls das so ist, warum sollte man mit den Status Bits rumspielen wenn 
gerade ein DMA Transfer läuft?


Edit:
>Am Anfang um die 6 MHz danach würde ich gerne auf 21 MHz es funktioniert
>aber nur bis 10,5 MHz

Das ist vor allem auch eine Frage der Hardware.
Mit meinen aktuellen ATSAMC21 Platinen kann ich 12MHz ohne 
Einschränkungen verwenden, also nach dem Init.
Wenn ich auf 24MHz hoch stelle funktioniert allerdings der Touch nicht 
mehr, also irgendwie läuft das mit MISO nicht rund.

: Bearbeitet durch User
von Ioan Mihai Cozac (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Rudolf,

Erstmal Danke für deine erstklassiger Bibliothek, sie hat mir viel Zeit 
erspart.
Ich arbeite gerade bei einem Projekt in medizinische Bereich, dabei 
werden verschiedene Figuren und Texte teilweise animiert dargestellt, 
soweit funktioniert alles glücklicherweise wie gedacht.
Verwendet wird bei meinem Projekt ein 7" FT813 Display von Riverdi, und 
jetzt kommt mein problem: da die Pixels des displays nicht perfekt 
quadratisch sind die runde Formen wie Punkte und Kreisel werden leicht 
oval dargestellt.
Soweit habe keine Möglichkeit gefunden dies in Software zu kompensieren. 
Grundsätzlich müstte glaube ich ein Faktor von abs(sin(0,93 * PI) von 
Radius des Zirkels extrahieren sodass in verschiedene Richtungen dies 
unterschiedliche Länge hat. Also wie EVE_cmd_dl(POINT_SIZE (x - faktor) 
* 16).
Leider funktioniert das nicht wie erwartet, mir bleibt es immerhin oval.
Bei FTDI gibt auch keine weitere details über Primitives.
Sorry für meine Sprache, bin keiner nativen Deutschsprecher.

PS mit einem Display von Glyn funktioniert alles super, nur sind die 
vielmehr teurerer...

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Puh, ich muss zugeben, dass mir das bisher nicht mal aufgefallen ist, 
die Abweichung ist ja auch eher dezent.
Und ich benutze eher nur kleine Kreise.


Medizin ist ja mal interessant.
Wird das tatsächlich ein Produkt?
Welcher MikroController kommt da zum Einsatz?


Meine erste Idee war jetzt mal bei Matrix Orbital zu schauen, aber dem 
Datenblatt nach hat deren 7" Panel ein Pixel-Pitch von 0.1923*0.1784 und 
ist damit minimal "schlechter" als das Panel von Riverdi.

Wobei jetzt noch interessant gewesen wäre, welches Display das von 
Riverdi genau ist, ich habe mir jetzt nur das Datenblatt von den 
RVT70UQFNWC0x angesehen.

Die dritte Adresse für FT813 Displays wäre Newhaven, sowas wie das hier: 
https://www.newhavendisplay.com/nhd70800480ftctxlctp-p-9579.html

Da finde ich aber gerade gar keine Angabe im Datenblatt zum Pixel-Pitch, 
dazu müsstest Du denen mal eine Support-Anfrage einstellen.

Die haben auch mechanisch eine etwas andere Schnittstelle.


Direkt manipulieren kann man die "Primitives" nicht, die landen im 
Gegensatz zu den "Widgets" direkt so in der Display-Liste.
Und sowas wie CMD_SCALE wirkt sich nur auf Bilder aus, nicht etwa auf 
POINTS.

Eine Alternative zu einem anderen Display wäre noch auf POINTS ganz zu 
verzichten und das mit Bitmaps zu machen die vorab so verzerrt werden, 
dass sich das mit der Anzeige dann wieder ausgleicht.

Wenn der FT813 damit in der Anwendung nicht mehr funktioniert, weil 
einfach der Grafik-Speicher jetzt schon voll ist, schau Dir mal die 
BT815 basierten Displays von Riverdi und Matrix Orbital an.
Die haben ein SPI-FLASH mit auf der Platine das von dem BT815 
angesprochen wird, da kann man unter anderem Bilder rein packen die 
direkt angezeigt werden können.
Beschrieben wird der SPI-FLASH am bequemsten mit einem USB-SPI Interface 
was es ebenfalls von Riverdi oder Matrix Orbital gibt.

von TFTLCDCyg (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
The 7 "HD screen also has that uniqueness relative to" careless pixels "

Rudolph has considered using a microSD reader in your library, it is 
much more convenient to upload images on the GRAM of the FT81X screen, 
without running out of memory or complicating the code.

By the way, have you managed to upload videos in avi format with audio 
on the FT81x processor?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
TFTLCDCyg schrieb:
> Rudolph has considered using a microSD reader in your library, it is
> much more convenient to upload images on the GRAM of the FT81X screen,
> without running out of memory or complicating the code.

I have considered it and just switched to a bigger controller. :-)
More seriously this is just out of scope for my code.
Sure, combining mass storage with EVE could be beneficial but apart from 
mayb e a helper function to transfer a memory buffer to EVE that is not 
my job.

And this function already exists for every other architecture than AVR 
in form of the code that reads from flash.
On ARM this can read from anywhere.

> By the way, have you managed to upload videos in avi format with audio
> on the FT81x processor?

Others have, but I have not even tried this so far.
This is just not what I use the FT81x/BT81x for.

von Ioan Mihai Cozac (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
The project is a time controller associated with low power therapy laser 
devices. It counts the various intervals needed for bacteria 
desinfection in mouth and teeths using laser beams. It displays among 
other information both progress circular sectors and various sounds 
every 10, 30 or 60 seconds.
I designed this using an ESP32 as microcontroller, there will be a 
wireless link between the laser device and the time controller but this 
is not important here. The internal flash is big enough to store all the 
necesarry pieces of code and images.
Yesterday came another display from Riverdi this one is the BT815 
version, although the same LCD, so the ovalizing problem remains. We 
bought it because of the "umlaut" problem of the FT8xx series, we need 
the infos to be displayed in several languages.
So there is no easy way to fix the picture distortion, i think we will 
choose the expensive better displays from Glyn.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
While it is not really obvious for me when I look at the picture, 
measuring height and width shows a clear deviation, yes.

When you already use BT815 for extended font support, why not use 
pictures for the circles?
After all, these have 64MBit of FLASH installed and a few additional 
bitmaps should be easily possible, even more so when using ASTC 
compressed images directly from the external FLASH.

And does Glyn even offer a 7" with BT815?

von Ioan Mihai Cozac (Gast)


Bewertung
0 lesenswert
nicht lesenswert
I should have 60 or 90 different pictures for every display situation... 
and that for more than 10 different circular elements. I should compute, 
draw and store hundreds of bitmaps...
Such a circular sector widget has the following code:
[c]
FT8_cmd_dl(DL_BEGIN | FT8_LINES);
    FT8_cmd_dl(DL_COLOR_RGB | RED);
    FT8_cmd_dl(LINE_WIDTH(1 * 16));
    int r1 = 77, r2 = 128;
    for (int t1 = 0; t1 < 6; t1++)
    { // DRAWING 6 SEGMENTS 60 DEGREES AROUND MAIN CIRCLES
      float t = (t1 / 3.00) * PI;
      FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r1 * sin(t)) * 16, y * 16 - 
(int)(r1 * cos(t)) * 16));
      FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r2 * sin(t)) * 16, y * 16 - 
(int)(r2 * cos(t)) * 16));
    }
    FT8_cmd_dl(LINE_WIDTH(7 * 16));
    //FT8_cmd_dl(DL_COLOR_RGB | RED);
    byte segments = (sec_2 / 10) * 10 + 10; // HALF WIDTH POSITIVE 
OFFSET
    for (int t1 = 0; t1 < segments; t1++)
    { // DRAWING 30 SEGMENTS BARGRAPH AROUND TIME COUNTER
      float t = (t1 / 30.00) * PI + (0.5 / 30.00) * PI;
      if (min_2 < min2_max || sec_2 < sec2_max) //PROPER DISPLAY OF THE 
RED SEGMENTS
      {
        FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r1 * sin(t)) * 16 + 
(int)(abs(32 * cos(t))), y * 16 - (int)(r1 * cos(t)) * 16));
        FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r2 * sin(t)) * 16, y * 16 - 
(int)(r2 * cos(t)) * 16));
      }
    }
[c/]

Glyn has sent us a custom board for test, but our old display is only 6 
bit so the picture is not properly displayed. They said they could 
produce them for us if enough pieces will be ordered.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ioan Mihai Cozac schrieb:
> I should have 60 or 90 different pictures for every display situation...
> and that for more than 10 different circular elements. I should compute,
> draw and store hundreds of bitmaps...

I see, that would be indeed a lot of additional work.

Ioan Mihai Cozac schrieb:
> FT8_cmd_dl(DL_BEGIN | FT8_LINES);

Oh, so are using an older 3.x version.
I changed the FT8_ prefixes to EVE_ prefixes a long time ago.
While most of the changes have been for BT81x, there also have been a 
number of additions and fixes for the older generations.

von Ioan Mihai C. (mihaicozac)


Bewertung
0 lesenswert
nicht lesenswert
Yes indeed...
I will try the new version on the new BT815 display, i think all the 
settings are the same only the EVE_HAS_CRYSTAL should be set to 1.

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Bewertung
0 lesenswert
nicht lesenswert
Hallo und viel Erfolg im neuen Jahr!
Hat schon mal jemand ein Display der Firma ACTRON mit C-Touch am FT813 
betrieben? Lt. Datenblatt des Display hat er ein C-Touch-Controller 
HY4635 mit der I2C-Adresse Hx38. Mit dem Ossci kontrolliere ich Data und 
Takt der I2C-Schnittstelle. Und der FT813 spricht den HY4635 auch mit 
dieser Adresse an, es kommt das ACK und dann nur noch ein nicht 
vollständiges Byte - Schluss! Das Merkwürdigste ist dabei, dass die 
Taktleitung dauerhaft auf Low liegt (müsste aber in Ruhe auf High 
liegen). Gibt es noch irgend ein Register des FT813 (C-Touch-Register), 
was vielleicht in diesem Fall noch entsprechend gesetzt werden muss?
Benutze ich das DEMO-Board mit FT813 und mit 5" Display (Bridgetek), so 
funktioniert mit meiner selben Software natürlich alles. Ich setze 
lediglich am Beginn einmal den REG_CTOUCH_MODE und REG_CTOUCH_EXTEND und 
kann dann z.B. den Register REG_CTOUCH_TOUCH_XY auslesen und erhalte die 
Koordinaten. Auf der I2C-Schnittstelle des Demo-Board sehe ich die 
ordnungsgemäße Kommunikation mit dem Ossci. Hier ist die Takt-Leitung 
auf High, wenn keine Kommunikation statt findet.
Hat jemand einen Tipp?????

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Dazu ist gerade eine Diskussion im BRT Community Forum durch: 
http://www.brtcommunity.com/index.php?topic=62.0

Und so wie es aussieht verkauft Actron Displays von Powertip,
das passt dann also praktisch genau auf den Thread.

Um welches Modell geht es denn konkret?

Die Kurzversion ist das  man den Touch-Controller im FT813 minimal 
patchen muss um den I2C Takt niedriger einzustellen.

Edit: was zum Geier meint Actron mit I³?
Das sind doch gar keine intelligenten Displays.

Edit2: ich würde das ja auch gerne ausprobieren, aber dazu müsste ich 
dann erstmal eine Platine designen an die man so ein Display 
anschliessen kann -> dann doch lieber nicht.

: Bearbeitet durch User
von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rudi,
guter Tipp mit "minimaler Patch". I2C ist ja allgemein bekannt als 
langsame Schnittstelle, max. 160khz (ca.). Das messe ich mal nach, was 
der FT813 da macht (Geschwindigkeit)… Und wie könnte ich die 
Geschwindigkeit dieser Schnittstelle am FT813 ändern ?????????????
Es geht konkret um das SH800480TO13-IHC09, aber das spielt keine Rolle, 
glaube ich, da ich von ACTRON leichtsinniger Weise mal vor ein paar 
Monaten schon 40 Stück verschiedener Baugrößen und Art (10x 4,3"; 10x7" 
und je 10 mit Glas-Überstand und Glas-Abschließend) geordert hatte und 
das Problem sowohl mit dem 4,3-, als auch mit dem 7-Zöller habe. Das 
geniale an den ACTRON mit ACT I3 Anschlüssen ist, dass die damit genau 
"mein" Problem gelöst haben: Es gibt so viele Displays und jedes hat 
einen anderen Anschluss (das 40-50-polige Folienkabel). "Natürlich" sind 
das keine intelligenten Displays, einfach nur Displays. Und dafür habe 
ich mir nun Display-Treiber-PLatinen mit dem FT813 gebaut und kann dank 
der ACT I3 verschiedene Display für verschiedene Anwendungen mit dem 
einen Treiber realisieren - wenn ich denn das mit dem C-Touch noch 
hinbekomme!!! Schlimmstenfalls spreche ich diese Schnittstelle am FT813 
vorbei direkt mit meinem Prozessor an … Ich weiß, wie ich dich kenne 
krämpeln sich jetzt bei dir alle Fußnägel hoch - von wegen 
"Vergewaltigung" des FT8xx . Das ist wie mit "an dem Co-Prozessor" 
vorbei selbst Buttons generieren.. Hatte dazu ja schon meinen "Rüffel" 
von Dir bekommen!
Danke für den Link zum Thread. Schaue mich da jetzt mal um!

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Bewertung
0 lesenswert
nicht lesenswert
OK - Exakter geht es ja tatsächlich nicht! Habe ich also nicht allein 
das Problem. Wie es aus der Diskussion hervorgeht, ist es tatsächlich 
ein Geschwindigkeitsproblem und Hinweise zur Veränderung der 
Taktgeschwindigkeit des FT813 sind dort auch zu finden. Na dann probiere 
ich mal. Und in diesem Fall scheint mir die Bedienung dieser 
Schnittstelle am FT vorbei direkt durch meinen Prozessor immer weniger 
abwegig!!!

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Bernd I. schrieb:
> I2C ist ja allgemein bekannt als
> langsame Schnittstelle, max. 160khz (ca.). Das messe ich mal nach, was
> der FT813 da macht (Geschwindigkeit)…

I2C hat normalerweise 100kHz oder 400kHz und es gibt auch noch HighSpeed 
Versionen mit 1MHz oder so.
Die FT81x/BT81x machen 400kHz und der HY4635 ist mit 100kHz glücklicher.


Bernd I. schrieb:
> Und wie könnte ich die
> Geschwindigkeit dieser Schnittstelle am FT813 ändern ?????????????

Den Wert 40 an Adresse 0x30b1ac schreiben.
Das gibt 58kHz und mit 20 bekommt man wohl so 98kHz.

Die Bilder sieht man in dem Forum meine ich nur wenn man da angemeldet 
ist.
Die haben ein "code.png" angehängt.

Und da steht drin:
/* Hycon fix */
delay(50);
Gpu_Hal_Wr8(host, REG_CPURESET, 2);
Gpu_Hal_Wr8(host, 0x301b1ac, 40);
Gpu_Hal_Wr8(host, REG_CPURESET, 0);

Also EVE_memWrite8().

Und danach besser noch so eine Schleife wie in EVE_init():
  timeout = 0;
  while (0x00 != (EVE_memRead8(REG_CPURESET) & 0x03)) /* check if EVE is in working status */
  {
    DELAY_MS(1);
    timeout++;
    if(timeout > 50)
    {
      return 0;
    }
  }

Der Touch-Controller braucht nämlich ein wenig bis er wieder aus dem 
Reset da ist.

Oder eben einfach nur ein delay(50) oder so.


Bernd I. schrieb:
> Das
> geniale an den ACTRON mit ACT I3 Anschlüssen ist, dass die damit genau
> "mein" Problem gelöst haben: Es gibt so viele Displays und jedes hat
> einen anderen Anschluss (das 40-50-polige Folienkabel).

Also im Grunde genommen das was Glyn auch mit dem "Familie Konzept" 
macht.
Und solche Faxen mit den Display-Anschlüssen sind genau der Grund warum 
ich lieber fertige Module verwende. :-)

Bernd I. schrieb:
> Und dafür habe
> ich mir nun Display-Treiber-PLatinen mit dem FT813 gebaut

Hat auch was, jetzt noch auf BT815 aufrüsten, einen Controller dazu und 
einen 3,3V Regler. :-)

Nein im Ernst, niedliches Platinchen.
Die Displays haben einen Regler für die Beleuchtung integriert?
12V ist da schon etwas ungewöhnlich.

Bernd I. schrieb:
> Schlimmstenfalls spreche ich diese Schnittstelle am FT813
> vorbei direkt mit meinem Prozessor an … Ich weiß, wie ich dich kenne
> krämpeln sich jetzt bei dir alle Fußnägel hoch - von wegen
> "Vergewaltigung" des FT8xx .

Keine Ahnung was Du meinst. :-)
Es gibt genau für sowas den sogenannten "Host" Mode bei dem der 
Controller im Ziel-System die I2C Kommunikation mit dem Touch-Controller 
abwickelt und die Daten an den FT81x schickt damit dieser die auswertet.
Das ist sicherlich lästig und I2C gefällt mir so oder so nicht, aber 
bevor man eben gar keinen Touch hat, weil EVE nicht mit dem 
Touch-Controller spielen will...

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Bewertung
0 lesenswert
nicht lesenswert
Rudi schrieb:
Die Bilder sieht man in dem Forum meine ich nur wenn man da angemeldet
ist.
Die haben ein "code.png" angehängt.

Und da steht drin:
/* Hycon fix */
delay(50);
Gpu_Hal_Wr8(host, REG_CPURESET, 2);
Gpu_Hal_Wr8(host, 0x301b1ac, 40);     ICH HOFFE, DAS IST EIN 
SCHREIBFEHLER !
Gpu_Hal_Wr8(host, REG_CPURESET, 0);

Hallo Rudi,
ich traue mich nicht so recht, in den Bereich 30b1ac einen Wert zu 
schreiben (die 40). Dieser Bereich ist im Datenblatt nirgendwo 
benannt/beschrieben!
Der letzte Bereich endet bei 308FFF (der Command Buffer). Und ich hoffe, 
das da oben ist ein Schreibfehler - eine Eins zu viel hinter der 30. 
Denn der Herr "BRT Community" schreibt ja auch vom 30b1ac oder den 
RAM_JBOOT + 1ac.
Über den RAM_JBOOT finde ich nichts !!! Soll ich also ??? :):) Und an 
anderer Stelle schreibts Du selbst auch 30b1ac
Denn wenn man mal eben an eine falsche Stelle etwas schreibt, kann der 
FTI danach auch hinüber sein!

Das mit den 12V für die Hintergrundbeleuchtung ist tatsächlich etwas 
ungewöhnlich, bedeutet aber eben nur eine Ader zu meinem "Platinchen" 
mehr. Der Regler ist auf dem Display, der kommt aber eben nicht mit 3,3V 
aus, sondern braucht mind. 5V (max. 17V).

OK ich traue mich jetzt!

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich getraut !!!
Nachdem sich die Rauchwolke verzogen hatte …

Nein - alles Super. I2C arbeitet jetzt auf 57kHz (gemessen) und der 
Touch funktioniert! Auf alles andere hat diese Taktveränderung doch wohl 
keinen Einfluss ???

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Bewertung
0 lesenswert
nicht lesenswert
Da meine "Platinchen" ja nun zu 100% so funktionieren, wie ich es mir 
gedacht hatte, kann ich ja mal 100 Stück davon fertigen lassen (wir 
machen bei uns im Haus, außer ein paar Muster keine SMD-Bestückung, nur 
THT). Möchtest Du eine davon? Würde ich Dir schenken, als kleines 
Dankeschön für die Hilfe!!!
Aber die sind eben nur für die ACTRON-Display's nützlich!

Schönen Sonntag noch.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Bernd I. schrieb:
> Über den RAM_JBOOT finde ich nichts !!! Soll ich also ??? :):) Und an
> anderer Stelle schreibts Du selbst auch 30b1ac

Ja, Tippfehler. :-)
RAM_JBOOT gibt es auch nirgendwo in den Unterlagen, das stammt sicher 
aus internen Unterlagen von FTDI/Bridgetek.

Das ist der Bereich in dem der Code für den Touch-Controller liegt.
da kann man auch nichts kaputt machen, von der Architektur sehen die EVE 
nämlich so aus, dass die ein ROM haben (oder vielleicht auch ein FLASH), 
das beim Start in RAM kopiert wird, ein Shadow-RAM.
So funktionieren auch die FT9xx von FTDI.
Man kann den Speicher zwar nicht auslesen, aber beschreiben geht.

In AN_336 gibt es Binär-Blobs die an diese Stelle kopiert werden.
Das sieht man da nicht direkt, da der Blob in den Kommando Co-Processor 
geschrieben und ausgeführt wird.
Wenn man das aber zerlegt, kommt man schnell dahinter das da im 
wesentlichen ein CMD_INFLATE die Daten an 0x3b1ac entpackt.

Spannende Sache, die EVE sind also patchbar, viel weiter als das bin ich 
aber noch nicht gekommen, da sich FTDI/BRT da sehr bedeckt hält.
Die haben intern sicherlich ein SDK dafür.
Was die in den Thread gepackt haben hat mich jetzt ein wenig überrascht.

Bernd I. schrieb:
> Möchtest Du eine davon? Würde ich Dir schenken, als kleines
> Dankeschön für die Hilfe!!!
> Aber die sind eben nur für die ACTRON-Display's nützlich!

Ich würde eine nehmen, klar, ab in die Sammlung. :-)
Aber erstmal muss ich schauen ob ich ein Display dafür bekomme.
Actron sind aber nicht die einzigen die Displays von Powertip 
vertreiben.
Dann 8 Fädeldrähte und es sollte laufen. :-)

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Interessant, Powertip hat FT813 Displays im Sortiment von denen ich noch 
nie gehört habe.

PH800480T024-IFC03 5"
PH800480T013-IFC05 7"

Leider kann ich dazu nichts finden, keine Datenblätter, kein 
Distributor.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Bernd I. schrieb:
>> Möchtest Du eine davon? Würde ich Dir schenken, als kleines
>> Dankeschön für die Hilfe!!!
>> Aber die sind eben nur für die ACTRON-Display's nützlich!
>
> Ich würde eine nehmen, klar, ab in die Sammlung. :-)

Okay, ich habe intensiv gesucht und ich würde dann eher doch keines 
nehmen, aber vielen Dank für das Angebot!

Dazu passen praktisch nur eine Handvoll Displays:

PH320240T023-IHC04 PH320240T023-IHC06
PH480272T009-IHC05 PH480272T009-IHC07
PH800480T024-IHC07 PH800480T024-IHC11
PH800480T013-IHC09 PH800480T013-IHC12

Und die bekomme ich zum einen allesamt nicht einfach so bestellt.
Dann fallen die ersten 4 mit 3,5" und 4,3" auch praktisch gleich raus.

Wenn man tatsächlich Produkte verkauft sieht die Sache sicher anders 
aus, dann kann man da über die Mengen ganz anders heran gehen.

Da die Ganze Geschichte für mich aber eher ein Hobby ist, wenn auch mit 
dem Benefit gelegentlich dienstlich Arbeit zu generieren, kaufe ich 
Displays nur in niedrigen einstelligen Stückzahlen.
Ich habe gerade ein 5" EVE2-50G auf dem Tisch das als Einzelstück an 
einen Kunden geht.
Und daneben liegt ein 4,3" EVE3-43G für das ich eine Demo-Software 
vorbereite um Kollegen davon zu überzeugen die Neu-Auflage eines 
Haus-internen Tools mit Display zu machen.
Davon brauche ich dann vielleicht mal >10 Stück.
Als nächstes werde ich dann wohl wieder ein 7" als Einzelstück in einen 
Testplatz stecken dürfen.
Okay, ich habe praktisch den ganzen Spass ohne Probleme wie 
Produktkosten wirklich berücksichtigen zu müssen. :-)

Also für mich lohnt sich das einfach nicht einzelne Displays mit eigenen 
FT81x/BT81x Platinen zu verwenden

von Ioan Mihai C. (mihaicozac)


Bewertung
0 lesenswert
nicht lesenswert
Found a pretty simple workaround for the ovalization, i draw 2 points 
for every point needed, with the center vertically misaligned, about 6% 
of the radius of points. Mathematically is not quite a perfect circle 
but optically looks much better as before.
But i have some trouble with the newest version of your EVE, there is an 
error that appears regarding the SPI library. It apperas regardless if i 
use the FT813 or the BT815 display.
IDE is VS Code for Platform.io, microcontroller is ESP32 and the error 
is like this:

In file included from src\EVE_target.h:849:0,
                 from src\EVE_commands.c:192:
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:28:1: error: unknown type name 'class'
 class SPISettings
 ^
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:29:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
In file included from src\EVE_target.h:849:0,
                 from src\EVE_commands.c:192:
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:38:1: error: unknown type name 'class'
 class SPIClass
 ^
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:39:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:86:8: error: unknown type name 'SPIClass'
 extern SPIClass SPI;
        ^
In file included from C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\cores\esp32/Arduino.h:35:0,
                 from src\EVE_target.h:850,
                 from src\EVE_commands.c:192:
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\cores\esp32/esp32-hal.h:48:0: warning: "NOP" redefined
 #define NOP() asm volatile ("nop")
 ^
In file included from src\EVE_commands.c:191:0:
src\EVE.h:755:0: note: this is the location of the previous definition
 #define NOP() ((45UL<<24))
 ^
In file included from src\EVE_commands.c:192:0:
src\EVE_target.h: In function 'EVE_cs_set':
src\EVE_target.h:882:6: error: request for member 'setDataMode' in something not a structure or union
   SPI.setDataMode(SPI_MODE0);
      ^
src\EVE_target.h: In function 'spi_transmit_async':
src\EVE_target.h:894:7: error: request for member 'write' in something not a structure or union
    SPI.write(data);
       ^
src\EVE_target.h: In function 'spi_transmit':
src\EVE_target.h:899:7: error: request for member 'write' in something not a structure or union
    SPI.write(data);
       ^
src\EVE_target.h: In function 'spi_receive':
src\EVE_target.h:915:13: error: request for member 'transfer' in something not a structure or union
   return SPI.transfer(data);
             ^
src\EVE_target.h:916:2: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^

Using the older FT8... library the program compiles and runs OK.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Ioan Mihai C. schrieb:
> Found a pretty simple workaround for the ovalization, i draw 2 points
> for every point needed, with the center vertically misaligned, about 6%
> of the radius of points. Mathematically is not quite a perfect circle
> but optically looks much better as before.

Interesting, thank you for the suggestion.

Ioan Mihai C. schrieb:
> But i have some trouble with the newest version of your EVE, there is an
> error that appears regarding the SPI library.

This is a "feature" of Arduino that for "reasons" the classes are not 
supposed to work with plain .c files.
It should work just fine if you rename "EVE_commands.c" to 
"EVE_commands.cpp".

There might be a solution to fix that without renaming the file but I 
have not found one yet and I am normally not reminded about this since I 
am normally not using the Arduino framework.

Plus that renaming the file works kind of tells me that the issue is not 
really on my side...

von Karol B. (karol_b135)


Bewertung
0 lesenswert
nicht lesenswert
Hi Rudolph! A lot of thanks for your job. I still have very old lib, its 
working with FT800 and FT810 well. I have RVT70UQFNWC00 from Riverdi and 
a lot of problems with it. Pleas visit url link, there are schematic, 
PCB, some C listing and movie. Could you give me an advice what I do 
wrong? I mage another project with the same tft panel and its workinkg 
well. Im getting crazy, I spent more then 2 days traing to fix it. Pleas 
help.

Beitrag "FT800 / FT810 Library"

von Karol B. (karol_b135)


Bewertung
0 lesenswert
nicht lesenswert
Hi Rudolph! A lot of thanks for your job. I still have very old lib, its 
working with FT800 and FT810 well. I have RVT70UQFNWC00 from Riverdi and 
a lot of problems with it. Pleas visit url link, there are schematic, 
PCB, some C listing and movie. Could you give me an advice what I do 
wrong? I mage another project with the same tft panel and its workinkg 
well. Im getting crazy, I spent more then 2 days traing to fix it. Pleas 
help.
Beitrag "FT800 / FT810 Library"

https://www.elektroda.pl/rtvforum/viewtopic.php?p=18496421#18496421

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hello,

I can have a closer look when I am home again.

But please describe what the problem actually is.
I had to translate the website to Englisch and I am not sure if it got 
lost in translation but there is no description of the issue.

Also, please attach the code here as well, I would need to login to that 
other forum in order to see it.

And then, why not just switch to the latest version of my library?

von Karol B. (karol_b135)


Bewertung
0 lesenswert
nicht lesenswert
Thanks for your answer.
There is a movie, didn't you saw it?
I have a lot of strange behavior of display. Its live on his own life, 
changing all elements on screen also pressing touch without physical 
finger touch.
void ft800_init(void)
{
  uint8_t chipid;
  uint16_t timeout = 0;
  
  FT_PDN_DDR |= FT_PDN;
  FT_CS_DDR |= FT_CS;

  FT_PDN_PORT &= ~FT_PDN;
  DELAY_MS(6);  // minimum time for power-down is 5ms
  FT_PDN_PORT |= FT_PDN;
  DELAY_MS(21);  // minimum time to allow from rising PD_N to first access is 20ms

  //ft800_cmdWrite(FT_CLKEXT);  // Set FT800 for external clock
  ft800_cmdWrite(FT_CLKINT);
  ft800_cmdWrite(FT_CLK48M);  // FT_CLK48M Set FT800 for 48MHz PLL
  ft800_cmdWrite(FT_ACTIVE);  // Start FT800

  chipid = ft800_memRead8(REG_ID);  // Read ID register
  while(chipid != 0x7C)  // if chipid is not 0x7c, continue to read it until it is, FT81x may need a moment for it's power on selftest
  {
    chipid = ft800_memRead8(REG_ID);
    DELAY_MS(1);
    timeout++;
    if(timeout > 400)
    {
      break;//return 0;
    }
  }

  ft800_memWrite8(REG_PCLK, 0x00);    // Set PCLK to zero - don't clock the LCD until later
  ft800_memWrite8(REG_PWM_DUTY, 30);    // Turn off backlight

  // Initialize Display
  ft800_memWrite16(REG_HSIZE,   FT_HSIZE);  // active display width
  ft800_memWrite16(REG_HCYCLE,  FT_HCYCLE);  // total number of clocks per line, incl front/back porch
  ft800_memWrite16(REG_HOFFSET, FT_HOFFSET);  // start of active line
  ft800_memWrite16(REG_HSYNC0,  FT_HSYNC0);  // start of horizontal sync pulse
  ft800_memWrite16(REG_HSYNC1,  FT_HSYNC1);  // end of horizontal sync pulse
  ft800_memWrite16(REG_VSIZE,   FT_VSIZE);  // active display height
  ft800_memWrite16(REG_VCYCLE,  FT_VCYCLE);  // total number of lines per screen, incl pre/post
  ft800_memWrite16(REG_VOFFSET, FT_VOFFSET);  // start of active screen
  ft800_memWrite16(REG_VSYNC0,  FT_VSYNC0);  // start of vertical sync pulse
  ft800_memWrite16(REG_VSYNC1,  FT_VSYNC1);  // end of vertical sync pulse
  ft800_memWrite8(REG_SWIZZLE,  FT_SWIZZLE);  // FT800 output to LCD - pin order
  ft800_memWrite8(REG_PCLK_POL, FT_PCLKPOL);  // LCD data is clocked in on this PCLK edge
  ft800_memWrite8(REG_CSPREAD,  FT_CSPREAD);  /* helps with noise, when set to 1 fewer signals are changed simultaneously, reset-default: 1 */
  // Don't set PCLK yet - wait for just after the first display list

  ft800_memWrite8(REG_ROTATE, 1);  // rotate display by 180°

  // Configure Touch
  ft800_memWrite8(REG_TOUCH_MODE, FT_TMODE_CONTINUOUS);  // enable touch
  ft800_memWrite16(REG_TOUCH_RZTHRESH, FT_TOUCH_RZTHRESH);  // Eliminate any false touches

  // Configure Audio - not used, so disable it
  ft800_memWrite8(REG_VOL_PB, 0x00);      // turn recorded audio volume down
  ft800_memWrite8(REG_VOL_SOUND, 0x00);    // turn synthesizer volume off
  ft800_memWrite16(REG_SOUND, 0x6000);    // set synthesizer to mute

  ft800_memWrite32(FT_RAM_DL, DL_CLEAR_RGB);
  ft800_memWrite32(FT_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
  ft800_memWrite32(FT_RAM_DL + 8, DL_DISPLAY);  // end of display list
  ft800_memWrite32(REG_DLSWAP, FT_DLSWAP_FRAME);

  ft800_memWrite8(REG_GPIO, 0x80);  // Enable the DISP signal to the LCD panel
  ft800_memWrite8(REG_PCLK, FT_PCLK);  // Now start clocking data to the LCD panel

  ft800_memWrite8(REG_PWM_DUTY, 70);  // Turn on backlight
  ft800_memWrite8(REG_INT_EN,1);      // włączam przerwana)

  DELAY_MS(10);  // just to be safe
  cmdOffset =ft800_memRead16(REG_CMD_WRITE);
}

///////////////////////////////////////////////////////////////////////////////////////
// kilka podstawowych funkcji do obsługi FT8xx
// atmega128
void init_spi(void)
{
  SPCR = (1<<SPE) | (1<<MSTR);  // SPI on, MSB first, Mode 0, Master, 
  //SPSR = (1<<SPI2X);      // Fosc/2 
  SPCR |= (1<<SPR0);        //     /16
}
void ft800_memWrite8(uint32_t ftAddress, uint8_t ftData8)
{
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));    // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit(ftData8);      // Send data byte
  ft800_cs_clear();
}
void ft800_memWrite16(uint32_t ftAddress, uint16_t ftData16)
{
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));    // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit((uint8_t)(ftData16));    // Send data low byte
  spi_transmit((uint8_t)(ftData16 >> 8));    // Send data high byte
  ft800_cs_clear();
}
void ft800_memWrite32(uint32_t ftAddress, uint32_t ftData32)
{
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));    // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit((uint8_t)(ftData32));    // Send data low byte
  spi_transmit((uint8_t)(ftData32 >> 8));
  spi_transmit((uint8_t)(ftData32 >> 16));
  spi_transmit((uint8_t)(ftData32 >> 24));    // Send data high byte
  ft800_cs_clear();
}
void ft800_cmdWrite(uint8_t data)
{
  ft800_cs_set();
  spi_transmit(data);
  spi_transmit(0x00);
  spi_transmit(0x00);
  ft800_cs_clear();
}
// Beginn a co-processor command
void ft800_start_cmd(uint32_t command)
{
  uint32_t ftAddress;

  ftAddress = FT_RAM_CMD + cmdOffset;
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));  // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit((uint8_t)(command));    // Send data low byte
  spi_transmit((uint8_t)(command >> 8));
  spi_transmit((uint8_t)(command >> 16));
  spi_transmit((uint8_t)(command >> 24));    // Send data high byte
  ft800_inc_cmdoffset(4);      // update the command-ram pointer
}
// virtually the same as ft800memWrite32() but calculating the address and offset as the other commands
void ft800_cmd_dl(uint32_t command)
{
  ft800_start_cmd(command);
  ft800_cs_clear();
}
//
void page_start(void)
{
  ft800_cmd_dl(CMD_DLSTART); // Start the display list
  ft800_cmd_dl(DL_CLEAR_RGB | GRAY_LIGHT2); // Set the default clear color 
  ft800_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); // Clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers
}
//
void page_stop(void)
{
  ft800_cmd_dl(DL_DISPLAY);  // Instruct the graphics processor to show the list
  ft800_cmd_dl(CMD_SWAP); // Make this list active
  ft800_cmd_execute();
  _delay_ms(5);
  uint8_t int_mask = ft800_memRead8(REG_INT_FLAGS);
}
//

//przykładwe użycie:
const  uint8_t ds1307_daysinmonth [] PROGMEM = { 31,28,31,30,31,30,31,31,30,31,30,31 };
void ustaw_zegar(uint8_t minuty,uint8_t godziny,uint8_t dzien,uint8_t miesiac,uint8_t rok)
{
  uint8_t CurrTag=0,Pendown=0,PrevTag = 0, space;
  uint16_t tmp;
  btn_struct btn_s;
  char tmp_str[100];

  while(PrevTag!=TAG_OK && PrevTag!=TAG_CANCEL)
  {
    strcpy(tmp_str,num2string(2000+rok,NONE)); strcat(tmp_str,"/"); if(miesiac<10)  strcat(tmp_str,"0");
    strcat(tmp_str,num2string(miesiac,NONE)); strcat(tmp_str,"/"); if(dzien<10)  strcat(tmp_str,"0");
    strcat(tmp_str,num2string(dzien,NONE)); strcat(tmp_str,"  "); if(godziny<10)  strcat(tmp_str,"0");
    strcat(tmp_str,num2string(godziny,NONE)); strcat(tmp_str,":"); if(minuty <10) strcat(tmp_str,"0");
    strcat(tmp_str,num2string(minuty,NONE)); //strcat(tmp_str,":"); if(sekundy <10) strcat(tmp_str,"0");
    //
    if(!timDisp)
    {
      timDisp = 10;    
      page_start();  
      
      ft800_cmd_fgcolor(RED);
      ft800_cmd_gradcolor(RED);  //gradient przycisków
      ft800_cmd_dl(DL_COLOR_RGB | BUTTONS_TEXT_COLOR);    // kolor 
      
      ft800_cmd_ramfont(1, 34);
      ft800_cmd_dl(DL_COLOR_RGB | WHITE);  // kolor tekstu 
      ft800_cmd_text(800/2,200,1,FT_OPT_CENTERX|FT_OPT_CENTERY,tmp_str);
      
      space = 10; btn_s.w=(800-3*space)/2; btn_s.h=70; btn_s.y= 480-space-btn_s.h;
      btn_s.x=800-btn_s.w-space; btn_s.color=11141120; btn_s.tag=TAG_OK;
      draw_button_text2(btn_s,CurrTag,30,"ZAPIASZ");
      
      btn_s.color=2434341;  // ciemny szary
      btn_s.x=space;   btn_s.tag=TAG_CANCEL;
      draw_button_text2(btn_s,CurrTag,30,"ANULUJ"); //strcpy_P(tmp_str, txt[5+lng])
      
      ft800_cmd_dl(DL_COLOR_RGB | BLACK);  // kolor tekstu 
      space = 65; btn_s.w=180; btn_s.h=60; btn_s.y= 70;
      btn_s.x=30; btn_s.color=YELLOW; btn_s.tag=10;
      draw_button_text2(btn_s,CurrTag,31,"+");      
      
      btn_s.x+=btn_s.w+space+1; btn_s.w=70; btn_s.color=YELLOW; btn_s.tag=11;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.x+=btn_s.w+space+10; btn_s.color=YELLOW; btn_s.tag=12;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.x+=btn_s.w+space+5; btn_s.color=YELLOW; btn_s.tag=13;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.x+=btn_s.w+space-3; btn_s.color=YELLOW; btn_s.tag=14;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.w=180;btn_s.y= 270;
      btn_s.x=30; btn_s.color=YELLOW; btn_s.tag=15;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space+1; btn_s.w=70; btn_s.color=YELLOW; btn_s.tag=16;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space+10; btn_s.color=YELLOW; btn_s.tag=17;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space+5; btn_s.color=YELLOW; btn_s.tag=18;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space-3; btn_s.color=YELLOW; btn_s.tag=19;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      page_stop();
    }
      
    CurrTag = ft800_memRead8(REG_TOUCH_TAG);
    Pendown = ((ft800_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01);
    if(( 1 == Pendown) && (CurrTag != PrevTag))
    {
      if(PrevTag == 14){
        minuty++;
        if(minuty>59)minuty = 0;
      }
      if(PrevTag == 13){
        godziny++;
        if(godziny>23) godziny = 0;
      }
      if(PrevTag == 12){
        dzien++;
        if(dzien>pgm_read_byte(ds1307_daysinmonth + miesiac - 1)) dzien = 0;
      }
      if(PrevTag == 11){
        miesiac++;
        if(miesiac>12) miesiac = 1;
      }
      if(PrevTag == 10){
        rok++;
        if(rok>99) rok = 19;
      }
      if(PrevTag == 15){
        if(rok>19)rok--;
        else rok = 99;
      }
      if(PrevTag == 16){
        if(miesiac)miesiac--;
        else miesiac = 12;
      }
      if(PrevTag == 17){
        if(dzien)dzien--;
        else dzien = pgm_read_byte(ds1307_daysinmonth + miesiac - 1);
      }
      if(PrevTag == 18){
        if(godziny)godziny--;
        else godziny = 23;
      }
      if(PrevTag == 19){
        if(minuty)minuty--;
        else minuty = 59;
      }
      sygnal(100,1,1);
    }
    PrevTag = CurrTag;
  }
  // oczekiwanie na zwolnienie przycsiku
  while(!(ft800_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01){};
  if(PrevTag == TAG_OK)
  {
    tmp = ((minuty&0x3F)) | ((godziny&0x3F) <<6);
    send_tx_frame_wait(48,CMD_SET_TINE,tmp>>8,(uint8_t)tmp);  // wysyłam dane przez rs485 do innego modułu
    tmp = (dzien&0x1F) | ((miesiac&0x0F) << 5) | ((rok&0x3F) <<9);
    _delay_ms(50);
    send_tx_frame_wait(49,CMD_SET_DATE,tmp>>8,(uint8_t)tmp);  // wysyłam dane przez rs485 do innego modułu
  }
  _delay_ms(100);      
}

F_CPU=11059200 (is it to slow?)
Atmega 128, hardware SPI
PD=PINE6
CS=PINB4

Here are sch and pcb:
https://obrazki.elektroda.pl/2410018900_1582788848.png
https://obrazki.elektroda.pl/4933762200_1582788970.png

And movie:
https://filmy.elektroda.pl/54_1582790312.mp4

Regards,
Karol

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karol B. schrieb:
> There is a movie, didn't you saw it?

Yes, but apparently it played too small on the forum, I looked at it 
again and yes, it glitches.

> I have a lot of strange behavior of display. Its live on his own life,
> changing all elements on screen also pressing touch without physical
> finger touch.

Have you checked your 3.3V?
This displays draws current of 130mA or more on the 3.3V line.
I can not tell from the pictures which of the two 3.3V regulators is 
actually used for the display.
But, while I find no data for a LD117A, only LD1117A, the datasheet for 
the LD1117 lists 10µF minimum capacatiy at the output and you only have 
4.7µF.

And the APE8865-3 is designed to be stable with low ESR ceramic 
capacitors with 30mR to 50mR but it looks like you placed a tantalum cap 
there.
From what I can see in the video C12 at the display-connector also is a 
tantalum type.
Unless these are ultra low ESR types that might be the problem.

Annother idea, it looks like the case is made of metall and the 
anti-static bag under the display is a conductive one.
Please remove the display from the case and place it on a non-conductive 
underground.

>F_CPU=11059200 (is it to slow?)

This should be no problem.

I have to check the software later, looks like I need to translate some 
parts.

von Karol B. (karol_b135)


Bewertung
0 lesenswert
nicht lesenswert
PCB has 2 options for 3.3V regulator (1117-33 or APE8865Y5) I use only 
1117 series (spx1117m3-l-3-3). 1uF on input nad 100nF+4uF7 (tantalum) on 
output.
I checked by powered up pcb from laboratory power suplyy, still the same 
issue on display. That's weird but screen callibration or built in logo 
are working fine.

I placeed display on a non-conductive underground.

I have the same program working on anbother PCB, there are only a little 
changes:
- CS=PINB5, PD=PINB4
- ATMEGA128A@5V + 74125 for SPI level shift

As you can see on scheamtic, my connections on no-working PCB are: 
CS=PINB4, PD=PINE6, ATmega128A@3.3V

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karol B. schrieb:
> I use only 1117 series (spx1117m3-l-3-3). 1uF on input nad
> 100nF+4uF7 (tantalum) on output.

So this is the one from Exar, what type exactly is the 4µ7 output 
capacitor?
What is the exact modell number or where did you order it from?

Karol B. schrieb:
> I checked by powered up pcb from laboratory power suplyy, still the same
> issue on display.

But you supplied 5V?

> That's weird but screen callibration or built in logo are working fine.

These are really simple commands, there is not much going over the SPI 
for these.

Karol B. schrieb:
> I have the same program working on anbother PCB, there are only a little
> changes:
> - CS=PINB5, PD=PINB4
> - ATMEGA128A@5V + 74125 for SPI level shift
>
> As you can see on scheamtic, my connections on no-working PCB are:
> CS=PINB4, PD=PINE6, ATmega128A@3.3V

This should work just fine.
11MHz should be well within the allowable frequence for 3.3V.
The only issue I could think of would be that PB0 is not set to output.

von Karol B. (karol_b135)


Bewertung
0 lesenswert
nicht lesenswert
>4µ7 output capacitor? =>
TAJA475K006R from www.tme.eu

>But you supplied 5V?
Both, 5V+3.3V (3.3 LDO was present but current flow thrue it was equal 
or near 0mA)

I'm preaty sure now, the point is my pcb. The same program (only CS/PD 
pin connection are diferent) work fine on another PCB, but there are 
74xx125 level shifter.
Maybe the point is about SPI connection:
1) working fine => Atmega128@5V -> SPI thru 74LCX125MTC -> TFT
2) working bad => Atmega128@3.3V -> SPI direct to -> TFT
However, I saw on osciloscope shape of signals, they looks fine, I 
think.

PS. From some time, I allways set PB0 (SS) as output.
By the way, if it is an output, can I change state (PORTB0) in 
interrupt routine?

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karol B. schrieb:
>>4µ7 output capacitor? =>
> TAJA475K006R from www.tme.eu

Okay, this is the wrong capacitor for the job, the ESR is way too large.
Please replace it with a 4µ7 ceramic or put 2µ2+ in parallel to it.

>>But you supplied 5V?
> Both, 5V+3.3V (3.3 LDO was present but current flow thrue it was equal
> or near 0mA)

Hmm, okay.

> I'm preaty sure now, the point is my pcb. The same program (only CS/PD
> pin connection are diferent) work fine on another PCB, but there are
> 74xx125 level shifter.
> Maybe the point is about SPI connection:
> 1) working fine => Atmega128@5V -> SPI thru 74LCX125MTC -> TFT
> 2) working bad => Atmega128@3.3V -> SPI direct to -> TFT
> However, I saw on osciloscope shape of signals, they looks fine, I
> think.

I recently had an issue with an ATSAMC21 running at 3.3V and driving the 
SPI directly.
But that was because the ATSAMC21 is a lot weaker at driving the pins 
than the Mega128.
Also I was running the SPI at more than double the speed.
You could try to patch in a buffer for MOSI and SCK, something like a 
NC7WZ16P6X.
For MISO I am using a 74VHC1GT125 since I was hoping it would solve the 
issue that the data gets corrupted when reading with 24MHz - and it did 
not.

> PS. From some time, I allways set PB0 (SS) as output.

Excellent.

> By the way, if it is an output, can I change state (PORTB0) in
> interrupt routine?

Sure, this should not interfere with anything.

von Karol B. (karol_b135)


Bewertung
0 lesenswert
nicht lesenswert
MISO line:
https://obrazki.elektroda.pl/6391929500_1582828139.jpg
The same shape is present on PCB with 74xx125 buffer.

I have built several new tiles, this is the rule - it works with buffer, 
and without buffer doesn't.

What's the matter? As you said, Atmega128 has enough Pin-current to 
drive directly SPI interface. Also, speed isn't to fast (now I slow 
down: SPCR |= (1<<SPR0| 1<<SPR1); @ F_CPU=11059200).

PS. I have tryed run new librarry. I changed SMAC21 project (create new 
one with ATmega128, slect TFT, set PD,CS lines and still have blank 
screen).

von Rudolph R. (rudolph)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
That on the MISO line is quite normal, if you plot CS with it this 
should happen very shortly after CS goes high.
The line is just not driven anymore.

Karol B. schrieb:
> As you said, Atmega128 has enough Pin-current to
> drive directly SPI interface.

I can not find it in the datasheet right now but the M128-A should be 
able to drive at least 10mA @ 3.3V while the C21 can drive at best 6mA 
with two dedicated high-current pins while all the other pins can only 
drive 3mA.
And the 6mA is not enough, I had to put a second pin-pair for SCK and 
MOSI in parallel to make it work - which of course is no option with the 
M128-A.

I will add a buffer to my design and that is hopefully the end of it.

And the worst part of that issue was that the display just crashed after 
a few seconds for no apparent reason.
The voltage levels looked totally fine to me.
I had a small filter with 10R and 22pF and did quite some measurements, 
nothing worked.
Then I just put two 741G125 buffers in the SCK and MISO lines and it 
worked up to maximum speed.

Annother issue I had before that was with a board that had a slightly 
unstable 3.3V.
It would flicker on startup and after a short time the touch-controller 
crashed.
On a hunch I changed three caps on the board, I put an extra cap in 
parallel to the ouput-cap of my stepdown, the switched the boost cap at 
this stepdown in case I put on the wrong part and I put a second cap in 
parallel at the input to the stepdown.
One of these, or two or all three together did the trick and that 
display is rock solid now.


Anyways, I put together a small test version for the M128-A that might 
be even working - it compiles fine but I can not test it.
The init_ports() function might need adjustment to play nice with your 
board.
Oh yes, and the profiling values are completely wrong due to that 
strange clock of 11.0592MHz.

von Ioan Mihai C. (mihaicozac)


Bewertung
0 lesenswert
nicht lesenswert
Had this kind of self-tapping display error and found that the supply 
voltage was not stable enough, sometimes the current draw spikes and it 
leads to register corruption. Try with another power supply or use a 
extra ground wire from display to module, this helps also minimizing the 
audio noise if you use this function.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Rudolph,

auch von meiner Seite ein großes Dankeschön für deinen Treiber. Aktuell 
bin ich dabei diesen für meine Zwecke anzupassen. Dieser Thread hat mir 
bei einigen Problemen und Fragen zum BT-Chip weitergeholfen, allerdings 
bin ich jetzt auf ein Problem gestoßen, zu dem ich weder hier noch sonst 
wo etwas finden konnte.
Ich habe verschiedene Schriften konvertiert und auf den externen Flash 
gespielt. Das funktionierte bisher auch wie gewünscht.
Jetzt benötige ich allerdings verschiedene Symbole. Dafür habe ich mir 
die entsprechenden Schriften generiert, die diese Symbole beinhalten und 
die Symbole über UTF-8 Kodierung ausgegeben. Das funktioniert allerdings 
nur bis Codepage EF (Bsp.: E2 AF 85 zzgl. 0 zur Terminierung). Sobald 
die Symbole nach UTF-8 mit vier Bytes kodiert werden müssen (Bsp.: F0 9F 
A1 83 zzgl. 0 zur Terminierung), werden diese bei mir auf dem Display 
nicht mehr dargestellt.
Für die Darstellung der Schrift bzw. der Symbole verwende ich die 
EVE_cmd_text Funktion. Der Text wird allerdings nicht der Funktion 
übergeben, sondern vorher in einen entsprechenden Text-Buffer 
geschrieben. Diese Veränderung ist notwendig, um Abwärtskompaitbilität 
zur Software des vorherigen Displays gewährleisten zu können.

Codebeispiel:
switch (direction)

         {
            case 0://arrow up
            {

               arrow_x = x1+((x2-x1)/2)-20;
               arrow_y = y1+((y2-y1)/2)-12;

               EVE_cmd_setfont2(13, SPECIAL_FONT2_RAM_ADR,0); //special font

         //Dieser Pfeil wird korrekt dargestellt
               LCD_FuncData.text_buffer[0] =0xE2;
               LCD_FuncData.text_buffer[1] =0xAF;
               LCD_FuncData.text_buffer[2] = 0x85;
               LCD_FuncData.text_buffer[3] = 0;
               break;
            }
            case 1://arrow down
            {
               arrow_x = x1+((x2-x1)/2)-20;
               arrow_y = y1+((y2-y1)/2)-12;

               EVE_cmd_setfont2(13, SPECIAL_FONT2_RAM_ADR,0); //special font

         //Dieser Pfeil wird nicht angezeigt
               LCD_FuncData.text_buffer[0] =0xF0;
               LCD_FuncData.text_buffer[1] =0x9F;
               LCD_FuncData.text_buffer[2] = 0xA1;
               LCD_FuncData.text_buffer[3] = 0x83;
               LCD_FuncData.text_buffer[4] = 0;
               break;
            }
  }

  if (button_down)
        {
               EVE_cmd_button(x1,y1,x2-x1,y2-y1,13,EVE_OPT_FLAT); //hier wird die Beschriftung des Buttons über EVE_write_string aufgerufen und der Buffer-Inhalt an den BT816 übertragen
        }
        else
        {
               EVE_cmd_button(x1,y1,x2-x1,y2-y1,13,0);
        }


Vielleicht hat hier ja jemand eine Idee warum dieses Problem aufritt. 
Über einen Lösungsansatz würde ich mich freuen.

Grüße Simon

von Karol B. (karol_b135)


Bewertung
0 lesenswert
nicht lesenswert
> von Ioan Mihai C:
I tried with another power supply with no effect. FPC between TFT module 
and my PBC is 10cm long (sometimes even 20cm long) also with no 
difference. I will try add some extra ground.
For now, I made 4 pcb extra with the same uC but also with 74x125  IC 
buffer. Its look terrible but is working :)

>Rudolph,
THX for EVE_Test_M128_RVT70.zip, I will try in few days (I hope today, 
I'm really cant wait for it :) )

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Simon schrieb:
> Ich habe verschiedene Schriften konvertiert und auf den externen Flash
> gespielt. Das funktionierte bisher auch wie gewünscht.
> Jetzt benötige ich allerdings verschiedene Symbole. Dafür habe ich mir
> die entsprechenden Schriften generiert, die diese Symbole beinhalten und
> die Symbole über UTF-8 Kodierung ausgegeben. Das funktioniert allerdings
> nur bis Codepage EF (Bsp.: E2 AF 85 zzgl. 0 zur Terminierung). Sobald
> die Symbole nach UTF-8 mit vier Bytes kodiert werden müssen (Bsp.: F0 9F
> A1 83 zzgl. 0 zur Terminierung), werden diese bei mir auf dem Display
> nicht mehr dargestellt.

Okay, interessant, so tief habe ich das noch nicht getestet.
Ich war ja schon froh, einfache Sonderzeichen benutzen zu können. :-)
Mein Font hatte auch nur so 242 Glyphen oder so.

Was Du mal ausprobieren kannst ist das Flash-Image in den EVE-Screen 
Editor zu laden, bei der .glyph den Haken rein, dass die ins RAM geladen 
wird, etwa gleich in Adresse Null.
Dann einfach nur noch das SETFONT2(13, 0, 0) dazu und
ein CMD_TEXT() in das Fenster ziehen mit eben dem Font.
Zumindest ein "µ" konnte ich problemlos benutzen, also Sonderzeichen 
gehen schon mal grundsätzlich.
Was ist F0 9F A1 83 überhaupt? :-)

Simon schrieb:
> {
>                EVE_cmd_button(x1,y1,x2-x1,y2-y1,13,EVE_OPT_FLAT); //hier
> wird die Beschriftung des Buttons über EVE_write_string aufgerufen und
> der Buffer-Inhalt an den BT816 übertragen
>         }

Simon schrieb:
> Für die Darstellung der Schrift bzw. der Symbole verwende ich die
> EVE_cmd_text Funktion. Der Text wird allerdings nicht der Funktion
> übergeben, sondern vorher in einen entsprechenden Text-Buffer
> geschrieben. Diese Veränderung ist notwendig, um Abwärtskompaitbilität
> zur Software des vorherigen Displays gewährleisten zu können.

Hmm, okay,  warum nicht einfach den String übergeben?

In meinem aktuellen Projekt steht sowas drin:
char str_output[128];

...
uint_to_str(calc, str_output, 4);
EVE_cmd_text(480+115, 195, 27, EVE_OPT_RIGHTX, str_output);
int_to_str_3(calc_int32, str_output, 2);
EVE_cmd_text(310+265, 355, 27, EVE_OPT_RIGHTX, str_output);
GetErrCodeText(u16_Ctrl_ErrCode_F1, str_output);
EVE_cmd_text(310, 450, 27, 0, str_output);

Die Funktion EVE_cmd_text() will ja nur einen Pointer haben.
Und abgesehen von der Null für das Ende und das nach 249 Zeichen gekappt 
wird ist der Funktion auch der Inhalt egal.

Karol B. schrieb:
> FPC between TFT module
> and my PBC is 10cm long (sometimes even 20cm long)

That might be the issue, I only use 5cm cables.
And maybe your layout, the display shares the SPI with the SD card 
socket.
With the controller in die middle and running the SPI lines left and 
right you may have an issue with reflections.
You could try and add small resistors in the lines, 10R perhaps.
But ultimately I would suggest switching to a controller that is a 
little more advanced than the Mega128A.
Even a Mega1281 would be an upgrade since it has two SPI.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Was ist F0 9F A1 83 überhaupt?

Das ist ein bestimmter Pfeil den ich gerne verwenden würde, also nicht 
so extrem wichtig. Ich bin mir aber nicht sicher ob ich ggf. später noch 
andere Symbole aus den entsprechenden Codepages benötige und versuche 
deswegen das Problem schonmal vorab zu klären.

Rudolph R. schrieb:
> Was Du mal ausprobieren kannst ist das Flash-Image in den EVE-Screen
> Editor zu laden

Das habe ich probiert und es sieht tatsächlich so aus, als könne der 
BT-Chip die 4-Byte codierten Pages nicht verarbeiten. Er hat alle 
Zeichen/Symbole unter der 4-Byte Grenze, die ich probiert habe 
problemlos angezeigt. Alles ab dieser Grenze wird nur noch mit zwei 
Fragezeichen dargestellt. Auf meinem realen Display wird gar nichts 
angezeigt.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Simon schrieb:
> Rudolph R. schrieb:
>> Was Du mal ausprobieren kannst ist das Flash-Image in den EVE-Screen
>> Editor zu laden
>
> Das habe ich probiert und es sieht tatsächlich so aus, als könne der
> BT-Chip die 4-Byte codierten Pages nicht verarbeiten. Er hat alle
> Zeichen/Symbole unter der 4-Byte Grenze, die ich probiert habe
> problemlos angezeigt. Alles ab dieser Grenze wird nur noch mit zwei
> Fragezeichen dargestellt. Auf meinem realen Display wird gar nichts
> angezeigt.

Poste das bitte mal hier: http://www.brtcommunity.com/
So nach dem Motto "melden macht frei".
Mal schauen, was Bridgetek dazu zu sagen hat.

Wichtig wäre noch irgendwie zu verifizieren, dass die Glyphen wirklich 
im Font enthalten sind, die könnten ja auch bei der Konvertierung schon 
verloren gehen.

Eine Möglichkeit wäre dann vielleicht noch die Glyphen direkt selber 
anzuzeigen.
Wenn Du im EVE Screen Editor unten mal das Tab "Inspector" auswählst 
siehst
Du was der aus den Kommandos macht.

Bei mir taucht mit zwei Zeichen gerade das hier auf:

  Raw  Text
11  0x0500000d  BITMAP_HANDLE(13)
12  0x1f000001  BEGIN(BITMAPS)
13  0x0182c1ce  BITMAP_SOURCE(0x800000 | 180686)
14  0x405a02d0  VERTEX2F(180, 720)
15  0x01819cf4  BITMAP_SOURCE(0x800000 | 105716)
16  0x410802d0  VERTEX2F(528, 720)

Also im Grunde zerlegt der Co-Prozesser für das CMD_TEXT den String und 
berechnet für jedes Zeichen die Position und welches Bild anzuzeigen 
ist.
Der Knackpunkt wäre die Adresse zu finden, die steht wohl in der .glyph 
drin.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Poste das bitte mal hier: http://www.brtcommunity.com/
> So nach dem Motto "melden macht frei".
> Mal schauen, was Bridgetek dazu zu sagen hat.

Ok mache ich im Laufe des Tages mal.

Rudolph schrieb:
> Wenn Du im EVE Screen Editor unten mal das Tab "Inspector" auswählst
> siehst
> Du was der aus den Kommandos macht.

Das habe ich gemacht und er macht aus meinem Pfeil tatsächlich zwei 
Fragezeichen:

Das ist meine Eingabe:
CMD_TEXT(123, 117, 13, 0, "?🡃")

und das kommt dabei heraus:
  Raw  Text
13    0x01879bb4  BITMAP_SOURCE(0x800000 | 498612)
14    0x40f601d4  VERTEX2F(492, 468)
15    0x01879bb4  BITMAP_SOURCE(0x800000 | 498612)
16    0x411201d4  VERTEX2F(548, 468)
17    0x01879bb4  BITMAP_SOURCE(0x800000 | 498612)
18    0x412e01d4  VERTEX2F(604, 468)

Das merkwürdige ist, dass immer zwei Fragezeichen herauskommen, egal 
welches 4-Byte codierte Zeichen ich eingebe. Es scheint also von 
Bridgtek bewusst abgefangen zu werden....

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Kann man so einen Font irgendwo frei herunter laden um das mal 
auszuprobieren?

Und ich merke gerade das mir was Fonts angeht etwas die Tools fehlen.

Naja, für sowas wie "Prüfstand" habe ich das auch schon mal eingetippt 
und einen Screenshot davon gemacht. :-)

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Kann man so einen Font irgendwo frei herunter laden um das mal
> auszuprobieren?

Der entsprechende Pfeil, der bei mir nicht funktioniert ist in dieser 
Schrift enthalten: 
https://fontlibrary.org/de/font/symbola#Symbola-Regular

Allgemein gibts es noch weitere nützliche Open Source Fonts, 
beispielsweise hier:
https://github.com/Microsoft/fonts
oder hier
https://github.com/adobe-fonts?page=1

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das ist ein wenig anstrengender als ich dachte. :-)

Der Pfeil ist also U+1F843, damit findet man den dann zum Beispiel auch 
in der Character-Tabelle zu dem Symbole Font.
In UTF-8 kodiert sind das die F0 9F A1 83 - was ja sofort offensichtlich 
im Zusammenhang steht. :-)

Nun ist 00000 bis 0FFFD der Bereich BMP - Basic Multilingual Plane.
Und 1F843 gehört zum nächsten Bereich SMP - Supplementary Multilingual 
Plane und ist da im Block "Supplemental Arrows-C".

https://www.sql-und-xml.de/unicode-database/#blockbereiche

Da wird in den BT81x wohl "nur" BMP implementiert sein.
Scheinbar hat das Windows Tool "Zeichentabelle" das gleiche Problem, da 
finde ich die Pfeile nämlich auch nicht.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast Du mal versucht den Offset der Glpyhe auszurechnen um diese direkt 
anzuzeigen?

Also wie hier:

11  0x0500000d  BITMAP_HANDLE(13)
12  0x1f000001  BEGIN(BITMAPS)
13  0x0182c1ce  BITMAP_SOURCE(0x800000 | 180686)
14  0x405a02d0  VERTEX2F(180, 720)

Im "BT81X Series Programminung Guide 1.1" steht auf Seite 100 / 101
wie man die die Adresse berechnet.

Dazu muss man die .glpyh auslesen.

Und dann im Kern sowas hier:

return (xf->start_of_graphic_data + xf->gptr[cp / 128] + bytes_per_glyph 
* (cp % 128) / 32);

Das hilft nur nicht, wenn die Daten gar nicht erst enthalten sind.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Da wird in den BT81x wohl "nur" BMP implementiert sein.

Das ist auch meine aktuelle Vermutung. Auf der BRT Seite hat sich leider 
noch nicht allzu viel getan, bin mal gespannt was da von Bridgtek als 
Antwort kommt.

Rudolph schrieb:
> Hast Du mal versucht den Offset der Glpyhe auszurechnen um diese direkt
> anzuzeigen?

Hatte ich noch nicht probiert. Habe das gestern auch nur kurz probieren 
können. Bei meinen errechneten Adressen ist der Screen Editor allerdings 
abgestürzt, obwohl der Adressbereich eigentlich gültig war. Ich gucke 
mir das bei Gelegenhiet nochmal in Ruhe an. Danke für den Tipp.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal ein wenig mit Fonts gespielt und mir fehlt vor allem immer 
noch ein Tool mit dem man Code-Blöcke aus Fonts löschen kann.
Über 8000 Glyphen zu haben ist zwar ganz nett, wenn man das auf Bitmap 
mit einer festen Größe konvertiert wird das aber schnell unlustig.

Der Webfont-Generator auf www.fontsquirrel.com ist schon sehr hilfreich, 
den finde ich von den Optionen her aber ein wenig eingeschränkt.
Und ich bin nicht mal sicher, ob der mit den Bereichen jenseits von BMP 
klar kommt.

Dann habe ich mir mal die resultierende .xfont Datei angesehen die der 
EVE Asset Builder erzeugt.
Und eine Sache ist schon mal sehr seltsam, die Anzahl der Glpyhen steht 
immer auf 65536, egal wie viele Glyphen der Font wirklich hat.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bisher habe ich immer nur alle Glyphen oder eine so geringe Auswahl 
verwendet, dass ich die händisch in eine .txt-Datei geschrieben habe. 
Die kann man ja dann in den EVE Asset Builder laden als Vorgabe. 
Deswegen kann ich dir aktuell beim Thema Software zur Auswahl von 
Codeblöcken leider auch nicht weiterhelfen.

Rudolph schrieb:
> Dann habe ich mir mal die resultierende .xfont Datei angesehen die der
> EVE Asset Builder erzeugt.

Worin hast du dir die denn angesehen? In Notepad++ oder im hex-Editor 
kann ich da keine Rückschlüsse auf die Anzahl der Glyphen ziehen. Aber 
das würde ja die Vermutung bestätigen dass das einfach nicht vorgesehen 
ist.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die .xfont habe ich einfach mit einem Hex-Editor aufgemacht.

Die Struktur dazu steht ja im Programming Manual.

Das sieht dann zum Beispiel so aus:

FF AA 00 01 Signatur
90 22 00 00 Size
B5 93 00 00 Format
4A 02 00 00 Swizzle
60 00 00 00 Layout Width
04 00 00 00 Layout Height
30 00 00 00 Pixel Width
14 00 00 00 Pixel Height
80 00 80 00 Start of Graphic Data
00 00 01 00 Number of Characters
00 2E 10 00 gptr - Offsets to glyph data

Anhand der Signatur sieht man, dass das erste Byte das LSB ist.

Die "Number of Characters" scheint dabei schon mal nicht richtig gesetzt 
zu werden, da steht immer 0x00010000 drin.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ach stimmt da war ja was...

Rudolph schrieb:
> Die "Number of Characters" scheint dabei schon mal nicht richtig gesetzt
> zu werden, da steht immer 0x00010000 drin.

Habe das jetzt mal für verschiedene Schriften durchgeschaut und kann das 
nicht bestätigen. Bei mir variiert das je nach Anzahl enthaltener 
Zeichen (damit meine ich die Anzahl an Zeichen, die ich über die 
.txt-Datei vorgeben habe).
Auffällig ist allerdings dass der Wert immer kleiner oder gleich 65536 
ist. Bei der Symbolschrift, mit der ich die beschriebenen Probleme habe, 
steht der besagte Wert von 65536 drin.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe aktuell den Symbola.ttf mit den 8xxx Glyphen durch den EVE 
Asset Builder gezogen, ASTC, 12 Punkt, sowie einen Notosans-regular den 
ich mit Fontsquirrel auf 222 Glyphen reduziert habe.
Also einfach machen lassen ohne das über eine Datei einzuschränken.

Und da steht beide Male 0x00010000 drin.

Jetzt habe ich gerade mal den Notosans-regular mit 32xx Glyphen 
durchlaufen lassen und da ist das auch so.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Habe das auch nochmal ausprobiert. Dieser Wert scheint sich auf die 
Einschränkungen durch die .txt-Datei zu beziehen. Wenn ich den gesamten 
Schriftsatz konvertiere habe ich auch immer den Wert 0x00010000.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Naja, mal davon ab, dass es dann eben nicht die Anzahl der Zeichen ist, 
das ist ja auch noch ein wenig niedrig angesetzt, so eigentlich.

Leider mahlen die Mühlen bei Bridgtek etwas sehr langsam und das hart 
moderierte Forum hilft da auch wenig diesen Eindruck zu entschärfen.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"We discovered an issue with EAB regarding 4-byte UTF-8 characters.
EAB v1.4 is scheduled at Mar 25 and will include a fix for this."

Na, das klingt doch sehr vielversprechend und lange hin ist das auch 
nicht mehr. :-)

Das interpretiere ich so, dass EVE das grundsätzlich kann, die Daten nur 
gar nicht erst durch den Konverter gegangen sind.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch positiv überrascht und werde das auf jeden Fall direkt 
testen, sobald die neue Software verfügbar ist. :-)

von JohnLemon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hello all,
I'm trying to figure out how to upload custom font to ram into BT815. I 
have Riverdi RVT43ULBNWC03 connected to ESP32 (arduino framework). I 
generated font files in EVE Asset Builder and tried to upload content of 
.raw file with EVE_cmd_loadimage command but display stuck on black 
screen... Can someone explain me how to upload fonts to BT81x?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Well, do you also have a USB/SPI adapter like the Hermes board from 
Riverdi?
https://riverdi.com/product/hermes-board/

With that you can upload the flash image using the EVE Asset Builder to 
the on-board SPI-FLASH on the display.

In order to upload the data to EVEs G-RAM the font would need to be 
rather small.

Either way, EVE_cmd_loadimage() is only for .jpg and .png images.

You either need EVE_memWrite_flash_buffer() to transfer raw data from 
your target controller to G-RAM or EVE_cmd_inflate() if the data is 
z-lib compressed.

If you have the font data in the external SPI-FLASH you can use it 
directly from there if it is compressed in ASTC format.
In this case you only need to copy the .xfont file to G-RAM.
Preferably with EVE_cmd_flashread() as the .xfont can be stored in the 
SPI-FLASH as well.

When you have the .xfont in G-RAM and the .glyph either in G-RAM or in 
the SPI-FLASH you need to use EVE_cmd_setfont2() to assign a 
bitmap-handle to the new font.


What font are you using, how do you convert it and what sizes do the 
resulting files have?

: Bearbeitet durch User
von JohnLemon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hello Rudolph,
thank you for your answer. I don't have Hermes Board from Riverdi. I'm 
basing on AN277 from FTDI:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_277_FT800_Custom_Font_Implement.pdf

I made .raw and .rawh files in EVE Asset Builder (Legacy Format), added 
content of metricblock and font table to my font.c file, and I tried to 
use it as in the AN277.
Is it possible to upload a font to FLASH via ESP32?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Okay, so this is legacy format with a maximum of 128 characters.
You can just follow the application note then.
It would be possible to write the data to the SPI-FLASH but this would 
only make things more complicated.

The code in the application note has this:

//load font data into memory
Ft_Gpu_Hal_WrMemFromFlash(phost, RAM_G + 1000, 
SAMApp_ShowCustomFont_MetricBlock, 148);
Ft_Gpu_Hal_WrMemFromFlash(phost, RAM_G + 1000 + 148, 
SAMApp_ShowCustomFont_FontBmpData,
36432);

Translated to my library this is:

EVE_memWrite_flash_buffer(RAM_G + 1000, 
SAMApp_ShowCustomFont_MetricBlock, 148);
EVE_memWrite_flash_buffer(RAM_G + 1000 + 148, 
SAMApp_ShowCustomFont_FontBmpData,
36432);

When you have this up and running you can try to use setfont2 instead.
But not like in the application note.
I have no idea what the guys at FTDI where thinking when they did 
chapter 4.2 but it makes the example overly complicated by loading the 
data from a file instead of loading it from the controllers memory like 
in 4.1.
And loading a file from disk while building a display list also is not 
the brightest idea.

Also the example is plain wrong, the four lines before 
Ft_Gpu_CoCmd_SetFont2() are useless, Setfont2 takes care of this.
And the comment says that it sets the starting character to 32 but the 
parameter is "97".

I do not have an ESP32 here right now but a whole lot of displays 
including a Riverdi 4.3" and a Matrix Orbital EVE3-43G.

And to test this with an Arduino I could use the CFAF800480E1 from 
Crystalfontz which has a FT813.
See: 
https://github.com/RudolphRiedel/FT800-FT813/tree/4.x/example_projects/EVE_Test_Arduino_PlatformIO

Just change the target in platformio.ini , switch to EVE_RiTFT43 in 
EVE_config.h.
Then check the end of EVE_target.h for the Arduino options.
You need to provide the pins for Chip-Select and Power-Down.
And I am not sure about the ESP32, if the Arduino target provides a 
SPI.transfer() function the example already should compile and run just 
fine.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Okay, I just went ahead and tried to build my Arduino example for ESP32.

platformio.ini:

[env:esp32]
platform = espressif32
board = wemos_d1_mini32
framework = arduino

EVE_target.h:

...
#if defined (ARDUINO)

  #include <Arduino.h>
  #include <stdio.h>
  #include <SPI.h>

  #define EVE_CS     9
  #define EVE_PDN    8
...

For some reason the ESP32 needs the Arduino.h include while it just 
builds for the Uno and the Due.

And then there are warnings that NOP() gets redefined in EVE.h.
So you can just comment out line 757 of EVE.h:
//#define NOP() ((45UL<<24))

With that it at least builds for ESP32.

von JohnLemon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hello,
thank you very much for your help. I will test it tomorrow. I know about 
warning with NOP and Arduino.h definitions. This is the case for every 
project.

von JohnLemon (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hello,
I bought Hermes and I uploaded the fonts to flash- it works perfectly 
:). But now I have problem with PNG without background.
I have a white icon (WIFI status) with background transparency. But when 
I display it on TFT I have icon in color that was previoulsy defined. 
When the color is the same like background where icon is, then it should 
be white, but it have color little bit darker than background.
drawBitmap(MEM_ICON_WIFI, 130, 3, 25, 25, EVE_RGB565, 0, WHITE);
void drawBitmap(uint mem_icon, uint x, uint y, uint w, uint h, uint fmt, uint tag, uint bg)
{
    EVE_cmd_dl(DL_COLOR_RGB | bg);
    EVE_cmd_dl(TAG(tag));
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(mem_icon, fmt, w, h);
    EVE_cmd_dl(VERTEX2F(x, y));
    EVE_cmd_dl(DL_END);
    EVE_cmd_dl(TAG(0));
}

von Vladislav N. (vladineufeld)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Rudolph,

ich würde mich freuen, wenn du mir weiterhelfen würdest.

Ich programmiere aktuell das EVE 3 7 Zoll Touchdisplay von Riverdi mit 
einem Nucleo STM32 Board. Dafür benutze ich die von Riverdi zur 
Verfügung gestellte Bibliothek in C.

Ich habe den EIndruck, dass ich leider das noch nicht ganz genau mit dem 
FIFO vom Grafikcontroller verstanden habe.

Jedenfalls habe ich mir folgenden Demo-Code gemacht:

        Gpu_CoCmd_Dlstart(phost);
        App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
        App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
        App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
        App_WrCoCmd_Buffer(phost, VERTEX2II(220, 110, 26, 'T'));
        App_WrCoCmd_Buffer(phost, VERTEX2II(244, 110, 26, 'E'));
        App_WrCoCmd_Buffer(phost, VERTEX2II(270, 110, 26, 'X'));
        App_WrCoCmd_Buffer(phost, VERTEX2II(299, 110, 26, 'T'));

        App_WrCoCmd_Buffer(phost, END());

        App_WrCoCmd_Buffer(phost, COLOR_RGB(160, 22, 22));
        App_WrCoCmd_Buffer(phost, POINT_SIZE(320));
        App_WrCoCmd_Buffer(phost, BEGIN(POINTS));
        App_WrCoCmd_Buffer(phost, VERTEX2II(192, 133, 0, 0));
        Gpu_CoCmd_Number(phost, 50, 100, 26,OPT_SIGNED, value);


   Gpu_CoCmd_Text(phost, 0,0, 26,0, "Hallo Welt");
   Gpu_CoCmd_Text(phost, 100,0, 26,0, "Hallo Welt");
   //Gpu_CoCmd_Text(phost, 200,0, 26,0, "Hallo Welt");
        //App_WrCoCmd_Buffer(phost, VERTEX2II(320, 110, 31, 'T'));

        App_WrCoCmd_Buffer(phost, END());
        App_WrCoCmd_Buffer(phost, DISPLAY());

        Gpu_Hal_WaitCmdfifo_empty(phost);
        App_Flush_Co_Buffer(phost);
        Gpu_CoCmd_Swap(phost);

Wenn ich den Code so ausführen lasse, dann sehe ich alle Elemente, die 
ich programmiert habe. Wenn ich jedoch eines der auskommentierten 
Befehle noch hinzufüge, bleibt der Bildschirm schwarz.

Weißt du, was das Problem sein könnte?

Mein erster Gedanke war, dass der FIFO voll ist. Das kann aber nicht 
sein, da das bei jedem Befehl gecheckt wird und so lange gewartet wird, 
bis genug Platz vorhanden ist und dann wird der Befehl erst 
reingeschrieben. Und ich habe es auch schon mit dem Debugger gecheckt: 
Es werden alle Befehle ausgeführt, nur rührt sich das Display nicht.

Viele Grüße

Vladi

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
JohnLemon schrieb:
> drawBitmap(MEM_ICON_WIFI, 130, 3, 25, 25, EVE_RGB565, 0, WHITE);

That is your issue: EVE_ARGB1555
When you direclty load truecolor .png images they load as RGB565 - no 
alpha channel.
Either convert the images to ARG1555 and load them with cmd_inflate or 
even better since you already have the Hermes board now, use ASTC 
directly from the SPI-FLASH.
For example 8x8 which would be "EVE_COMPRESSED_RGBA_ASTC_8x8_KHR".

EVE_cmd_setbitmap(0x800000 | (adr_in_flash / 32), 
EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, sizex, sizey);

von Rudolph R. (rudolph)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vladislav N. schrieb:
> ich würde mich freuen, wenn du mir weiterhelfen würdest.

Ich kann es versuchen, aber...


> Ich programmiere aktuell das EVE 3 7 Zoll Touchdisplay von Riverdi mit
> einem Nucleo STM32 Board. Dafür benutze ich die von Riverdi zur
> Verfügung gestellte Bibliothek in C.

...ich habe weder richtig Erfahrung mit den Nucleo Boards, noch bin ich 
ein Freund der ersten Library von FTDI.
Einer der Gründe warum ich meine eigene Library geschrieben habe war, 
dass mich der Code von FTDI so gar nicht überzeut hat.

Die erste Frage wäre ja mal, welcher STM32?
Für die F4xx habe ich ja schon Support eingebaut und auch ein PlatformIO 
Projekt dazu das zumindest mal baut.

Vladislav N. schrieb:
> Ich habe den EIndruck, dass ich leider das noch nicht ganz genau mit dem
> FIFO vom Grafikcontroller verstanden habe.

Ich habe mir mal erlaubt ein .pdf von Crystalfontz anzuhängen, das 
findet sich in den Datenblättern von deren Displays.
Das ist zwar für die EVE2, aber ich fand das schon sehr anschaulich.

Vladislav N. schrieb:
> Weißt du, was das Problem sein könnte?

Das ist es, nur die beiden auskommentierten Zeilen?

Naja, das erste ist mal, BEGIN und END gehören Paar-weise zusammen.
 App_WrCoCmd_Buffer(phost, BEGIN(POINTS));
 App_WrCoCmd_Buffer(phost, VERTEX2II(192, 133, 0, 0));
 Gpu_CoCmd_Number(phost, 50, 100, 26,OPT_SIGNED, value);
 App_WrCoCmd_Buffer(phost, END());

Und dann ist die Zeile
 //App_WrCoCmd_Buffer(phost, VERTEX2II(320, 110, 31, 'T'));
so komplett aus dem Kontext gerissen.
Ohne das
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
machen VERTEX2II und VERTEX2F gar nichts.

Das VERTEX2II soll ja ein Bild anzeigen, 31 ist das Bitmap-Handle, 
vorbelegt durch einen Zeichensatz.
Und 'T' ist die Nummer 84, das 84. Bild aus dem Set, auch Zelle genann 
oder eben "cell".

Vladislav N. schrieb:
> Mein erster Gedanke war, dass der FIFO voll ist.

Der FIFO hat 4k, so leicht bekommt man den nicht voll. :-)

von Vladislav N. (vladineufeld)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Datei. Die ist hilfreich!

Ich habe das Nucleo f20zfg (STM32 f2xx).

Ja wenn ich weiterhin nicht klar komme mit der Bibliothek, werde ich 
deine mal versuchen. Nur dann müsste ich den Code nochmal auf f2xx 
anpassen.

Ah ok ja stimmt das mit dem VERTEX Zeile ist wirklich ohne Zusammenhang 
^^
Aber das ist nicht das Problem. Diese auskommentierte Zeile können wir 
ruhig ganz ignorieren. Aber das Problem ist: Sobald ich das dritte 
"Hallo Welt" einkommentiere, dann wird gar nichts mehr angezeigt. Wenn 
ich das weglasse, dann werden die anderen Befehle problemlos angezeigt.

Was genau hat dir eigentlich nicht gefallen an der Bridgetek Bibliothek?

von Rudolph R. (rudolph)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vladislav N. schrieb:
> Ja wenn ich weiterhin nicht klar komme mit der Bibliothek, werde ich
> deine mal versuchen. Nur dann müsste ich den Code nochmal auf f2xx
> anpassen.

Das habe ich gerade mal versucht und ein PlatformIO Projekt dafür 
aufgesetzt, analog zu dem F407 Projekt das ich schon hatte.

So wie es aussieht ist das HAL für den STM32F2xx komplett gleich zu 
benutzen wie das für den F4xx.

Ich habe in der EVE_target.h einfach nur den Block für den STM32F4 
kopiert und die Includes geändert.
Die größte Herausforderung war jetzt das richtige Define zu finden.
Die PlatformIO Board Dateien sind da hilfreich und so habe ich für das 
Nucleo_F207ZG schliesslich "#if defined (STM32F207xx)" gewählt.

Da müssen jetzt nur noch die Pins richtig angegeben werden.

Und wie beim letzten Projekt hier weiter oben, die main.c ist praktisch 
leer, das funktioniert so nicht, das ist nur um zu schauen ob es 
compiliert!

Warning This does compile but main.c does not work the way it is now!



Und schlau wäre auch in der EVE_target.c noch die entsprechenden 
Funktionen einzubauen um DMA machen zu können.
Nur benutze ich eben keine STM32 und zur Verfügung gestellt hat das 
bisher auch niemand.



Vladislav N. schrieb:
> Aber das Problem ist: Sobald ich das dritte
> "Hallo Welt" einkommentiere, dann wird gar nichts mehr angezeigt.

Hast Du das mit dem BEGIN/END denn gefixt?



Vladislav N. schrieb:
> Was genau hat dir eigentlich nicht gefallen an der Bridgetek Bibliothek?

Boah, so viele Ding und zu lange her. :-)
Aber wenn Du Dir nur mal die Zeilen ansiehst die Du gepostet hast, da 
taucht überall als Parameter "phost" auf.
Davon halte ich soweit gar nichts, das ist nämlich gar nicht für die 
Verwendung mit einem Mikro-Controller gedacht.
Anstatt das jedesmal wieder und komplett redundant zu übergeben habe ich 
den entscheidenden Parameter "cmdOffset" zu einer globalen Variable 
gemacht die auch absichtlich nur in der EVE_commands.c drin ist und 
nicht über die EVE_commands.h exportiert wird.

Und das ständige checken und noch mal checken des FIFOs bremst das ganz 
gut aus.

Meine Implementierung mag nicht ganz so robust sein, zum Beispiel könnte 
man den FIFO zu voll machen wenn man die Display-Liste erzeugt.
Aber wenn man das im Blick hat ist das komplett beherrschbar und so wie 
ich das implementiert habe deutlich schneller.
Das kostet ein paar kB extra, zugegeben.

Siehe auch das hier: http://www.brtcommunity.com/index.php?topic=100.0
Die neue "Portable MCU Library for EVE", beschrieben in BRT_AN_025 
gefällt mir deutlich besser als die erste Library von FTDI.
Wenn es das damals schon gegeben hätte, hätte ich meine Version 
vielleicht gar nicht angefangen.
Nur ist mein Code aktuell mit dem gleichen Controller eine ganze Ecke 
schneller.

Das was Riverdi in der Bibliothek gemacht hat ist auch deutlich 
aufgeräumter als die erste Implementierung von FTDI, viel leichter zu 
verstehen was da überhaupt passiert.
Ich bin allerdings sehr sicher, dass das langsamer läuft als meine 
Version.

von Vladislav N. (vladineufeld)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dankeschön,das hört sich gut an. Ich habe bislang noch nichts von 
PlatformIO gehört. Müsste mal ein neues Projekt in CubeIDE erstellen und 
die Dateien einfügen.

Ich habe jedenfalls gerade das Problem "behoben". Es sind gerade ganz 
verrückte Sachen passiert. Ich habe den Eindruck, der Grafikcontroller 
führt ein Eigenleben...

Ich bin auf die Idee gekommen, den Befehl 
Gpu_Hal_WaitCmdfifo_empty(phost) auszukommentieren. Dann hat die Anzeige 
plötzlich wie gewünscht geklappt. Auch etliche weitere Befehle wurden 
hinzugefügt und auch die problemlos angezeigt. Dann wollte ich mal beide 
Varianten mit dem Debugger vergleichen und mir den Befehl der wartet, 
bis der FIFO abgearbeitet wurde, genauer anschauen. Plötzlich ging die 
Anzeige auch als ich den Befehl einkommentiert hatte. Dann habe ich noch 
ein paar weitere Male das Programm draufgeflasht und alles war gut trotz 
des Befehls. Dann habe ich mal die Versorgungsspannung an und aus 
gemacht und dann ging es mit dem Befehl wieder nicht... oh ja Embedded 
Systeme sind manchnmal ganz komisch...
Jedenfalls denke ich, dass das nun der Fehler ist: Lieber 
Gpu_Hal_WaitCmdfifo_empty(phost) weglassen. Auch wenn ich nicht verstehe 
warum... Was ist das Problem? Dann wartet er eben noch bis der FIFO 
abgearbeitet wurde und erst dann wechselt er die Displayliste. Das war 
ja jetzt keine zeitkritisches Beispiel...(das Programm hat sich ja nie 
aufgehangen in ner Endschlosschleife, sondern wurde immer ganz 
durchgeführt.) Hast du als erfahrener Programmierer eine Erklärung? :D

Abgesehen davon: Warum wird eigentlich vom Hersteller im Datenblatt 
empfohlen, nicht direkt in die Displayliste zu schreiben, sondern den 
Umweg über den Co-Prozessor zu machen?
Was diesbezüglich komisch ist: Bei so einem Beispielprogramm von Riverdi 
wo ein Bildschirmschoner realisiert wurde (Ball baumelt von Ecke zu 
Ecke) haben die das nur mit direkten Befehlen in die DL gemacht...

Eine weitere Frage hätte ich auch noch: In der Riverdi Bibliothek kann 
man mit einem define auch noch eine "BUFFER_OPTIMIZATION" hinzuschalten. 
Ich habe mir mal den Code angeguckt und wenn man das aktiviert, dann 
werden die Befehle für den Co-Prozessor bzw. die DL-Befehle in einem 
extra Buffer gespeichert. Ich habe dir mal die entscheidenden vier 
Funktionen als Code im Anhang gepackt. Und mit den Befehlen 
App_Flush_Co_Buffer(phost); bzw App_Flush_DL_Buffer(phost); wird der 
Buffer dann komplett in RAM_CMD bzw. RAM_DL geschrieben. Wenn man das 
nicht aktiviert hat, dann wird jeder Befehl sofort in RAM_CMD bzw. 
RAM_DL geschrieben. Aber das komische ist: Wenn man diese Funktion 
aktiviert hat, dann passiert beides: Also dann wird beispielsweise durch 
den Befehl App_WrCoCmd_Buffer(Gpu_Hal_Context_t *phost,uint32_t cmd) 
sowohl der Buffer mit dem CMD gefüllt als auch sofort der CMD in RAM_CMD 
geschrieben. Und wenn man am Ende dann auch noch 
App_Flush_Co_Buffer(phost) schreibt, dann sind die Befehle ja doppelt in 
RAM_CMD.Einmal erst durch das direkte schreiben und danach nochmal nach 
schreiben des Buffer Inhalts. Ich weiß nicht ob das so gewollt? Eher 
nicht. Oder sollte man wenn man die BUFFER_OPTIMIZATION macht dann den 
anderen Codeteil der den Befehl direkt in den Speicher schreibt 
weglassen?
Was ich noch nicht erwähnt habe: Wenn man die die Funktion zuschaltet, 
dann wird auch geprüft, ob der Buffer schon voll ist. Wenn ja dann wird 
der komplette Inhalt direkt in den Speicher geschrieben

Jedenfalls liefen bei mir deren Demos stabiler als ich die 
BUFFER_OPTIMIZATION hinzugeschaltet habe (ohne hat es geflackert und mit 
gab es dann kein Flackern mehr).

Eine andere Sache noch:
Ich habe mit folgendem Programm, welches in der main() in der 
Dauerschleife läuft, versucht einfach mal die Touchkordinaten und den 
Tag Wert auf dem Bildschirm anzuzeigen:

void touchVersuch(Gpu_Hal_Context_t *phost, uint8_t* p_currTag, 
uint16_t* p_x_pos, uint16_t* p_y_pos)
{
  uint8_t tag = App_Touch_Update(phost, p_currTag, p_x_pos, p_y_pos);
  *p_currTag = tag;
  Gpu_CoCmd_Dlstart(phost);
  App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
  App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
  Gpu_CoCmd_Number(phost, 0, 0, 26 ,OPT_SIGNED,*p_x_pos);
  Gpu_CoCmd_Number(phost, 0, 20, 26 ,OPT_SIGNED,*p_y_pos);
  Gpu_CoCmd_Number(phost, 0, 40, 26 ,OPT_SIGNED,*p_currTag);
  App_WrCoCmd_Buffer(phost, DISPLAY());
  //Gpu_Hal_WaitCmdfifo_empty(phost);
  App_Flush_Co_Buffer(phost);
  Gpu_CoCmd_Swap(phost);
}


Aber leider läuft das kaum. Nur zufällig mal. Mal kann ich mir die X 
Koordinaten anzeigen aber nach ner Zeit hängt es sich auf. Manchmal 
kommt direkt ein starres Bild, was sich durch Touch nicht mehr ändert. 
X- und Y Werte zusammen aktuallisieren klappt nie.
Weißt du das Problem?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Um das noch mal zu erwähnen, ich bin für die Merkwürdigkeiten in der 
FTDI Library und auch der Variante davon von Riverdi ein wenig der 
falsche Ansprechpartner. :-)

PlatformIO, vor allem in Kombination mit VScode ist enorm praktisch um 
"mal eben schnell" ein Projekt für zig verschiedene Platformen 
aufzusetzen.
Zumindest solange es eine passende Board-Definition gibt.
CubeIDE habe ich gar nicht - und auch gar keine Verwendung dafür, weil 
ich mit den STM32 eben nichts anfangen kann.
Aber das Projekt da oben hat "stm32cube" als Framework.


Das mit dem Auskommentieren von Gpu_Hal_WaitCmdfifo_empty() ist 
merkwürdig.
Wie oft rufst Du den Display-Code eigentlich auf?
Das muss schon seltener passieren als die Bildrate vom Display ist.

Vladislav N. schrieb:
> Abgesehen davon: Warum wird eigentlich vom Hersteller im Datenblatt
> empfohlen, nicht direkt in die Displayliste zu schreiben, sondern den
> Umweg über den Co-Prozessor zu machen?

Wird das wirklich irgendwo empfohlen?
Der Co-Prozessor kann auf jeden Fall mehr und man muss auch weniger 
Daten übertragen, viele einfache Kommandos werden in mehrere Befehle in 
der Display-Liste zerlegt.

Spiel mal mit dem EVE Screen Editor.
Wenn Du da was von links in den Bildschirm ziehst, etwa ein "Text" dann 
taucht unten dazu auf was in den Co-Prozessor FIFO geschrieben wird.
Schaltet man dann den Tab unten auf "Inspector" um so sieht man was der 
Co-Prozessor da draus für Display-Listen Befehle macht.
Ein "einfacher" Button ist im Ergebnis doch ganz nett komplex.

Vladislav N. schrieb:
> Eine weitere Frage hätte ich auch noch: In der Riverdi Bibliothek kann
> man mit einem define auch noch eine "BUFFER_OPTIMIZATION" hinzuschalten.

Eigentlich nützlich ist sowas um den erzeugten Puffer dann anschliessend 
per DMA zu übertragen.
Optimiert ist das so in dem Sinne nur dadurch, dass beim Erzeugen des 
Puffers nicht auf das Ende der SPI-Übertragung gewartet wird.
Aber ob man nun Kommando-SPI-Kommando-SPI oder Kommando-Kommando SPI-SPI 
auführt ändert in Summe ja nichts an der Ausführungszeit.

Vladislav N. schrieb:
> Aber das komische ist: Wenn man diese Funktion
> aktiviert hat, dann passiert beides: Also dann wird beispielsweise durch
> den Befehl App_WrCoCmd_Buffer(Gpu_Hal_Context_t *phost,uint32_t cmd)
> sowohl der Buffer mit dem CMD gefüllt als auch sofort der CMD in RAM_CMD
> geschrieben.

Okay, das ist Unsinn, mit der Option an sollten die Kommandos nicht mehr 
direkt auf den SPI schreiben.

Vladislav N. schrieb:
> void touchVersuch(Gpu_Hal_Context_t *phost, uint8_t* p_currTag,
> uint16_t* p_x_pos, uint16_t* p_y_pos)
> {
>   uint8_t tag = App_Touch_Update(phost, p_currTag, p_x_pos, p_y_pos);
>   *p_currTag = tag;
>   Gpu_CoCmd_Dlstart(phost);
>   App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
>   App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
>   Gpu_CoCmd_Number(phost, 0, 0, 26 ,OPT_SIGNED,*p_x_pos);
>   Gpu_CoCmd_Number(phost, 0, 20, 26 ,OPT_SIGNED,*p_y_pos);
>   Gpu_CoCmd_Number(phost, 0, 40, 26 ,OPT_SIGNED,*p_currTag);
>   App_WrCoCmd_Buffer(phost, DISPLAY());
>   //Gpu_Hal_WaitCmdfifo_empty(phost);
>   App_Flush_Co_Buffer(phost);
>   Gpu_CoCmd_Swap(phost);
> }

Das verwirrt mich jetzt doch mal, ich benutze das ja selber nie.
Aber ist das wirklich richtig, dass das "App_WrCoCmd_Buffer" mit 
"Gpu_CoCmd_Number" vermischt wird?
Muss wohl so, aber konsistent ist sowas nicht gerade.

Auf jeden Fall ist "App_Touch_Update()" wohl eher nicht so hilfreich.
Da passiert doch einfach mal zu viel drin.

Hilfreicher wäre da:
Gpu_Hal_Rd8(phost,REG_TOUCH_TAG);

Nur dazu müsstest Du in der Display-Liste überhaupt mal einen Touch-Tag 
vergeben und in dem Ausschnitt ist nichts.

Ohne Touch-Tag wäre das hier besser:
Gpu_Hal_Rd32(phost, REG_TOUCH_SCREEN_XY);

Und einfach mal mit cmd_number ausgeben.
void touch_test(Gpu_Hal_Context_t *phost)
{
 uint32_t koordinaten = Gpu_Hal_Rd32(phost, REG_TOUCH_SCREEN_XY);

 Gpu_CoCmd_Dlstart(phost);
 App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
 App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
 Gpu_CoCmd_Number(phost, 20, 20, 28 , 0, koordinaten);
 App_WrCoCmd_Buffer(phost, DISPLAY());
 Gpu_CoCmd_Swap(phost);
 App_Flush_Co_Buffer(phost);
 Gpu_Hal_WaitCmdfifo_empty(phost);
}

Mir ist da am Ende noch aufgefallen das die Reihenfolge von 
App_Flush_Co_Buufer und Gpu_Hal_WaitCmdfifo_empty falsch herum war.
Und nachdem ich jetzt meinen Code eingefügt habe, habe ich noch die 
Position von dem SWAP Kommando verändert.


Bei mir würde das so aussehen:
void TFT_display(void)
{
 uint32_t koordinaten;

 koordinaten = EVE_memRead32(REG_TOUCH_SCREEN_XY);

 EVE_cmd_dl(CMD_DLSTART); /* start the display list */
 EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
 EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
 EVE_cmd_number(20, 20, 28, 0, koordinaten);
 EVE_cmd_dl(DL_DISPLAY);
 EVE_cmd_dl(CMD_SWAP); /* make this list active */
 EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */
}

So etwas vereinfacht, normalerweise habe ich da noch ein 
EVE_start_cmd_burst() / EVE_end_cmd_burst() Paar drum herum.

von Vladislav N. (vladineufeld)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ah ok das ist ja praktisch mit PlatformIO!

Ja vieleicht könnte das wirklich ein Problem bei mir sein mit dem 
Timing. Denn damit kenne ich mich noch nicht so gut aus.

Das hier ist der Code, der automatisch von der Entwicklungsumgebung 
erzeugt wurde zur für die SystemClockConfiguration:

RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  /** Initializes the CPU, AHB and APB busses clocks
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
  RCC_OscInitStruct.PLL.PLLM = 13;
  RCC_OscInitStruct.PLL.PLLN = 195;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 5;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /** Initializes the CPU, AHB and APB busses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != 
HAL_OK)
  {
    Error_Handler();
  }

Ich habe dann noch folgende paar Zeilen aus der Bibliothek von Riverdi 
inkludiert. Anschließend war die Anzeige stabiler (vorher war die 
Anzeige öfter mal zweigeteilt):

 /* configure the Systick interrupt time */
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

  /* configure the Systick */
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */
  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

   SystemCoreClock = 48000000; /* 48MHz */
   SystemCoreClockUpdate();

Also gehe ich maol davon aus, dass das Bild mit ner Frequenz von 48 MHz 
aktuallisiert wird.

So berechnet man dann die Bildrate des Displays:
800 x 480 = 384000  x 60 Hz x 24 Bit Auflösung = 552960000 Hz = 0,5 GHz

Der Aufruf ist also deutlich weniger als die Bildrate.
Oder habe ich jetzt irgendwas nicht verstanden?

Rudolph R. schrieb:
> Wird das wirklich irgendwo empfohlen?

Ja habe den Ausschnitt aus dem BT81x Programmierguide mal angehängt. 
Aber dort steht ja die Erklärung. Ist also nur eine Vorsichtsmaßnahme. 
Ah ok man hat also einfach mehr Möglichkeiten mit dem Co-Prozessor.

Später sollte ich mich auch mal mit DMA befassen. Aktuell ist es nicht 
in der Bib drinne aber habe gesehen, dass es von STM in der 
HAL-Bibliothek da Funktionen für gibt. Oder ich nutze deine Lib dann 
habe ich das schon :D Aber gut müsste bestimmt noch irgendwo mit den HAL 
Befehlen ergänzen.

Rudolph R. schrieb:
> Mir ist da am Ende noch aufgefallen das die Reihenfolge von
> App_Flush_Co_Buufer und Gpu_Hal_WaitCmdfifo_empty falsch herum war.
> Und nachdem ich jetzt meinen Code eingefügt habe, habe ich noch die
> Position von dem SWAP Kommando verändert.

Also das verstehe ich nicht, warum ist das falsch rum? Erst muss man 
doch die Anweisung geben, dass der Buffer in RAM_CMD geschrieben wird. 
Dann kann man mit Gpu_Hal_WaitCmdfifo_empty(phost); prüfen, ob das 
erledigt wurde (Also sind Lesezeiger REG_CMD_READ und Schreibzeiger 
REG_CMD_WRITE gleich ?). Und falls ja anschließend die Display Liste 
wechseln. Wo ist mein Denkfehler...?

Bist du dir sicher, dass der Code bei dir klappt mit dem Register 
REG_TOUCH_SCREEN_XY?
Bei mir hat es leider nicht funktuioniert. Also prinzipiell schon wenn 
man durchdebuggt. Aber nach ein paar Durchläufen hängt sich der Code auf 
nach dem Befehl: App_Flush_Co_Buffer(phost); Aber paar mal konnte ich 
wirklich den Registerwert auslesen und das wurde nach dem Swap Befehl 
dann angezeigt auf dem Display beim Debuggen. Scheint irgendein Problem 
mit dem Timing wohl zu geben...

Ja als nächstes werde ich mich mal mit dem EVE Screen Designer vertraut 
machen.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Vladislav N. schrieb:
> Das hier ist der Code, der automatisch von der Entwicklungsumgebung
> erzeugt wurde zur für die SystemClockConfiguration:

Ja nun, ich habe gar keinen STM32. :-)

Vladislav N. schrieb:
> SystemCoreClock = 48000000; /* 48MHz */
>    SystemCoreClockUpdate();
>
> Also gehe ich maol davon aus, dass das Bild mit ner Frequenz von 48 MHz
> aktuallisiert wird.

Da draus geht bestenfalls hervor, dass Dein Controller mit 48MHz 
getaktet ist.
Kann man machen, nur läuft der STM32F207 mit bis zu 120 MHz.

>So berechnet man dann die Bildrate des Displays:
>800 x 480 = 384000  x 60 Hz x 24 Bit Auflösung = 552960000 Hz = 0,5 GHz

Äh, nein, die Bildrate wären die 60 Hz.
Aber die Bildrate sind auch nicht 60Hz, die ergeben sich aus dem 
Pixel-Clock.
Bei mir steht PCLK für dieses Display auf 2 und mit meiner Library sind 
das 36Mhz.
Wenn Riverdi da auch den Wert von 2 benutzt sind das entweder 30MHz oder 
eben auch 36MHz, je nachdem ob sie den Takt passend zu den BT81x 
einstellen.
Nun hat so ein Display nicht 800x480, das hat 1056 HCYCLE und 525 
VCYCLE.
Die Bildrate beträgt also so 65 Hz oder 54 Hz.
-> Zwischen zwei Updates sollten mindestens  18,5 ms sein.

Meine Software aktualisiert das alle 20 ms.

Interessant wäre an der Stelle dann auch noch, wie schnell überhaupt der 
SPI läuft.
Beim Init muss der nämlich langsamer als 11 MHz sein, danach darf der 
bis zu 30 MHz haben, das muss man aber erstmal stabil hin bekommen.

Vladislav N. schrieb:
>> Wird das wirklich irgendwo empfohlen?
>
> Ja habe den Ausschnitt aus dem BT81x Programmierguide mal angehängt.
> Aber dort steht ja die Erklärung. Ist also nur eine Vorsichtsmaßnahme.

Ah okay, das ist nur Quatsch, so wie das formuliert ist.
Der Co-Prozessor schreibt ja nicht einfach so aus Jux in die 
Display-Liste.
Richtiger wäre, dass es gefährlicher wird wenn man beides gleichzeitig 
versucht.

Vladislav N. schrieb:
> Also das verstehe ich nicht, warum ist das falsch rum? Erst muss man
> doch die Anweisung geben, dass der Buffer in RAM_CMD geschrieben wird.
> Dann kann man mit Gpu_Hal_WaitCmdfifo_empty(phost); prüfen, ob das
> erledigt wurde (Also sind Lesezeiger REG_CMD_READ und Schreibzeiger
> REG_CMD_WRITE gleich ?). Und falls ja anschließend die Display Liste
> wechseln. Wo ist mein Denkfehler...?

Nun ja, und wo wird dann auf die Ausführung von dem CMD_SWAP gewartet?

Die spannende Frage dazu ist schon mal, was macht App_Flush_Co_Buffer() 
eigentlich?

void App_Flush_Co_Buffer(Gpu_Hal_Context_t *phost)
{
#ifdef  BUFFER_OPTIMIZATION
    if (CmdBuffer_Index > 0)
    Gpu_Hal_WrCmdBuf(phost,CmdBuffer,CmdBuffer_Index);
#endif
    CmdBuffer_Index = 0;
}

So normalerweise, ohne diese "Buffer Optimisation" macht das praktisch 
garnichts weiter. Es wird auch automatisch jedes einzelne Kommando 
ausgeführt -> Handbremse.
Aber mit der "Buffer Optimisation" ist das der Befehl mit dem der 
CMD-FIFO beschrieben und das dann ausgeführt wird.
Lustigerweise beinhaltet das übrigens auch das Warten.

void Gpu_Hal_WaitCmdfifo_empty (Gpu_Hal_Context_t *host)
{
  while(Gpu_Hal_Rd16(host,REG_CMD_READ) != 
Gpu_Hal_Rd16(host,REG_CMD_WRITE));

  host->cmd_fifo_wp = Gpu_Hal_Rd16(host,REG_CMD_WRITE);
}

Okay, das macht was ich erwartet habe, wenn auch eher nicht so prall.
Wenn man REG_CMD_WRITE schon beschreibt weil man besser auch trackt wo 
der steht, dann muss man den  nicht lesen.
Und wenn man den schon liest, dann reicht einmal völlig aus...

In einem Beispiel von Riverdi habe ich das aber auch gerade so gefunden:
 App_WrCoCmd_Buffer(phost, DISPLAY());
 Gpu_CoCmd_Swap(phost);
 App_Flush_Co_Buffer(phost);
 Gpu_Hal_WaitCmdfifo_empty(phost);

Also das gehört schon so herum.

Vladislav N. schrieb:
> Bist du dir sicher, dass der Code bei dir klappt mit dem Register
> REG_TOUCH_SCREEN_XY?

Ja, habe ich gerade mal ausprobiert.
Allerdings habe ich dabei noch festgestellt, dass dem CMD_NUMBER noch 
eine Farbe fehlt:
 EVE_cmd_dl(DL_COLOR_RGB | BLACK);
 EVE_cmd_number(20, 20, 28, 0, koordinaten);

Und die Anzeige ist so alles anderes als nützlich, das gibt nur eine 
dicke Zahl.
Als Hex-Werte wäre das hilfreicher, oder eben wenn man die X/Y 
Koordinaten da raus zieht und getrennt ausgibt.
void TFT_display(void)
{
 uint32_t koordinaten;
 uint16_t x_koord, y_koord;

 koordinaten = EVE_memRead32(REG_TOUCH_SCREEN_XY);
 x_koord = (koordinaten >> 16);
 y_koord = koordinaten;

 EVE_cmd_dl(CMD_DLSTART);
 EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
 EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
 EVE_cmd_dl(DL_COLOR_RGB | BLACK);
 EVE_cmd_number(20, 20, 28, 0, x_koord);
 EVE_cmd_number(20, 40, 28, 0, y_koord);
 EVE_cmd_dl(DL_DISPLAY);
 EVE_cmd_dl(CMD_SWAP);
 EVE_cmd_start();
}

Das zeigt mir zwei Zahlen auf dem Display an, in Ruhe jeweils 32768 oder 
auch 0x8000 wie es im Programming-Manual steht.

Und wenn ich mit dem Finger über das Display gehen werden mir die 
Koordinaten angezeigt.
Das hat mich auch gerade darauf gebracht das mein Display schlecht 
kalibriert ist.
Ich habe einen leichten Versatz nach Rechts und etwas mehr nach Oben.

von Vladislav N. (vladineufeld)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Puhh ich habe das mit den unterschiedlichen Clocks nun mal versucht 
nachzuvollziehen um PCLK herauszufinden und habe leider noch einiges an 
Verständnisproblemen.

Ich habe mal den Code und nachvollzogen und dort wird eine externe 
Quelle  als Taktversorgung eingesetzt(Weiß ich jetzt nicht, warum 
Riverdi nicht den internen relaxation oscillator clock benutzt).

Hier ist der Befehl:
Gpu_HostCommand(phost,GPU_EXTERNAL_OSC);

der ist mit 44h hinterlegt. Der Host Command 44h ist zum Festlegen der 
PLL.
"Select PLL input from external crystal oscillator or external input 
clock."

Laut Datenblatt kann man nur externe Quellen mit 12 MHz wählen, also 
gehe ich davon aus, dass die PLL nun 12 MHz ist.

Nun verstehe ich den Host Befehl CLKSEL nicht. Wann benutzt man denn 61h 
und wann 62h für das erste Byte?

Die benutzen bei der Initialisierung folgende Zeile:
Gpu_HostCommand(phost,GPU_PLL_48M)

GPU_PLL_48M ist mit 62h hinterlegt, also wird 620000h gesendet

Warum durch diesen Befehl die PLL auf 48 MHz setzen soll (so entnehme 
ich das dem typedef) erschließt sich mir nicht. Im Anhang ist die 
Bedeutung der Bits in Byte 2 zu sehen. Die sind ja alle 0.

"For compatibility to FT800/FT801, set Byte2 to 0x00. This will set the 
PLL clock back to default (60 MHz)"

Also laut dem Zitat wird die "PLL" auf 60 MHz gesetzt. Und nicht auf 48 
MHz?

Aber die eigentliche Funktion deises Befehl ist es ja, den Systemtakt 
festzulegen:
"Select the system clock frequency. Note that software shall also update 
the register value for REG_FREQUENCY to align with system clock 
selected."


In der Library habe ich auch noch folgende Funktion gefunden (die aber 
bei der Initialisierung nicht benutzt wurde):

Gpu_81X_SelectSysCLK (Gpu_Hal_Context_t  *host,
                      GPU_81X_PLL_FREQ_T  freq)
{
  if(GPU_SYSCLK_72M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x40 << 8) | (0x06 << 
8));
  else if(GPU_SYSCLK_60M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x40 << 8) | (0x05 << 
8));
  else if(GPU_SYSCLK_48M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x40 << 8) | (0x04 << 
8));
  else if(GPU_SYSCLK_36M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x03 << 8));
  else if(GPU_SYSCLK_24M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x02 << 8));
  else if(GPU_SYSCLK_DEFAULT == freq)
    Gpu_HostCommand_Ext3(host, 0x61);
}

Da sie nicht benutzt wurde, gehe ich mal davon aus, dass der Systemtakt 
60 MHz ist.

In das Register REG_PCLK schreiben Sie in der Initialisierung den Wert 2 
rein, also denke ich mal, dass PCLK 30 MHz ist.


Rudolph R. schrieb:
> Die Bildrate beträgt also so 65 Hz oder 54 Hz.

Wie hast du die Bildrate berechnet?

Rudolph R. schrieb:
> Meine Software aktualisiert das alle 20 ms.

In welchem Teil deiner Library kann man das sehen, wie du das 
eingestellt hast?

Rudolph R. schrieb:
> Interessant wäre an der Stelle dann auch noch, wie schnell überhaupt der
> SPI läuft.
> Beim Init muss der nämlich langsamer als 11 MHz sein, danach darf der
> bis zu 30 MHz haben, das muss man aber erstmal stabil hin bekommen.

Woher hast du die Info, dass er langsamer als 11 MHz sein muss? Also du 
meinst bei der Initialisierung des Chips oder?

Ich habe jetzt übrigens mal diese

Vladislav N. schrieb:
> /* configure the Systick interrupt time */
>   HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
>
>   /* configure the Systick */
>   HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
>
>   /* SysTick_IRQn interrupt configuration */
>   HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
>
>    SystemCoreClock = 48000000; /* 48MHz */
>    SystemCoreClockUpdate();

Ich habe überigens diese Befehle nun rausgenommen. Plötzlich 
funktionieren die Beispiele von Riverdi es auch ohne diese Befehle 
stabil. Also jetzt habe ich nur den Code für sie System Clock 
Configuration der automatisch von der IDE erzeugt wurde (Da werden dann 
auch die 120 MHZ benutzt :D)

Die Einstellungen des SPI habe ich graphisch über die IDE gemacht und da 
habe ich den Baudraten prescaler auf 2, was einer Baudrate von 30 Mbit/s 
entspricht. Die haben da nach so ein Beispiel wo das Bridgetek Logo 
angezeigt wird. Das läuft mit den 30 Mhz nicht ganz stabil. Da Habe ich 
herausgefunden, dass ein prescaler von 4 besser ist, also 15 MHz.

Aber mit beiden Frequenzen funktioniert das nicht mit der stabilen 
Anzeige der X und Y-Werte.

Es wird wohl bestimmt daran liegen, dass ich mir bislang noch gar keine 
Gedanken dazu gemacht habe, wie oft das Display aufgerufen wird und wie 
oft der Code in der Main aufgerufen wird. Erstmal wäre gut zu wissen, 
was für eine Bildrate eingestellt ist.
Und wie realisiere ich das, wie oft ein Code in der Main aufgerufen 
werden soll? Dafür muss ich mich wahrscheinlich über Timer informieren 
und dann vor den Code eine If Bedingung mit einer Timing Variablen 
machen und immer wenn der Timer die Variable setzt, dann erst den Code 
ausführen? (So wie du das in deiner Main gemacht hast). Aktuell wird der 
Code ja einfach wahrscheinlich mit den 120 MHz abgearbeitet und das ist 
ja viel schneller als die Bildrate...

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Vladislav N. schrieb:
> Ich habe mal den Code und nachvollzogen und dort wird eine externe
> Quelle  als Taktversorgung eingesetzt(Weiß ich jetzt nicht, warum
> Riverdi nicht den internen relaxation oscillator clock benutzt).

Naja, sie haben eben einen Quarz auf der Platine und mit diesem ist der 
Takt etwas stabiler.

Vladislav N. schrieb:
> Da sie nicht benutzt wurde, gehe ich mal davon aus, dass der Systemtakt
> 60 MHz ist.
>
> In das Register REG_PCLK schreiben Sie in der Initialisierung den Wert 2
> rein, also denke ich mal, dass PCLK 30 MHz ist.

Gut, das passt.

Vladislav N. schrieb:
>> Die Bildrate beträgt also so 65 Hz oder 54 Hz.
>
> Wie hast du die Bildrate berechnet?

30MHz / (1056 * 525) = 54,112554

Du hast bei Dir in der Formel noch 24 Bit Auflösung mit drin gehabt.
Die Daten werden allerdings parallel übertragen, nicht seriell.

Vladislav N. schrieb:
>> Meine Software aktualisiert das alle 20 ms.
>
> In welchem Teil deiner Library kann man das sehen, wie du das
> eingestellt hast?

In gar keinem, das ist Teil meiner Anwendung.
Die beiden Beispiele die ich auf Github habe machen das.
In dem ATSAMC21 Beispiel wird der Systick-Timer für einen 5 ms Interrupt 
verwendet damit die Hauptschleife nur alle 5 ms durchlaufen wird.
Und alle vier Durchläufe wird TFT_display() aufgerufen.
In dem Arduino Beispiel mache ich das gleiche, nur benutze ich da 
millis() um die Hauptschleife nur alle 5 ms auszuführen.

https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/example_projects/EVE_Test_SAMC21_FT813_EVE2-35G/main.c

Vladislav N. schrieb:
> Woher hast du die Info, dass er langsamer als 11 MHz sein muss? Also du
> meinst bei der Initialisierung des Chips oder?

Ja, bei der Initialisierung des Chips.

Und das ist eine interessante Frage.
Im "FT800 Programmers Guide.pdf" steht noch im Kapitel 2.2.5: "Use MCU 
SPI clock not more than 11MHz".
Und im Kapitel 4.2.3 vom "DS_FT800.pdf" steht:
"If SPI is used as host interface, the SPI clock shall not exceed 11MHz 
before system clock is
enabled. After system clock is properly enabled, the SPI clock is 
allowed to go up to 30MHz."
Im Datenblatt vom FT81x findet sich das nicht mehr.
Im "FT81X_Series_Programmer_Guide_1.2.pdf" steht das im Kapitel 2.3 auch 
nicht mehr explizit drin, das Beispiel hat aber noch die Zeilen dafür.
Und im Kapitel 2.4 vom 
"BRT_AN_033_BT81X_Series_Programming_Guide_1.1.pdf" taucht nicht mal 
mehr das auf.

Hmm, interessant, sich daran zu halten ist jetzt nicht in dem Sinne 
falsch, aber scheinbar schon seit den FT81x so nicht mehr notwendig.

Das habe ich gerade mal ausprobiert.
Bis 17 MHz SPI Takt hoch kann ich den BT815 starten lassen.
Da drüber klappt es aber nur nicht mehr so richtig, weil ich noch ein 
Problem mit dem MISO habe und dann nur noch Murks über die Leitung 
kommt.
Mit 17MHz SPI Takt bleiben die X/Y Koordinaten auch nicht fest auf 
32768, da sind ständig Bit-Kipper drin.

Vladislav N. schrieb:
> Es wird wohl bestimmt daran liegen, dass ich mir bislang noch gar keine
> Gedanken dazu gemacht habe, wie oft das Display aufgerufen wird und wie
> oft der Code in der Main aufgerufen wird. Erstmal wäre gut zu wissen,
> was für eine Bildrate eingestellt ist.

(Sytem-Clock / PCLK) / (HCYLCE * VCYCLE)

Wobei man PCLK sinnigerweise so einstellt das sich in etwa 60 Hz 
ergeben.
Und nachdem ich das gerade in meine Excel-Tabelle für die 
Display-Parameter eingegeben habe, sollte ich vielleicht noch ein paar 
Parameter anpassen, da gerade viele von den kleinen Displays da deutlich 
drüber liegen.
Das EVE3-43G etwa das ich gerade benutze hat wie alle anderen 4.3" bei 
mir eine Einstellung von PCLK = 5, mit den 72MHz von dem BT815 macht das 
90Hz.
Ein PCLK = 7 und entsprechend 64 Hz wären sinnvoller.

Was man daran auch schön erkennen kann, die Framerate wird mit höheren 
Auflösungen zunehmend zum Problem, zumindest bis einschliesslich BT816.
Unter 2 sollte man gar nicht gehen, da EVE sonst Probleme bekommt die 
Pixel auch noch zu erzeugen.

Aber wenn man so eines wie das ADAM101 mit 1024x600 hat bei VCYCLE = 720 
und HCYCLE = 1100, da kommt man mit PCLK = 2 und den maximal 60 MHz des 
darauf verbauten FT813 eben nur auf 38 Bilder pro Sekunde.
Hätte das einen BT815 käme man wenigstens auf 45 FPS.

Deshalb gibt es auch (noch) keine EVE Displays mit etwa 1280x800.

von Vladislav N. (vladineufeld)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mich mal einbisschen recherchiert über die Möglichkeiten die 
man mit EVE hat. Dabei bin ich auf das Beispiel 4 von dieser Seite 
gestoßen:

https://www.ftdichip.com/Support/SoftwareExamples/FT800_Projects.htm

So eine Anzeige wäre ziemlich cool für meine Endanwendung.

Natürlich gibt es den Code zu diesen Beispielen aber nur für andere 
Zielplattformen. Das Application Layer und das EVE Layer sind aber 
nahezu identisch wie auch in der Riverdi Bibliothek.

Ich habe versucht, den Code von der Datei "App_Gauges.c" in mein Projekt 
zu integrieren. Kompilieren hat dann auch geklappt, jedoch funktioniert 
die Anwendung leider nicht auf meinem Display.

Erst habe ich die Variable prog_uchar8_t digits[] aus "App_Gauges.c" nur 
in uchar8_t geändert. Denn in deren "platform.h" war das hier zu finden: 
#define prog_uchar8_t  uchar8_t
Keine Ahnung, warum die das gemacht haben aber das sollte ja nicht das 
Problem sein.

Die hatten in Ihrer Bibliothek noch die Funktion
Gpu_Hal_WrCmdBufFromFlash(...) drinne, welche ich auch einfach noch in 
meine Gpu_hal.c hinzugefügt habe.

Außerdem waren in deren Hal.utils.c noch folgende defines die ich 
hinzugefügt habe:
#define pgm_read_byte_near(x)   (*(x))
#define pgm_read_byte(x)        (*(x))
#define random(x)    (rand() % (x))

Wenn ich durch den Code debugge, dann hängt er sich irgendwann bei einem 
Gpu_Hal_WaitCmdfifo_empty(phost); auf.

Vieleicht liegt es aber auch daran, dass ich mich bislang noch gar nicht 
mit dem Flash Speicher des Riverdi beschäftigt habe, dieses Beispiel 
aber offenbar auch was mit Flash zu tun hat (wegen der Funktion 
Gpu_Hal_WrCmdBufFromFlash ). Das ist der Code der Funktion:

void Gpu_Hal_WrCmdBufFromFlash(Gpu_Hal_Context_t *host,uchar8_t 
*buffer,uint32_t count)

 uint32_t length =0, SizeTransfered = 0, getfreespace;
    do {
        length = count;
        getfreespace = Gpu_Cmdfifo_Freespace(host);
        if (length > getfreespace){
            length = getfreespace;
        }
        Gpu_Hal_CheckCmdBuffer(host,length);

        Gpu_Hal_StartCmdTransfer(host,GPU_WRITE,length);


        SizeTransfered = 0;
        while (length--) {
            Gpu_Hal_Transfer8(host,pgm_read_byte_near(buffer));
            buffer++;
            SizeTransfered ++;
        }
        length = SizeTransfered;

        Gpu_Hal_EndTransfer(host);
        Gpu_Hal_Updatecmdfifo(host,length);

        Gpu_Hal_WaitCmdfifo_empty(host);

        count -= length;
    }while (count > 0);

Aber hier ist ja als Flash dieses großen Zahlenarray aus "App_Gauges.c" 
gemeint. Was nicht klar ist, warum Gpu_Hal_Transfer8 benuitzt wird (hier 
erwartet man auch noch eine Antwort von der GPU die aber nirgendswo 
gespeichert wird)

Dort ist auch noch eine Schriftartendatei "digits.fon" (siehe Anhang). 
Aber ich habe nirgendswo in deren Code gesehen, wo Sie diese benutzen. 
Weißt du, was man mit der machen muss?

Hast du ne Idee, wie man das Beispiel zum Laufen bringen könnte?

Noch ne andere Sache: Dieser EVE Screen Designer, bringt der mir 
irgendwas wenn ich nicht eine von den supporteten Zielplattformen 
benutze? Nach dem Anschauen des Guides habe ich eher festgestellt, dass 
ich keinen Mehrwert erschließen kann, da ich ja nur den C-Code für 
andere Platformen bekommen kann.

Im ESD sind zwei Widgets die evtl. auch für mich in Frage kommen könnten 
(siehe die letzten beiden Anhänge). Aber diese findest man nicht im 
Programmierguide. Weißt du, wie es mir möglich wäre, diese Widgets 
einzubinden?

Der EVE Screen Editor hingegen kann mir helfen, da ich dort mal Sachen 
ausprobieren könnte, ohne sie kompilen zu müssen.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Vladislav N. schrieb:
> Hast du ne Idee, wie man das Beispiel zum Laufen bringen könnte?

Äh, so spontan nicht, habe ich noch nicht versucht.
Gpu_Hal_WrCmdBufFromFlash() hat aber nichts mit dem SPI-FLASH auf dem 
Modul zu tun, das bezieht sich auf den Programm-Speicher vom Controller.
Sowas habe ich ja auch eingebaut, siehe oben, das stammt alles noch aus 
der Zeit vor den BT81x.

Den EVE Screen Designer benutze ich auch nicht.
Ich hoffe im Moment das dem EVE Screen Editor mal ein Exporter für die 
neue Library nach AN025 beigebracht wird, das ist dann schon mal viel 
dichter an meinem eigenen Code dran.

Was die Widgets angeht, zumindest das erste ist als Beispiel enthalten 
in dem aktuellen EVE Screen Editor.
Die Beispiele sind sowieso interessant, wenn auch etwas versteckt in dem 
Installations-Ordner.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Hello,

yesterday evening I pushed a small update.
Among other things I marked the function EVE_get_touch_tag() as 
deprecated.
If you using it you will get a warning that it is deprecated.

Just use EVE_memRead8(REG_TOUCH_TAG); instead.
Or EVE_memRead8(REG_TOUCH_TAG1); and so in case of multi-touch.

And make sure EVE is not busy when you use DMA:
void TFT_touch(void)
{
  uint8_t tag;
  static uint8_t toggle_lock = 0;
  
  if(EVE_busy()) /* is EVE still processing the last display list? */
  {
    return;
  }

  tag = EVE_memRead8(REG_TOUCH_TAG); /* read the value for the first touch point */

  switch(tag)
  {
...


With the upcoming BT817 a couple more changes will be necessary.
The "#if defined (BT81X_ENABLE)" needs to be changed since BT817 
obviously still is a BT81x and yet it is beyond BT815 with additional 
registers.
Instead I am thinking about using "EVE2", "EVE3" and "EVE4".
EVE2 == FT81X_ENABLE
EVE3 == BT81X_ENABLE and EVE2 is to be set as well
EVE4 for BT817 with EVE3 and EVE2 to be set as well

Well, it may be time to make EVE2 base-line when the first BT817 
displays are released.
Meaning to finally remove FT80x support, clean it up some more and call 
it 5.x.

von Bernd Ickert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Simple Frage an erfahrene Fachleute! Mit lang erprobter Hardware und 
Displays ab 4,3 Zoll (mind. 480x272) versuche ich nun schon seit Stunden 
ein 3,5 Zoll Display mit 320x240 zum Laufen zu bringen. Display-Treiber: 
FT813. Ist es möglich, dass dieser FT gar nicht für solche "kleinen" 
Displays vorgesehen ist? Hat der außer der Ober- auch eine 
Untergrenze???
Meine Erfahrungen zeigten, dass die Einstellungen der Register
HCYKLE  HOFFSET  HSYNC0 / HSYNC1 (und das Gleiche für V) recht 
großzügig in bestimmten Bereichen verändert werden können, ohne dass es 
sichtbare Auswirkungen hat.
Klar, HSIZE und VSIZE sollten wohl immer richtig sein (hier also 320 und 
240).
Zum Laufen bringen: Damit meine ich das Display einfach nur vollflächig 
mit einer Farbe beschreiben...
Je nach Einstellungen (an denen ich wie gesagt, nun schon seit Stunden 
probiere) habe ich angefangen von gar kein Bild bis zu halben/über Eck, 
flackernd die Hälfte, mit weißen Balken mal hier und da na usw...
Schließe ich einfach mal ein 480x272 an, habe ich ein grünes Bild (die 
Farbe, die es sein soll!) in der Größe 320x240 und weißem Balken 
unterhalb und "Farbschrott" rechts, was der Bereich > 320x240 ist!
Wo ist der Denkfehler?

Bernd

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier ein EVE2-35G liegen: 
https://www.matrixorbital.com/ftdi-eve/eve-ft812/eve2-35g

Das hat einen FT813, 3,5", 320x240 und spielt einwandfrei.
Ebenso das EVE3-35G mit dem noch dickeren BT815.

Mein Beispiel-Projekt ist für ein EVE2-35G konfiguriert:
https://github.com/RudolphRiedel/FT800-FT813/tree/4.x/example_projects/EVE_Test_SAMC21_FT813_EVE2-35G

Auf was für einer Hardware bist Du unterwegs, was für ein Display ist 
das genau und welche Timing-Einstellungen benutzt Du im Detail?

: Bearbeitet durch User
von Bernd Ickert (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin  mit dem "niedlichen Platinchen" (siehe 18.1. diesen Jahres) 
unterwegs, also einfach nur den FT813, den ich per SPI bediene, so wie 
zuvor mit allen anderen Displays. Das 3,5' ist jetzt Premiere - und 
klappt nicht. Anbei das Datenblatt des Display. ACTRON, die mit dem 
einheitlichen 50-poligen Anschluss, weshalb ich einfach mal von einem 
Display zum anderen Wechseln kann.
Seite 18 findest Du die entsprechenden Timings für dieses Display. 
Kannst Du mir bitte, bitte sagen, welche Werte für HCYKLE  HOFFSET 
HSYNC0 / HSYNC1 (und V....) dafür erforderlich sind?!
REG_HSIZE = 320
REG_VSIZE = 240

Werte in Klammern dahinter, was ich schon alles u.a. probiert habe
REG_HCYCLE: 408 - 450 ???
REG_HOFFSET ? (40)
REG_SYNCO ? (20, 40, 0)
REG_SYNC1 ? (68, 48, 2, 1)
REG_VCYCLE: 262 - 350 ???
REG_VOFFSET ? (40, 30, 22
REG_VSYNC0 ? (10, 1 , 0)
REG_VSYNC1 ? (40, 18, 10)

REG_PCLK habe ich auch schon mal hochgesetzt (also Takt runter), derzeit 
auf 10, also 4,5MHz... Alles egal! Nur bei REG_PCLK = 1 geht nichts mehr 
(48 MHz), ab 2 geht es. Oder liege ich da falsch? Ich betreibe den FT813 
mit 12MHz-Quarz, also durch PLL 48Mhz. Wie hoch ist dann PCLK, wenn 
REG_PCLK = 1 ist? 48 oder 12 MHz (FOSC / 4) ???

Angebot "niedliches Platinchen" steht noch - wenn Du es brauchst!

von Bernd Ickert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nun ist mir noch etwas aufgefallen:
Im Datenblatt des Display 3,5' sind die Impulse (HSYNC / VSYNC) Positiv 
im Diagramm gezeichnet, während sie bei allen anderen (bisher von mir 
verwendeten) stets negativ sind und so auch im 
FT813-Programmieranweisung (s.28) aufgeführt sind, also auch negativ.
Außer die Polarität des Clock (mit REG_PCLK_POL) kann man aber die H- 
und V-Sync-Ausgänge nicht negieren. (?). Müsste man nun also die ganzen 
Zeiten (Anzahl CLK, Anzahl Lines) so umrechnen, dass sich eben die 
positiven Werte ergeben. Hattest Du so was schon mal?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Okay, das ist also schon mal ein FT813.

Ist jetzt nicht so, als hätte ich mich damit schon oft herum schlagen 
müssen, normalerweise habe ich ja die Daten von den Modul-Herstellern.

Das Beste an den Timings ist ja, jeder Hersteller gibt das ein klein 
wenig anders an, mal ist der Buchstabensalat anders, mal fehlen auf den 
ersten Blick Werte.

Probier das mal:

#define EVE_HSIZE  (320L)
#define EVE_VSIZE  (240L)
#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (4L)
#define EVE_VOFFSET  (22L)
#define EVE_VCYCLE  (262L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (20L)
#define EVE_HOFFSET  (88L)
#define EVE_HCYCLE   (408L)
#define EVE_PCLKPOL  (1L)
#define EVE_PCLK  (9L)

Die Clock-Polarität sagt ja nur, ob das nun auf die fallende oder auf 
die steigende Flanke zu beziehen ist.
Und nach dem Datenblatt ist es die fallende Flanke und somit 
REG_PCLK_POL=1.

Bernd Ickert schrieb:
> Ich betreibe den FT813 mit 12MHz-Quarz, also durch PLL 48Mhz.

Der hat aber per Default 60MHz, da muss man sich schon ein wenig Mühe 
geben den auf 48MHz runter zu bekommen. :-)

von Bernd Ickert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Daten! Das sind ja genau die, die lt. Datenblatt 
richtig sein sollten und mit denen ich (Plus/Minus) schon in allen 
Richtungen experimentiert hatte. Ich habe jetzt bei ACTRON ein neues 
geordert, um auszuschließen, ob es sich nicht doch um ein 
"Montags-"Display handelt. Wenn sich ein neues Display genauso verhält, 
wie dieses, na dann geht's weiter...

Ich betreibe den FT mit einem separaten Quarz 12MHz, so wie es im 
Datenblatt des FT813 in "Application Examples" vorgegeben ist. Was der 
FT dann mit dieser Frequenz noch macht, weiß ich (nicht) mehr. Ich 
meinte, mal gelesen zu haben, dass mit Hilfe der inneren PLL daraus dann 
48 MHz gemacht werden (beim PIC ist es jedenfalls so - einstellbar). 
Aber natürlich auch möglich, dass durch "Mal 5" - PLL daraus 60Mhz 
werden...
Ich melde mich wieder - Eine schöne Woche

von Bernd Ickert (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da haben wir (wahrscheinlich) das Problem. Nach Rücksprache mit ACRON 
mit einem sehr kompetenten Techniker (hat man selten bei 
Display-Lieferanten!!!) liegt das Problem an der DE-Polarität. Autor der 
beigefügten AppNote ist auch der, mit dem ich eben sprach. Auf Seite 10 
siehst Du in der Tabelle letzte Spalte von Unten das Aktive low für den 
DE, während alle anderen Aktive High sind. Und das kann der FT8xx nicht. 
Da das Problem bekannt ist, haben sie da schon was in petto und ich 
bekomme ein äquivalentes Display.
Dieses Muster kann ich aber auch noch durch Umlöten eines Widerstandes 
trotzdem verwenden. Anleitung dazu erhalte ich heute noch. Na dann mal 
sehen!!!

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Doch, ja, ich bin mit den fertigen Modulen immer noch ganz glücklich 
soweit. :-)
Und ich bin schon gespannt was Matrix Orbital feines mit den BT817 raus 
bringen wird für EVE4.
Ich hoffe da auf ein EVE4-100G mit 10.1" und 1280x800. :-)

Bernd Ickert schrieb:
> Ich betreibe den FT mit einem separaten Quarz 12MHz, so wie es im
> Datenblatt des FT813 in "Application Examples" vorgegeben ist. Was der
> FT dann mit dieser Frequenz noch macht, weiß ich (nicht) mehr. Ich
> meinte, mal gelesen zu haben, dass mit Hilfe der inneren PLL daraus dann
> 48 MHz gemacht werden (beim PIC ist es jedenfalls so - einstellbar).
> Aber natürlich auch möglich, dass durch "Mal 5" - PLL daraus 60Mhz
> werden...

Das ist korrekt soweit, der Takt wird per PLL aus den 12MHz erzeugt.
Aber das mit den 48MHz war bei den FT80x der Fall, bei den FT81x waren 
das schon per Default 60MHz.
Bei den BT81x sind es per Default auch erstmal 60MHz, die lassen sich 
aber auf 72MHz hoch stellen - was meine Library auch macht.

von Mila Mik (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Doch, ja, ich bin mit den fertigen Modulen immer noch ganz glücklich
> soweit. :-)
> Und ich bin schon gespannt was Matrix Orbital feines mit den BT817 raus
> bringen wird für EVE4.
> Ich hoffe da auf ein EVE4-100G mit 10.1" und 1280x800. :-)

Ich warte seit Februar auf Muster vom BT817. Ich brauche den für eine 
Neuentwicklung wo ein Display mit 1024x600 gefordert wird. 
Seltsamerweise ist auf der Bridgetek-Seite jetzt wieder jeder Hinweis 
verschwunden, während der embedded war dort noch die Ankündigung. Weiß 
jemand wo die bei bridgetek dafür Zuständige Abteilung sitzt ? Ist das 
in UK oder Singapore ? Dürfen die noch arbeiten ?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte jetzt auch schon länger keinen direkten Kontakt mehr zum 
Support, aber das Forum läuft ja noch und das geht nur moderiert.
Eigentlich ja, dafür das im Februar der Release sein sollte sind die 
Informationen immer noch recht dünn.

So wie ich das verstehe, muss nicht stimmen, läuft das schon 
international.
Support auf jeden Fall aus UK.

Was die Entwicklung mit dem BT817 und dem 1024x600 Display angeht,
so wie ich das verstehe, kannst Du das im Grunde mit einem BT815 
anfangen.
Die dürften ziemlich kompatibel werden.
Die BT817 sind dann nachher schneller und erlauben eine höhere Bildrate.
Aber um das LVDS Interface kommt man wohl nicht herum, es sei denn 
Bridgetek nutzt die Zeit um den BT817 nach den Ankündigungen über das 
eine Bild zur Embedded World noch mal zu überarbeiten.
Meine letzten Informationen sind von Anfang März.

Das ADAM101 von Glyn ist übrigens ein 10.1" mit FT813 und 1024x600.
Da ist ein LVDS Chip drauf.
Der FT813 ist meiner Meinung nach mit dem Display aber ein klein wenig 
überfordert.

Edit: es gibt einen neuen EVE Asset Builder V1.4:
https://brtchip.com/eve-toolchains/#EVEAssetBuilder

Unter anderem sollen die UTF-8 Probleme gefixt sein.

: Bearbeitet durch User
von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Edit: es gibt einen neuen EVE Asset Builder V1.4:
> https://brtchip.com/eve-toolchains/#EVEAssetBuilder
>
> Unter anderem sollen die UTF-8 Probleme gefixt sein.

Ist mir auch schon aufgefallen und teste seit gestern. Habe die gleichen 
Tests gemacht wie bereits vor einigen Wochen beschrieben, aber das 
Problem ist unverändert da. Werde bei Bridgetek mal nach einem 
ESE-Beispiel inkl. Flashdaten fragen, mit dem es funktionieren soll.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Was mich ein wenig wundert ist die Größe der Dateien.
Ich habe gestern noch mal eine gestrippte Version von dem 
notosans-regular auf 100 Punkte konvertiert.
notosans-regular-webfont_100_ASTC.glyph 3272kB

Okay, warum nicht, ist ja auch Mordsgroß.
Nur wenn ich diese Datei in eine .zip packe, dann schrumpft das zu 74kB.
Okay, der Font hat 222 Glyphen.
Also mal ein einzelnes Zeichen testen.
"1": 40kB - 581 Bytes als .zip
".": 8kB - 337 Bytes als .zip
"a": 96kB - 924 Bytes als .zip

So schlecht kann ASTC doch eigentlich gar nicht komprimieren?

Dazu die Release-Notes:
V1.4.0:
    - Fix bugs:
      + The UTF-8 code point 0xF09FA183 (i.e. 0x1F843 for unicode) 
cannot be displayed
      + The glyph file is not compressed when the code point is in UTF-8
      + eab_tools.exe will not run on a fresh 64-bit Win10 machine
      + Image conversion fail if current output folder does not exist
    - Add the "Verify" function in flash utility
    - Recognize UTF8-BOM and remove it before converting
    - Speed up generating font when code point mode is UTF-8
    - Replace 'numpy' by 'tinynumpy' to reduce distribution package size

Irgendwie sieht das danach aus als wäre bei der 1.4.0 nicht der 
Font-Converter für die 1.4.0 dabei.

Edit: "eab_tools font_convert -v" : EVE Font Conversion Utility V0.1.6

Mit der 1.4.0 habe ich exakt das gleiche wie mit der 1.2.0.

: Bearbeitet durch User
von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klingt nach einer plausiblen Erklärung. Werde das im Bridgetekforum mal 
mit anklingen lassen :-)

von Mike T. (miket)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Das ADAM101 von Glyn ist übrigens ein 10.1" mit FT813 und 1024x600.
> Da ist ein LVDS Chip drauf.
> Der FT813 ist meiner Meinung nach mit dem Display aber ein klein wenig
> überfordert.

Danke, das kannte ich noch nicht. Im Datenblatt des BT815/FT813 steht 
eigentlich eine maximale Auflösung von 800x600, aber scheinbar geht dann 
ja auch mehr.
Wieso meinst du, dass man dann unbedingt LVDS braucht ? Das Display das 
ich anstrebe gibt es auch mit TTL Interface. Müsste das dann nicht 
direkt gehen ?
Noch einen LVDS-Transmitter dazu bauen wäre aber auch kein Problem.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Mike T. schrieb:
> Danke, das kannte ich noch nicht. Im Datenblatt des BT815/FT813 steht
> eigentlich eine maximale Auflösung von 800x600, aber scheinbar geht dann
> ja auch mehr.

Das Maximum sind so theorethische 4096x4096 oder so.
Ist aber uninteressant, das Problem sind nicht die Pixel an sich.
Sondern der Pixel-Takt und dass das Bild ja auch noch erzeugt werden 
muss.
Mit dem ADAM101 lag ich glaube ich bei um 30 Bilder pro Sekunde.

> Wieso meinst du, dass man dann unbedingt LVDS braucht?

Na, unbedingt nicht, aber jenseits von 800x600 wird die Auswahl an 
Panels mit TTL Interfaces echt dünn.
Und LVDS stirbt auch schon wieder, MIPI DSI ist angesagt.

> Das Display das ich anstrebe gibt es auch mit TTL Interface.
> Müsste das dann nicht direkt gehen ?

Doch, das geht natürlich.

> Noch einen LVDS-Transmitter dazu bauen wäre aber auch kein Problem.

Das ist ganz schön hässlich im Layout, vor allem auch da die Signale 
vergleichsweise schnell sind.

von Mike T. (miket)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Das ist ganz schön hässlich im Layout, vor allem auch da die Signale
> vergleichsweise schnell sind.

Da muss man auf die richtige Impedanz (100Ohm differenziell, 50 Ohm 
single ended) und gleiche Länge der einzelnen Leitungen achten, dann 
geht das schon. Dafür sind es auch nur 4 oder 5 Leitungspaare also 10 
Leitungen und nicht 27. Hab ich schon oft gemach, funktioniert wenn mans 
richtig macht.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Klar, geht das, keine Frage.
Und ich meinte jetzt auch mehr die andere Seite, also das TTL Interface 
an den LVDS Chip anzuklemmen.
Ich habe noch keinen LVDS Chip gesehen bei dem das einfach wäre, so mit 
TTL auf der einen Seite und LVDS+Versorgung auf der anderen Seite.
Irgendwie muss man immer 1/3 der Leitungen um den Chip herum wickeln.

Naja, ich werde sowas auch weiterhin nicht versuchen.
Gestern habe ich mal wieder nach Displays gefischt.
Über 800x600 und/oder über 7" gibt es praktisch nur welche mit LVDS.
Mit MIPI DSI habe ich jetzt gar nicht so viele gesehen.
Dann habe ich mit dem WF101FSYAPLNG0 ein nettes Teil gefunden mit dem 
man mal herum spielen könnte, nur kaufen kann man sowas dann natürlich 
nicht.
Aber naja, gibt eh kein richtiges Datenblatt einfach so frei dafür und 
der Aufwand dafür eine Platine zu machen steht auch in keinem Verhältnis 
zu dem Nutzen den ich davon hätte.

Das Spiel macht ohne Stückzahlen einfach keinen Spaß.

von Rudolph R. (rudolph)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe heute einen Test-Sockel auf ein EVE3-43G gelötet um mal einen 
Satz weiterer Flash-Chips zu testen.

http://www.brtcommunity.com/index.php?topic=77.msg318#msg318
Chip  Size(MBit)  Detect  Erase  Read/Write  CMD_FLASHFAST
W25Q128JVSIQ  128  Yes  Yes  Yes  Yes
SST26VF064BA-104I/SM  64  Yes  Yes  Write fails  -
AT25QF128A-SHB-T  128  Yes  Yes  Yes  0xE004 - device/blob mismatch
W25Q32JVSSIQ  32  Yes  Yes  Yes  Yes
W25Q64JVSSIQ  64  Yes  Yes  Yes  Yes
IS25LP128F-JBLE   128  Yes  Yes  Yes  Yes
S25FL064LABMFI010  64  Yes  Yes  Yes  Yes
S25FL128LAGMFV010  128  Yes  Yes  Yes  Yes
MX25L6433FM2I-08G  64  Yes  Yes  Yes  Yes
IS25LP064A-JBLE  64  Yes  Yes  Yes  Yes
AT25SF641-SUB-T  64  Yes  ?  Yes  0xE004 - device/blob mismatch

von Axel V. (axel-f)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gestern habe ich versucht, ein Bild anzeigen zu lassen.
Habe es zuerst mit dem "EVE Asset Builder" in ein ARGB1555 umwandeln 
lassen. Angezeigt wurde nur ein gelbes Rechteck (foreground colour). 
Dann habe ich es mit ARGB4 versucht- gleiches Ergebnis. Bildgröße war 
200 x 130. Dann habe ich eine andere Datei genommen, auf ARGB4 gewandelt 
und als 108 x 123 angezeigt. Das hat funktioniert.
Erst als ich das Ursprungsbild auf 50 x 33 verkleinert hatte, konnte ich 
es (als ARGB4) anzeigen. Ich hänge das Ursprungsbild mal an.
Gibt es da irgendwelche Größenbeschränkungen?
Zum Anzeigen habe ich aus Deinem Beispiel verwendet:
  FT8_cmd_dl(DL_BEGIN | FT8_BITMAPS);
  FT8_cmd_setbitmap(MEM_WOLKE, FT8_ARGB4, 50, 33);
  FT8_cmd_dl(VERTEX2F(240*16, 10*16));

Muß man hier irgendwie mit den Farben im Ursprungsbild aufpassen?

Danke,
Gruß Axel

von Axel V. (axel-f)


Bewertung
0 lesenswert
nicht lesenswert
Oh, ich glaube ich hab's. Da war ganz am Anfang des Beitrags was von 
4k-Grenze zu lesen. An welcher Stelle ist die zu finden bzw. wodurch 
besteht diese Grenze?

Gruß Axel

von Rudolph R. (rudolph)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das gerade mal in meinen Test-Code eingebaut und ich habe 
soweit keine Probleme mit der Anzeige in 200x130.
Das erste ist ARGB4, das zweite ist ARGB1555 und das dritte ist direkt 
als .jpg verwendet und entsprechend als RGB565 angezeigt.
Ach ja, das ist ein EVE3-50G.

Die Bilder habe ich mit dem EVE Asset Converter Builder 1.4.0 
konvertiert aus der hier angehängten Original Datei.
Option "Compressed" an und "Dithering" aus.

ARGB4: 5925 Bytes
ARGB1555: 9665 Bytes

Zwei Sachen sind mir aufgefallen.
Zum einen das oben angehängt Bild, das ist komplett "verseucht" mit 
Meta-Daten.
Wenn ich das in IrfanView aufmache wird mir angezeigt: JPEG, quality: 
90, subsampling ON (2x2)
Also habe das ohne Meta-Daten und mit 90% Kompression wieder 
gespeichert.

JPG: 5190 Bytes

Entweder ist die Angabe zur Kompression in der Original-Datei gelogen, 
oder da stecken wirklich über 40KiB Daten in der Datei die nichts mit 
dem Bild zu tun haben.
Ich habe das nicht nachgezählt, aber wenn man die Datei mit einem 
Hex-Editor aufmacht ist da Text drin ohne Ende.

Oh ja, schöner Test, packt man die Original-Datei in eine .zip, so hat 
das Archiv dann 17053 Bytes.
Packe ich die neue Datei in eine .zip werden das 5222 Bytes.


Zum anderen benutzt Du irgendeinen alten Stand aus 2018.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Axel V. schrieb:
> Da war ganz am Anfang des Beitrags was von
> 4k-Grenze zu lesen. An welcher Stelle ist die zu finden bzw. wodurch
> besteht diese Grenze?

Das Problem besteht seit FT8_Commands.c Version 3.10 nicht mehr, also 
für cmd_inflate, für cmd_loadimage seit Version 2.7.
Die Ursache war, dass der Kommando-FIFO eben nur 4k groß ist und die 
Lösung war die Daten in Häppchen zu verschicken die kleiner als 4k groß 
sind.
Aus dem Grund ist in dem Zuge auch dazu gekommen, dass cmd_inflate nicht 
mehr "von Hand" ausgeführt werden muss, jedes Segment erfordert sowieso 
schon die Ausführung.

Aber ich bin mir gerade nicht mal sicher, ob in so einem Fall überhaupt 
was angezeigt worden wäre.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
A little heads up, 5.0 will remove FT80x support.
But 5.0 will also support BT817/BT818 and since I do not even have a 
programming manual for EVE4 yet, do not hold your breath. :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.