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.
von Daniel S. (snipod)


Angehängte Dateien:

Lesenswert?

Moin Moin,
also ich habe mich noch mal mit dem Thema ESP-IDF beschäftigt und eine 
Lösung für die Lücken in den Transaktionen gefunden.
Nutzt man "DMA" und sendet die ganze DL als ein Buffer bekommt man die 
Lücken raus und man landet bei 290 us für die Demo DL (bzw. 751 wenn man 
das EVE_busy()) mitzählt.

Wenn man das ganze jetzt weiter verbessen möchte, müsste man die ganzen 
einzelnen Commands umschreiben, dass nicht einzelne SPI Transaktionen 
erzeugt werden, sondern immer ein Buffer an Bytes gesendet wird. Dafür 
müsste ich aber den Kern der Bibliothek angreifen... Beispielsweise
1
void EVE_start_command(uint32_t command)
2
{
3
  uint32_t ftAddress;
4
5
  ftAddress = REG_CMDB_WRITE;
6
  EVE_cs_set();
7
  char spi_buf[7] = {
8
    (uint8_t)(ftAddress >> 16) | MEM_WRITE,
9
    (uint8_t)(ftAddress >> 8),
10
    (uint8_t)(ftAddress),
11
    (uint8_t)(command >> 24),
12
    (uint8_t)(command >> 16),
13
    (uint8_t)(command >> 8),
14
    (uint8_t)(command)};
15
  spi_transmit_bytes(spi_buf, 7);
16
}

PS: für "DMA" benötigt man natürlich noch die entsprechende Funktion:
1
void EVE_start_dma_transfer(void)
2
  {
3
    EVE_cs_set();
4
5
    static spi_transaction_t trans;
6
    trans.length = (4 * 8 * (EVE_dma_buffer_index)) - 8;   //we dont want the first byte of the EVE_start_cmd_burst
7
    trans.rxlength = 0;
8
    trans.flags = 0;
9
10
    trans.tx_buffer = ((char *)EVE_dma_buffer) + 1;      //we dont want the first byte of the EVE_start_cmd_burst
11
    spi_device_transmit(EVE_SPI_DEVICE_HANDLE, &trans); 
12
    EVE_cs_clear();
13
    EVE_dma_buffer_index = 0;
14
  }

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Äh, schau doch mal wie ich das aktuell für die Arduino Seite umgesetzt 
habe, ich komme jetzt auf 100µs für die Demo ohne gleich alles über den 
Haufen zu werfen und ohne DMA.
Mit DMA sollte das deutlich unter 60µs fallen.
Das SPI.writeBytes() ist ja praktisch nichts anderes als 
spi_device_transmit(), das ist beides blockierend, nur ist die ESP-IDF 
Version langsamer als die Arduino variante.

Einzelne Kommandos auf DMA umzustellen macht überhaupt keinen Sinn, zum 
einen hat man dann wieder den Overhead der 3-Byte Adresse mit drin, zum 
anderen dauert das viel zu lange die Que für die paar Bytes anzuwerfen.
Mit dem ESP-IDF wird der DMA übrigens auch nicht direkt bedient, es wird 
vielmehr das RTOS freundlich darum gebeten irgendwann mal vielleicht den 
Request zu der passenden Que hinzufügen.

Gestern habe ich erst mal DMA für STM32duino eingebaut, auf dem 
"langsamen" Nucleo-64 mit STM32F446RE braucht der Display-Refresh jetzt 
12µs.
Auf dem Metro-M4 läuft DMA unter Arduino auch schon ein paar Tage.

Angehängt ist noch mal mein Test-Programm vom 23.12. das ich auf Github 
gepostet hatte.
Wenn das laufen würde, so mit den drei Blöcken in der loop() 
gleichzeitig aktiv, dann hätten wir DMA.

Also das hier:
1
#if 1
2
    spi_transaction_t trans;
3
    trans.length = 8;
4
    trans.rxlength = 0;
5
    trans.flags = SPI_TRANS_USE_TXDATA;
6
7
    trans.tx_data[0] = 0x55;
8
    EVE_cs_set();
9
    spi_device_transmit(EVE_spi_device_simple, &trans);
10
    EVE_cs_clear();
11
#endif
12
13
#if 1
14
    uint32_t data = __builtin_bswap32(0xdeadbeef);
15
    spi_transaction_t trans3;
16
    trans3.length = 32;
17
    trans3.rxlength = 0;
18
    trans3.flags = 0;
19
    trans3.tx_buffer = &data;
20
    EVE_cs_set();
21
    spi_device_transmit(EVE_spi_device_simple, &trans3);
22
    spi_device_transmit(EVE_spi_device_simple, &trans3);
23
//    spi_device_polling_transmit(EVE_spi_device_simple, &trans3);
24
//    spi_device_polling_transmit(EVE_spi_device_simple, &trans3);
25
    EVE_cs_clear();
26
#endif
27
28
#if 0
29
    uint32_t EVE_dma_buffer[1025];
30
31
    EVE_dma_buffer[1] = 0x12345678;
32
    EVE_dma_buffer[2] = 0x12345678;
33
    EVE_dma_buffer[3] = 0x12345678;
34
    EVE_dma_buffer[4] = 0x12345678;
35
36
    spi_transaction_t trans2;
37
    trans2.length = 43 * 4 * 8;
38
    trans2.rxlength = 0;
39
    trans2.flags = 0;
40
    trans2.addr = 0x00b02578;
41
    trans2.tx_buffer = (uint8_t *) &EVE_dma_buffer[1];
42
    EVE_cs_set();
43
    spi_device_queue_trans(EVE_spi_device, &trans2, portMAX_DELAY);
44
//    EVE_cs_clear();
45
#endif

Die ersten beiden Blöcke tun was sie sollen.
Der dritte Block funktioniert auch wenn der alleine benutzt wird.
Aber wenn ich den dritten Block zusammen mit einem der anderen beiden 
aktiviere crasht der ESP32 und resettet sich.
Ich habe keine Idee was da falsch läuft.

von Daniel S. (snipod)


Angehängte Dateien:

Lesenswert?

Hi,
also ich habs mir mal angeschaut, ich denke da kommt bisschen was 
zusammen.

Der Post Transaction Callback ist nicht richtig definiert und die 
structs solltest Du immer nullen bevor Du da was setzt...

Hat dann aber bei mir immer noch nicht so ganz funktioniert. Dann hab 
ich es eben "nativ" in die IDF gepackt, da gehts. Denke da gibts ein 
Problem mit dem Arduino Core und dem IDF SPI Treiber.

Ist aber nach wie vor eine riesen Zeitspanne zwischen CS setzen und 
start der Übertragung...

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Top, mein Test-Programm läuft jetzt unter Arduino und alles was ich 
dafür geändert habe war ein paar Mal "= {0};" zu ergänzen.

Wofür haben wir eigentlich einen Compiler? :-)

Die Blöcke haben jeweils einen eigenen "spi_transaction_t" und diese 
hast Du nicht genullt. :-)

Die Post-Transaction Callback Funktion sollte so in Ordnung sein, der 
Parameter wird doch schliesslich nicht verwendet.

Nicht nur die Zeit von Chip-Select Down bis Anfang Transfer ist krank, 
die Zeiten zwischen zwei Bytes sind auch total übel.
Vor allem weil das mit Arduino Code "nur" 6µs dauert.

Den Unsinn bekommt man vermutlich nur in den Griff wenn man direkt auf 
die Register runter geht.
Aber naja, mal schauen wie das am Ende aussieht, der wichtigste Teil ist 
ja den Display-Refresh in den DMA zu verlegen, ob der Teil mit dem Touch 
nun fest 18µs oder 150µs dauert ist ja nich so relevant.
Aber wenn der Display-Refresh nur noch 80µs braucht und keine 1,2ms für 
2k, das merkt man schon eher. :-)

Dann muss ich da wohl noch mal ran. :-)

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Okay, also der Display-Refresh Teil läuft jetzt schneller als ich 
erwartet habe. :-)

Aber der normale SPI Zugriff ist mit dem ESP-IDF echt übelst langsam.
Was zum Geier treiben die da eigentlich?

Da muss es doch irgendeinen Trick geben dem Treiber beizubringen nicht 
jedes Mal Pi auf 1000 Stellen zu berechnen.

Ich habe versucht Arduino SPI mit ESP-IDF SPI zu mischen,
dann kommt nur gar nichts mehr aus dem SPI raus.

Naja, die 251µs sind wie ich oben schon schrieb fest und ändern sich 
nicht mit einer längeren Display-Liste.
Außerdem entfallen rund 93µs auf das Lesen der Länge der letzten 
Display-Liste, das ist eine Debug-Information.

Man könnte noch auf die Idee kommen den SPI Takt zu erhöhen da ich jetzt 
für normale Kommandos nur 10MHz eingestellt habe, im Init darf es eben 
nicht schneller sein als 11MHz.
Nur habe ich gerade keine Idee wie man ein einmal eingestelltes 
spi-bus-device verändert, zum anderen bringt das ja nichts wenn auf ein 
8 Bit Read-Kommando mit 4+1+1 Byte Transfer von 93,2µs Dauer nur 5µs auf 
den eigentlichen Daten-Transfer entfallen...
Yeah, der Takt ist doppelt so hoch, es dauert nur noch 91µs.

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Okay, jetzt kann ich so langsam mal einen Release vorbereiten.

Time2 ist jetzt auf 100µs runter, Pi wird zwischen zwei Transfers nur 
noch auf 200 Stellen berechnet...

Zuerst habe ich versucht mit
spi_device_acquire_bus(EVE_spi_device_simple, portMAX_DELAY);
in EVE_cs_set() und
spi_device_release_bus(EVE_spi_device_simple);
in EVE_cs_clear() dem SPI Treiber beizubringen das er nicht erst eine 
Partie Schach gegen den RTOS Task-Scheduler gewinnen muss damit er ein 
Byte auf den Bus werfen darf.
Nur blöderweise wurden die Abstände dann noch länger: 32µs.

Jetzt habe ich mal meine drei SPI Funktionen von
spi_device_transmit(EVE_spi_device_simple, &trans);
umgestellt auf
spi_device_polling_transmit(EVE_spi_device_simple, &trans);

Und sieh an, damit schrumft die Pause auf 8,2µs.
Wenn der Bus nicht belegt ist steigt das auf 12,2µs.

Also 100µs für den Touch ist jetzt nicht toll, aber sicher akzeptabel, 
vor allem als konstanter Wert.
Und davon entfallen jetzt 28,7µs auf das Lesen der Länge der letzten 
Display-Liste.

von Rudolph R. (rudolph)


Lesenswert?

Ich habe gerade noch ein Update hochgeladen für ESP32 ESP-IDF, quasi der 
gleiche Code wie für die Arduino Seite mit ein paar Zeilen zusätzlich.

Komischerweise ist das mit 40ms/139ms etwas langsamer als für den 
Arduino.

Ein Beispiel-Projekt für PlatformIO schiebe ich nachher noch ins 
Repository.

von Rudolph R. (rudolph)


Lesenswert?

Die Beispiele sind aktualisiert und das native ESP32 Beispiel ist jetzt 
auch da.

von Karol (Gast)


Lesenswert?

Hi there, could you help me please? I have your very old library (for 
FT800). I'm using it for FT813 with no problem. Now I'm trying lunch it 
with BT815 but isn't working. So, I downloaded lastest version (added to 
my project) but still dont work. Only calibrations work (but with 
differents background collor than wrote in software).
TFT is from Riverdi, RVT70UQBNWC00: 
https://riverdi.com/product/ritft70capux/

Thanks in advance, regards,
Karol

von Rudolph (Gast)


Lesenswert?

I am currently using the 5" BT815 from Riverdi as this is the closest 
match to the Riverdi IoT display I could find.
And the RiTFT-50 should be pretty much the same as the RiTFT-70, except 
for the size obviously.

So what are you using it with?
How exactly do you connect to the display, have you checked that the 
supply is stable and capable of delivering enough current and what 
controller from which pins?

von Robert S. (bimbo385)


Lesenswert?

Hallo an Alle,

ich hoffe ich bin hier an der richtigen Stelle um ein paar Fragen zum 
Einstieg loswerden zu können.

Ich bin jetzt nicht der professionelle Softwareentwickler (sondern 
Hardware), habe aber einige Kenntnisse in C und bezüglich der Atmel 
Atmega und Xmega MCUs.

Ich stehe vor der Aufgabe ein HMI mit einem FT813 Display: 
https://4dsystems.com.au/gen4-ft813-50ctp-clb
und einem Atmel/Microchip ATxmega128A1U als Hostprozessor zu bauen.

Es geht hier nicht um grafikintensive Animationen oder ähnlich, viel 
mehr sollen Messwerte und ein paar Graphen angezeigt werden, ein Menü 
für ein paar Einstellungen wird wohl auch benötigt und Bedienung per 
touch ist halt gewünscht.

Ich bin jetzt etwas überwältig von den ganzen Tools auf der FTDI 
Webseite und dann gibt es ja noch solche Opensource-Libs wie diese hier 
und diverse (nicht besonders gute) first-step Geschichten in denen nicht 
erklärt wird wie was funktioniert.

Habt ihr ein paar Tipps welchen Weg man jetzt am Besten geht?

Kann ich in meinem Fall mit dem EVE Screen Designer (ESD) 4.8 überhaupt 
etwas anfangen? Habe bisher nur ein bisschen damit herumgespielt und mir 
ist nicht klar wie ich aus dem Tool jetzt ANSI-C herausbekomme um den 
Code auf meinen Xmega zu bekommen. Außerdem muss da ja irgendwie eine 
API dran um zum Einen den hardware SPI anzusteuern und zum Anderem um 
Events und Werte an das Display zu senden (aus der eigentlichen 
Anwendung heraus).

Auch habe ich noch nicht ganz verstanden, was jetzt eigentlich der FT813 
tut und was meine MCU tun muss. Also man schickt an den FT813 Kommandos 
wie z.B. zeichne eine Linie und male einen Text/Button. Aber was ist mit 
den analogen Anzeigen (Gauge) aus dem ESD? Da werden laut dem Fenster 
unten links ganz viele Kommandos mit einzelnen Linien draus... Also 
scheint der FT813 solche komplexeren Objekte nicht zu kennen und 
selbständig zu rendern. Daher kommt man nur mit den grundlegen Kommandos 
wohl nicht aus, wenn man eine GUI bauen will, sondern benötigt etwas wie 
ESD.

Muss ich den FT813 eigentlich jemals irgendwie programmieren oder 
updaten, Nein, oder? Das Teil hat ja laut Datenblatt keinen Flash oder 
EEPROM, nur RAM und ROM.

Ich bin definitiv nicht zu faul die Doku zu lesen und mich 
reinzuarbeiten, auch helfe ich gerne bei der Entwicklung dieser Lib in 
Richtung Xmega, wenn das den "der Weg" ist ;-) Nur weiß ich ATM garnicht 
wo ich anfangen soll.

Gruß,
Robert

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

Tach,

> ich hoffe ich bin hier an der richtigen Stelle um ein paar Fragen zum
> Einstieg loswerden zu können.

Jain. :-)
Das ist ja nur ein Thread hier, da geht schon mal was unter, wenn auch 
nicht so richtig viel los ist.
Manche Dinge kann oder auch mag ich nicht so richtig tief beantworten, 
zum Beispiel zum ESD weil ich zum einen nicht damit arbeite, zum anderen 
exportiert das Teil für eine Library mit der ich praktisch nichts 
anfangen kann.

> Ich bin jetzt nicht der professionelle Softwareentwickler (sondern
> Hardware), habe aber einige Kenntnisse in C und bezüglich der Atmel
> Atmega und Xmega MCUs.

XMega habe ich übersprungen, ich habe irgendwo noch ein Eval Board mit 
einem XMEga128A1 oder so herum liegen, so >10 Jahre alt.

> Ich stehe vor der Aufgabe ein HMI mit einem FT813 Display:
> https://4dsystems.com.au/gen4-ft813-50ctp-clb
> und einem Atmel/Microchip ATxmega128A1U als Hostprozessor zu bauen.

Okay, so eines habe ich noch nicht in die Finger bekommen und könnte 
auch spontan nichts damit anfangen, weil der 30pol FFC da drauf zu 
nichts anderem kompatibel ist.
Aber, ich habe Support für die Displays in Form eines Parametersatzes in 
meine Library eingebaut:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_config.h

EVE_GEN4_FT813_50

> Es geht hier nicht um grafikintensive Animationen oder ähnlich, viel
> mehr sollen Messwerte und ein paar Graphen angezeigt werden, ein Menü
> für ein paar Einstellungen wird wohl auch benötigt und Bedienung per
> touch ist halt gewünscht.

Dafür sind die Displays bestens geeignet.

> Ich bin jetzt etwas überwältig von den ganzen Tools auf der FTDI
> Webseite und dann gibt es ja noch solche Opensource-Libs wie diese hier
> und diverse (nicht besonders gute) first-step Geschichten in denen nicht
> erklärt wird wie was funktioniert.

Ja, das ganze gibt es jetzt auch schon eine Weile.

> Habt ihr ein paar Tipps welchen Weg man jetzt am Besten geht?

Fang mit der Hardware an, mach das Datenblatt auf.
Das gen4-ft813-50ctp-clb möchte mit 5V versorgt werden und
hat 3,3V Pegel auf der SPI Schnittstelle.
Die typische Stromaufnahme ist mit 525mA angegeben, das finde ich jetzt 
zwar übertrieben, aber die 5V Quelle sollte schon so 600mA liefern 
können.

4D Systems hat ein Breakout Board.
Neben der Versorgung benötigt man mindestens MISO, MOSI, SCK, CS und PD.

Um das mal laufen zu lassen kannst Du das über das Breakout Board zum 
Beispiel an einen 3,3V Arduino UNO Clone klemmen, sowas wie ein 
Seeduino, und meine Demo-Software benutzen:
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO
8 = PD
9 = CS
11 = MOSI
12 = MISO
13 = SCK

Das einzige was dazu verändert werden müsste ist das in der EVE_config.h 
eingestellte Display.


> Kann ich in meinem Fall mit dem EVE Screen Designer (ESD) 4.8 überhaupt
> etwas anfangen?

Bestimmt, irgendwie, es gibt Leute die das benutzen, mir ist das
allerdings zu sperrig.
Gezielte Fragen dazu wären hier angebracht: http://www.brtcommunity.com/

> Habe bisher nur ein bisschen damit herumgespielt und mir
> ist nicht klar wie ich aus dem Tool jetzt ANSI-C herausbekomme um den
> Code auf meinen Xmega zu bekommen.

Ich habe ESD gerade aufgemacht und mir ist das ehrlich gesagt auch nicht 
klar. Früher ging das mal leichter da Code raus zu bekommen, auch mit 
dem EVE Screen Editor.
Den Code der da raus kam wollte ich nur nicht benutzen.

> Außerdem muss da ja irgendwie eine
> API dran um zum Einen den hardware SPI anzusteuern und zum Anderem um
> Events und Werte an das Display zu senden (aus der eigentlichen
> Anwendung heraus).

Als zumindest habe ich in meiner Library sicher mehr Targets für 
verschiedene Controller als im ESD zu finden sind, nur leider bisher 
auch keinen Support für die XMEga.

> Auch habe ich noch nicht ganz verstanden, was jetzt eigentlich der FT813
> tut und was meine MCU tun muss. Also man schickt an den FT813 Kommandos
> wie z.B. zeichne eine Linie und male einen Text/Button. Aber was ist mit
> den analogen Anzeigen (Gauge) aus dem ESD? Da werden laut dem Fenster
> unten links ganz viele Kommandos mit einzelnen Linien draus... Also
> scheint der FT813 solche komplexeren Objekte nicht zu kennen und
> selbständig zu rendern. Daher kommt man nur mit den grundlegen Kommandos
> wohl nicht aus, wenn man eine GUI bauen will, sondern benötigt etwas wie
> ESD.

Ganz so schlimm ist es nicht, es gibt in den FT8xx / BT8xx zwei Ebenen, 
das sind sind die "Graphics primitive", da fallen Punkte, Linien, 
Linien-Züge, Rechtecke und Bilder drunter.
Diese werden von der eigentlichen Graphics-Engine über die Display-Liste 
verarbeitet.
Dann gibt es noch den Kommando Co-Prozessor welchen man über den 
CMD-FIFO mit Befehlen füttert.
Der Co-Prozessor kümmert sich um die eingebauten Widgets, also Buttons, 
Gauges, Slider, Texte und einiges mehr.
Wenn man dem Co-Prozesser jetzt etwa ein CMD_BUTTON schickt dann zerlegt 
der das in Anweisungen für die Graphics-Engine und schreibt das in die 
Display-Liste.

Besonder gut sehen kann man das im EVE Screen Editor.

CMD_BUTTON(171, 183, 120, 36, 27, 0, "Button")

  Raw  Text
1  0x22000000  SAVE_CONTEXT()
2  0x27000002  VERTEX_FORMAT(2)
3  0x0e00003c  LINE_WIDTH(60)
4  0x1f000009  BEGIN(RECTS)
5  0x04003870  COLOR_RGB(0, 56, 112)
6  0x415d82eb  VERTEX2F(699, 747)
7  0x423e835d  VERTEX2F(1149, 861)
8  0x1f000001  BEGIN(BITMAPS)
9  0x23000000  RESTORE_CONTEXT()
10  0x22000000  SAVE_CONTEXT()
11  0x27000002  VERTEX_FORMAT(2)
12  0x0500001b  BITMAP_HANDLE(27)
13  0x99cbfdc2  VERTEX2II(206, 191, 27, 'B')
14  0x9b0bfdf5  VERTEX2II(216, 191, 27, 'u')
15  0x9c2bfdf4  VERTEX2II(225, 191, 27, 't')
16  0x9d0bfdf4  VERTEX2II(232, 191, 27, 't')
17  0x9debfdef  VERTEX2II(239, 191, 27, 'o')
18  0x9f2bfdee  VERTEX2II(249, 191, 27, 'n')
19  0x23000000  RESTORE_CONTEXT()

Und das ist jetzt nur der "flache" Button, mit 3D Effekt ist das mehr 
als doppelt so viel.

Mein Library geht exklusiv über den Co-Processor, das reduziert die 
notwendigen Daten über den SPI.

Sowas hier:
3  0x0e00003c  LINE_WIDTH(60)
4  0x1f000009  BEGIN(RECTS)
5  0x04003870  COLOR_RGB(0, 56, 112)
6  0x415d82eb  VERTEX2F(699, 747)
7  0x423e835d  VERTEX2F(1149, 861)

Malt zum Beispiel einfach nur ein Rechteck mit gerundeten Ecken,
das kann man auch an den Co-Prozessor schicken, der reicht das dann an 
die Display-Liste durch.

Jetzt füttert man den FT813 mit Kommandos, der packt die in eine 
Anweisungsliste und diese Liste wird dann immer wieder abgearbeitet.

In meiner Demo und auch sonst in Projekten generiere ich diese Liste 
einfach 50 Mal pro Sekunde neu.
Ändern sich irgendwelche Messwerte oder es muss zum Beispiel ein Button 
von nicht-gedrückt dargestellt auf gedrückt dargestellt verändert 
werden,
so erlaubt das kurze Intervall eine Aktualisierung ohne bemerkbare 
Verzögerung.
Und wie man in meiner einfachen Demo sieht erlaubt das nebenbei flüssige 
Animationen.
Diese Display-Liste ist doppelt gepuffert.
Wenn man dem Kommando Co-Prozessor mitteilt eine neue Liste anzulegen, 
dann passiert das in der aktuell nicht aktiven Liste.
Gibt man die Liste zur Anzeige frei dann wird das mit dem 
Bildschirmwechsel synchronisiert und der Speicher der alten Liste kann 
beschrieben werden.

> Muss ich den FT813 eigentlich jemals irgendwie programmieren oder
> updaten, Nein, oder? Das Teil hat ja laut Datenblatt keinen Flash oder
> EEPROM, nur RAM und ROM.

Die sind nicht programmierbar, richtig.
Teilweise muss man die patchen, jedesmal beim Start, um nicht direkt 
unterstützte Touch-Controller zu benutzen, das trift auf die 
gen4-ft813-50ctp-clb wohl aber nicht zu.

> Ich bin definitiv nicht zu faul die Doku zu lesen und mich
> reinzuarbeiten, auch helfe ich gerne bei der Entwicklung dieser Lib in
> Richtung Xmega, wenn das den "der Weg" ist ;-) Nur weiß ich ATM garnicht
> wo ich anfangen soll.

Och, ist nicht so als ob ich die ersten Tage nicht kräftig geflucht 
hätte, vor allem hatte ich auch noch keine Software die gelaufen wäre. 
:-)

Ein Logic-Analyzer ist übrigens hilfreich. :-)

Wenn Du mal schauen magst, ich habe das komplett aufgetrennt, in der 
EVE_target.h sind Basis-Funktionen als Inline-Funktionen angelegt.
Und die EVE_target.c enthält dann Funktionen die komplexer sind, für DMA 
zum Beispiel.

Um jetzt mal ein Target raus zu greifen, das für Arduino AVR ist schön 
kompakt:
1
#if  defined (__AVR__)
2
#include <avr/pgmspace.h>
3
4
#define EVE_CS     9
5
#define EVE_PDN    8
6
7
#define DELAY_MS(ms) delay(ms)
8
9
static inline void EVE_cs_set(void)
10
{
11
 digitalWrite(EVE_CS, LOW); /* make EVE listen */
12
}
13
14
static inline void EVE_cs_clear(void)
15
{
16
 digitalWrite(EVE_CS, HIGH); /* tell EVE to stop listen */
17
}
18
19
static inline void EVE_pdn_set(void)
20
{
21
 digitalWrite(EVE_PDN, LOW); /* go into power-down */
22
}
23
24
static inline void EVE_pdn_clear(void)
25
{
26
 digitalWrite(EVE_PDN, HIGH); /* power up */
27
}
28
29
static inline void spi_transmit(uint8_t data)
30
{
31
 SPDR = data;
32
 asm volatile("nop");
33
 while (!(SPSR & (1<<SPIF)));
34
}
35
36
static inline void spi_transmit_32(uint32_t data)
37
{
38
 spi_transmit((uint8_t)(data));
39
 spi_transmit((uint8_t)(data >> 8));
40
 spi_transmit((uint8_t)(data >> 16));
41
 spi_transmit((uint8_t)(data >> 24));
42
}
43
44
static inline void spi_transmit_burst(uint32_t data)
45
{
46
 spi_transmit_32(data);
47
}
48
49
static inline uint8_t spi_receive(uint8_t data)
50
{
51
 return SPI.transfer(data);
52
}
53
54
static inline uint8_t fetch_flash_byte(const uint8_t *data)
55
{
56
 #if defined(RAMPZ)
57
  return(pgm_read_byte_far(data));
58
 #else
59
  return(pgm_read_byte_near(data));
60
 #endif
61
}

Das ist so alles an Funktionen die spontan für ein Target benötigt 
werden, so ohne DMA.
Weitgehend Einzeiler.
In dem Beispiel habe ich jetzt spi_transmit() mit ein paar mehr Zeilen 
direkt auf Register-Ebene ausgeführt.
Das ist messbar schneller, da zum einen der Funktions Aufruf gespart 
wird, das SPI.transfer() zum anderen aber auch noch mehr macht als 
wirklich benötigt wird, in dem Fall offensichtlich das Lesen der 
angekommenen Daten.

Die XMega unterstützen meine ich DMA,das wäre nett das zu benutzen, aber 
die ersten Schritte gehen sicher auch ohne.

von Robert S. (bimbo385)


Lesenswert?

Moin Rudolph,

erstmal vielen vielen Dank für deine ausführliche Antwort. Ich werde 
mich morgen mal in Ruhe mit deiner Lib und den Bespielen befassen.

Hardware tut schon, ich hab das Keyboard Example von FTDI/4D am laufen 
mit einem Arduino Pro Micro auf 3,3 V, der FFC Breakout-Adapter war beim 
Display dabei. Das war kein Problem. Logicanalyzer hab ich (Saleae Logic 
8) und 4-Ch DSO mit SPI-Dekoder ebenso, kenne mich auch mit SPI aus. 
Also das auf unterster Ebene zu debuggen is prinzipiell kein Problem.

Meine Baustelle ist eher wie bekomme ich da effizent eine GUI zustande 
ohne jetzt das Rad (oder vielmehr den Bargraphen und die Buchstaben) neu 
zu erfinden.
Was ich jetzt noch nicht verstanden habe ist, wer bzw. wo ist dieser 
Coprozessor von dem du sprichst? Im FT813? Das würde heißen der FT813 
weiß doch was ein Button ist und ich kann dem sagen mach Button an 
Stelle XY in Größe mit Text usw? Also ohne auf die einzelen 
Grafikbefehle zurückzugreifen?

Datenblatt lesen werde ich wohl morgen mal in aller Ruhe angehen, also 
insbesondere die Abschnitte zu den Befehlen.

Schönen Abend!
Robert

von Rudolph R. (rudolph)


Lesenswert?

Robert S. schrieb:
> Was ich jetzt noch nicht verstanden habe ist, wer bzw. wo ist dieser
> Coprozessor von dem du sprichst? Im FT813? Das würde heißen der FT813
> weiß doch was ein Button ist und ich kann dem sagen mach Button an
> Stelle XY in Größe mit Text usw? Also ohne auf die einzelen
> Grafikbefehle zurückzugreifen?

Ja genau, der Cmd-Coprozessor ist Teil von dem FT813.
Mit dem werden zum Beispiel auch JPG Bilder dekodiert.

Das sieht in meiner Library zum Beispiel so aus:
EVE_cmd_button_burst(20,20,80,30, 28, toggle_state,"Touch!");

Das ist, X, Y, Breite, Höhe, Font-Nummer, Optionen und Beschriftung.
Zusammen ergibt das 6 32 Bit Werte die über den SPI übertragen werden.


Hmm, ich habe gerade mal im Netz gefischt, kann es sein das ein SPI 
Transfer per DMA mit dem XMEGA verhältnismäßig eklig ist?
Ich lese das was davon das es mit der SPI Unit nur im Slave-Modus DMA 
gibt?
Oder man benutzt den UART im SPI Modus?

Also reines Senden wäre von Vorteil, so bis 4k.

von Robert S. (bimbo385)


Lesenswert?

Hi,

so langsam wird mir klar wie das zusammenspielt. Bin durch Datasheet und 
Programmers Guide durch und für mich wird es wohl darauf hinauslaufen 
ausschließlich Kommandos für den Coprozessor abzusetzen und von der 
Displaylist selbst die Finger zu lassen. Sollte ich doch mal eine Linie 
oder so brauchen geht das ja auch bequem über den Coprozessor.

Da passt deine Lib ja 100tig zu, von daher werde ich jetzt mal versuchen 
ein Testprojekt auf meinen alten A1Xplained (mit dem 128A1) aufzusetzen 
und erstmal SPI ohne DMA zu implementieren.

Ich habe beim Xmega schon mit dem Eventsystem und DMA gearbeitet, 
allerdings gings da um Timer, ADC und Komparator um Samples von einer 
Wechselspannung zu erzeugen.
Laut Datenblatt gibt es keine DMA-Unterstützung für den SPI-Master, 
schade eigentlich. USART im Master SPI-Mode mit DMA soll zumindest laut 
Datenblatt möglich sein. Das wird dann aber frühstens Schritt 2.

Ich hab gelesen, dass man die ersten Kommandos nur mit max 11 MHz 
absetzen darf und erst danach mit max. 30 MHz loslegen soll. Hat deine 
Lib da schon eine "Stelle" für die Umschaltung der Geschwindigkeit, oder 
läuft die generell mit <= 11 MHz? Der Xmega könnte theoretisch bis 16 
MHz (Clkper = 32 MHz und double speed mode) am normalen SPI Master.

Gruß!

: Bearbeitet durch User
von Rudolph (Gast)


Lesenswert?

SPI setup rechne ich eigentlich zur Anwendung, daher habe ich für die 
meisten Targets keine EVE_init_spi() Funktion implementiert und die wird 
auch nicht vorausgesetzt.

Also die Umschaltung von wie-schnell-auch-immer-aber-unter-11MHz vor dem 
Init auf so-schnell-die-hw es erlaubt macht mein Code nicht.

Ich habe auch gerade mal mein "Xplain" ausgegraben, Hust, XMega128A1, 
2008 steht drauf.

von Robert S. (bimbo385)


Angehängte Dateien:

Lesenswert?

Das ging ja einfacher als gedacht.

Vielen Dank schon mal!

Ich werde dann mal deine Lib forken und dir die Tage ein Pullrequest für 
Xmega und und das 4D Display zukommen lassen.

Ist jetzt noch ganz easy busy wait byte transfer per SPI mit 8 MHz.

Aber ich werde mich wohl noch an USART MSPI mit DMA machen und evtl. 
auch die Geschwindigkeit auf max. hochdrehen.

Ich hab festgestellt, dass mein Display jetzt summt. Wo stellst du die 
Frequenz fürs Backlight ein? Scheint daher zu kommen und ist bei dem 
FTDI Beispiel nicht aufgefallen.

Gruß,
Robert

von Rudolph (Gast)


Lesenswert?

Na, das ging fix. :-)

Die PWM für die Beleuchtung wäre REG_PWM_HZ, die fasse ich nicht an und 
die steht daher auf dem Default-Wert von 250Hz.

Analog zu dem
EVE_memWrite8(REG_PWM_DUTY, 0x30);
in der TFT_init() in tft.c wäre das:
EVE_memWrite16(REG_PWM_HZ, 1234);

Da solltest Du aber auf jeden Fall vorher einen Blick ins Datenblatt 
werfen was das Display überhaupt mit macht.

von Robert S. (bimbo385)


Lesenswert?

Moin,

Pullrequest ist raus, Zeitmessung für den Xmega ist noch nicht 
implementiert im Example, dass kann ich noch machen, da wird erstmal nur 
dumm ne Zahl gezählt...

Frequenz setzen geht, Danke für das Beispiel.
Allerdings schweigt sich 4D im Datenblatt über die gewünschte Frequenz 
aus. Im Schaltplan von 4D geht das PWM-Signal an den EN-Eingang eines 
TCS5526 (stromgeregelter Step-Up-Wandler für die LEDs im Backlight) für 
den es kein englisches Datenblatt zu geben scheint (China).

Funktionieren tut anscheinend alles von 250 Hz bis 10 kHz, Tonhöhe 
ändert sich mit der eingestellten Frequenz. Wenn man das Tastverhältnis 
auf 100% stellt ist das Geräusch weg (war auch beim FTDI Example so). 
Ursache ist klar, Lösung ist ne gute Frage...
Ob der Regler dafür gemacht ist um mit dem EN-Signal die LEDs zu dimmen 
wage ich zu bezweifeln. Besser wäre es den Sollwert für den Strom zu 
regeln, das geht aber mit diesem Regler nicht, da der Sollstrom über den 
Wert des Shuntwiderstandes festgelegt wird.

Erstmal schauen, ob man das überhaupt aus dem Gehäuse raushört und ggf. 
stelle ich einfach das Backlight auf 100%.

USART im MSPI Modus kann ich mit der bisherigen Hardware machen, Pins 
gehen bis zum Frontpanelanschluss. Von daher werde ich da weiter machen, 
evtl. am Wochenende.

Gruß,
Robert

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

Danke, auch für das Beispiel, ich habe das eben überflogen und Approved. 
:-)

Tja, und zu dem Backlight-Regler, es gibt ja noch ein paar mehr schöne 
Module in der Art. :-)
Zumal der FT813 jetzt auch nicht mehr ganz der aktuelle Stand ist.

von Ioan Mihai Cozac (Gast)


Lesenswert?

Die Inverterspule einfach mit Kleber dichtmachen, oder gegen eine Chip 
Spule austauschen.

von Rudolph R. (rudolph)


Lesenswert?

Verkleben ist schon mal nicht, da sitzt den Bildern und dem Datenblatt 
nach eine VLCF5020T-100M1R1-1 drauf, das ist eine geschirmte 10µH für 
1,1A mit 5mm x 5mm.

Und ob man die gegen was anderes tauschen kann ist nicht so leicht zu 
sagen, so ohne Datenblatt für den TC5526.

Wobei man das ja auch nicht unbedingt machen will, einmal vielleicht, 
aber nicht wenn man ein paar mehr Displays verbauen will.

Mit den anderen Displays hatte ich sowas noch nicht.
Höchstens Störungen mit meiner billigst Variante eines "Audio" 
"Verstärkers" auf meinem Display-Adapter.

von Karol B. (karol_b135)


Angehängte Dateien:

Lesenswert?

After half a day fighting with new software (new library for eve3) I 
found bug in my software :)
I send in my old sw command cmd_button with options=OPT_CENTER. Now I 
know, that is incorecte (this opt is for CMD_KEYS,CMD_TEXT, CMD_NUMBER 
not for button).

It's interesting that it's working for FT813 but not for BT815 (Black 
screen, nothing on it).

PS. As far i remember (from the begining of EVE, FT800) full screen 
gradinet looks not well. Is there any posibility to make it better?

von Karol B. (karol_b135)


Lesenswert?

Gradient test software (7" 800*480 but its not matter):
1
enum {TAG_EXIT = 100,TAG_X0_PLUS=10,
2
TAG_X0_MINUS,TAG_Y0_PLUS,TAG_Y0_MINUS,TAG_X1_PLUS,TAG_X1_MINUS,TAG_Y1_PLUS,TAG_Y1_MINUS,};
3
void test_screen(void)
4
{
5
  uint8_t CurrTag=0,Pendown=0,PrevTag = 0;
6
  int16_t x0=0, y0=0, x1=0, y1=800;
7
  uint16_t btn_x, btn_x_next, btn_x_space, btn_w, how_many_buttons=4;
8
  char tmp_str[100];
9
  btn_w = 120;
10
  btn_x_space =20;
11
  btn_x_next = btn_w + btn_x_space;
12
  btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2;
13
  //
14
  while(PrevTag!=TAG_EXIT)
15
  {
16
    if(!timDisp)
17
    {
18
      timDisp = 10; // 10* 100times/second
19
      page_start();
20
      EVE_cmd_gradient(x0,y0,ORANGE,x1,y1,0x505050);
21
      
22
      EVE_cmd_dl(DL_COLOR_RGB | WHITE);  // text
23
      for(uint16_t y=0; y<=480; y+=10)  EVE_cmd_line(780,y,800,y,1);
24
25
      EVE_cmd_dl(DL_COLOR_RGB | WHITE);  // text color    
26
      EVE_cmd_text(400,40,31,OPT_CENTER,"Gradient test 1.0");
27
      EVE_cmd_line(220,70,580,70,3);
28
      // display texts+values:
29
      btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2 + btn_w/2;
30
      strcpy(tmp_str,"x0=");strcat(tmp_str,num2string(x0,NONE));
31
      EVE_cmd_text(btn_x, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
32
      strcpy(tmp_str,"x1=");strcat(tmp_str,num2string(x1,NONE));
33
      EVE_cmd_text(btn_x+=btn_x_next, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
34
      strcpy(tmp_str,"y0=");strcat(tmp_str,num2string(y0,NONE));
35
      EVE_cmd_text(btn_x+=btn_x_next, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
36
      strcpy(tmp_str,"y1=");strcat(tmp_str,num2string(y1,NONE));
37
      EVE_cmd_text(btn_x+=btn_x_next, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
38
      // buttons "plus":
39
      btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2;
40
      EVE_cmd_gradcolor(WHITE);      // buttons color
41
      EVE_cmd_dl(DL_COLOR_RGB | BLACK);  // text color
42
      draw_button_text(btn_x, (EVE_VSIZE/2) - (60/2),120,60,WHITE,TAG_X0_PLUS,CurrTag,29,"X0 +10");
43
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 - (60/2),120,60,WHITE,TAG_X1_PLUS,CurrTag,29,"X1 +10");
44
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 - (60/2),120,60,WHITE,TAG_Y0_PLUS,CurrTag,29,"Y0 +10");      
45
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 - (60/2),120,60,WHITE,TAG_Y1_PLUS,CurrTag,29,"Y1 +10");
46
      // buttons "minus":
47
      btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2;
48
      EVE_cmd_gradcolor(GRAY_LIGHT2);    // buttons color
49
      EVE_cmd_dl(DL_COLOR_RGB | BLACK);  // text color
50
      draw_button_text(btn_x, (EVE_VSIZE/2) + (60),120,60,WHITE,TAG_X0_MINUS,CurrTag,29,"X0 -10");
51
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 + (60),120,60,WHITE,TAG_X1_MINUS,CurrTag,29,"X1 -10");
52
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 + (60),120,60,WHITE,TAG_Y0_MINUS,CurrTag,29,"Y0 -10");
53
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 + (60),120,60,WHITE,TAG_Y1_MINUS,CurrTag,29,"Y1 -10");
54
      // button "exit":
55
      draw_button_text(10,480-40-10,120,40,YELLOW,TAG_EXIT,CurrTag,29,"exit");
56
      // touch:
57
      strcpy(tmp_str,"CurrTag=");strcat(tmp_str,num2string(CurrTag,NONE));
58
      EVE_cmd_text(2, 20,26,EVE_OPT_CENTERY,tmp_str);
59
      strcpy(tmp_str,"Pendown=");strcat(tmp_str,num2string(Pendown,NONE));
60
      EVE_cmd_text(2, 40,26,EVE_OPT_CENTERY,tmp_str);
61
      strcpy(tmp_str,"PrevTag=");strcat(tmp_str,num2string(PrevTag,NONE));
62
      EVE_cmd_text(2, 60,26,EVE_OPT_CENTERY,tmp_str);
63
      //
64
      page_stop();
65
    }
66
    CurrTag = EVE_memRead8(REG_TOUCH_TAG);
67
    Pendown = ((EVE_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01);
68
    if((CurrTag != 0) && CurrTag !=255)//if(( 1 == Pendown) && (CurrTag != PrevTag))
69
    {
70
      PrevTag = CurrTag;
71
      if(PrevTag == TAG_X0_PLUS && x0 < 1000) x0 +=10;
72
      if(PrevTag == TAG_X0_MINUS ) x0 -=10; //
73
      if(PrevTag == TAG_Y0_MINUS ) y0 -=10; //&& y0 >= 10
74
      if(PrevTag == TAG_Y0_PLUS && y0 < 600) y0 +=10;
75
      
76
      if(PrevTag == TAG_X1_PLUS && x1 < 1000) x1 +=10;
77
      if(PrevTag == TAG_X1_MINUS ) x1 -=10;// && x1 >= 10
78
      if(PrevTag == TAG_Y1_MINUS) y1 -=10; // && y1 >= 10
79
      if(PrevTag == TAG_Y1_PLUS && y1 < 6000) y1 +=10;
80
      buzzer(100,1,1);
81
    }
82
  }
83
  buzzer(100,100,3);
84
  while(!(EVE_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01){};
85
}
Also there:
1
 void buzzer(unsigned short int on, unsigned short int off, unsigned char repeat)
 for simple sound from electromagnetic buzzer
and:
1
 
2
void page_start(void)
3
{
4
  EVE_cmd_dl(CMD_DLSTART); // Start the display list
5
  EVE_cmd_dl(DL_CLEAR_RGB | BLACK); // Set the default clear color to X WHITE BLACK
6
  EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
7
}
becouse I use this 3 command a lot, as well:
1
void page_stop(void)
2
{
3
  EVE_cmd_dl(DL_DISPLAY);  // Instruct the graphics processor to show the list
4
  EVE_cmd_dl(CMD_SWAP); // Make this list active
5
  EVE_cmd_execute();
6
  _delay_ms(5);
7
  uint8_t int_mask = EVE_memRead8(REG_INT_FLAGS);
8
}
and:
1
void draw_button_text(uint16_t x,uint16_t y, uint16_t w, uint16_t h, uint32_t fg_color, uint8_t tag, uint8_t CurrTag,uint8_t font,const char *txt)
2
{
3
  EVE_cmd_dl(TAG_MASK(1));
4
  EVE_cmd_fgcolor(fg_color);        // button color
5
  EVE_cmd_dl(TAG(tag));
6
  //
7
  uint16_t opt=0;
8
  if(CurrTag == tag) opt =OPT_FLAT;// 256;
9
  EVE_cmd_button(x,y,w,h,font,opt,"");//(OPT_FLAT&(CurrTag&tag))
10
  EVE_cmd_text(x+(w/2), y+(h/2),font,OPT_CENTER,txt);
11
  EVE_cmd_dl(TAG_MASK(0));
12
}

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Is there actually an issue left?

For a quick test I just copied this line in my basic demo:
EVE_cmd_gradient_burst(0,LAYOUT_Y1,ORANGE,EVE_HSIZE,EVE_VSIZE,0x505050);

And the result is attached, it seems to be doing what it is supposed to 
do.

This is running on a RiTFT50, so BT815, 5" and 800x480.
The controller is an ATSAME51J19A, 120MHz M4F running bare-metal with 
the SPI at 15MHz and with DMA, so the 7µs for the display-refresh is 
correct.

von Karol B. (karol_b135)


Angehängte Dateien:

Lesenswert?

There is no more an issue left, any big one ;)

Maybe there is something wrong in initialisation? Because yours command:
1
 EVE_cmd_gradient_burst(0,LAYOUT_Y1,ORANGE,EVE_HSIZE,EVE_VSIZE,0x505050);
 give me this result: (image)

von Rudolph R. (rudolph)


Lesenswert?

What is wrong in your image?
This is a gradient from orange to grey, from top left to down right.

My orange is this:
#define ORANGE  0xffa500UL

I also tried these, slightly modified from the programming manual:
EVE_cmd_gradient_burst(0, LAYOUT_Y1, 0x0000ff, EVE_HSIZE, LAYOUT_Y1, 
0xff0000);
EVE_cmd_gradient_burst(0, LAYOUT_Y1, 0x808080, 0, EVE_VSIZE, 0x80ff40);
EVE_cmd_gradient_burst(0, LAYOUT_Y1, 0x808080, EVE_HSIZE, EVE_VSIZE, 
0x80ff40);

And these come out as displayed in the programming manual.

I also tried it in EVE Screen Editor:
CMD_GRADIENT(0, 0, 0x0000FF, 800, 0, 0xff0000)

This comes out pretty much the same.

von Karol B. (karol_b135)


Angehängte Dateien:

Lesenswert?

How about now? Could you see these colored stripes in the picture? 
Gradient isn't smooth. In my opinions its look awful ;)
Do you understand my problem? If so, could you pointer me where should I 
look solve?

von Karol B. (karol_b135)


Angehängte Dateien:

Lesenswert?

This is the best picture (attached image). Right white lines are at each 
10 pixels. So it can by our scale, then we can see that darker stripes 
are at near each 10 pixels.
Until I bought new tft with BT815 I was thinking that is becouse only 6 
from 8 lines for color data was connected (only 16 bits of color, not 
24), but now its fore sure, 24 bits color.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

The diagonal lines?
I have no good idea what these are.

Is your supply stable?
That could be a ripple in the supply voltage due to barely enough 
current available.

What happens when you remove everything else from the display-list?
Especially the buttons.

von Karol B. (karol_b135)


Lesenswert?

This is as simple as can be:
1
void quick_test(void)
2
{
3
  EVE_memWrite8(REG_PWM_DUTY, 13);
4
  EVE_cmd_dl(CMD_DLSTART); // Start the display list
5
  EVE_cmd_dl(DL_CLEAR_RGB | BLACK); // Set the default clear color to X WHITE BLACK
6
  EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
7
  EVE_cmd_gradient(0,0,ORANGE,0,480,0x505050);
8
  EVE_cmd_dl(DL_DISPLAY);
9
  EVE_cmd_dl(CMD_SWAP);
10
  EVE_cmd_execute();
11
  while(1);
12
}
The same efects. Power suply is stable. What about EVE_init()? Can be 
there something wrong (for this screen)?
I have this function with no changes.
1
 #define EVE_EVE3_70

von Rudolph R. (rudolph)


Lesenswert?

Karol B. schrieb:
> I have this function with no changes. #define EVE_EVE3_70

Hmmm, up there you wrote you have an EVE_RiTFT70.
The EVE3_70 is a resistive-touch display with BT816 from Matrix Orbital.

Please try "EVE_RiTFT70".

von Karol B. (karol_b135)


Lesenswert?

It's no matter, i have tried many of them. What you thinking about REG 
DITHER and so on? I tried:
1
 EVE_memWrite8(REG_DITHER, 1);
 and
1
 EVE_memWrite8(REG_DITHER, 0);
with no changes.

von Rudolph R. (rudolph)


Lesenswert?

As I wrote, I have no good idea what this is.

I am mostly ignoring REG_DITHER and leaving in on default, 1.

I had minor issues with CSPREAD but then it is active for RiTFT70 but 
disabled for EVE3-70 as specified by their datasheets.

von Karol B. (karol_b135)


Lesenswert?

Thanks a lot. I will try tomorrow with Riverdi, this company is from 
Poland  as  I am, so it can be easy to understand each other ;)
My english is poor like the gradient quality :D

Rudolph could you explain how to deal with graphics (*.jpg, *.bmp etc)?
I have two hardware versions (old one with FT813 + ATMEGA128 + SDcard 
interface and new one with BT815 + 25Q64JVSIQ + ATMEGA128 + SDcard 
interface, both with 7" 800x480 TFT from Riverdi).
I haven't needed a SD card before, so I worry to use it. This is very 
important project. I worry about stable work, potential memory card 
errors and so on.
What is the best solutions?
How to prepare image files, adress it for EVE etc? image-convert 0.7 is 
enougth?
1
 /* 100x100 test-picture in .jpg format */
2
const uint8_t pic[3867] PROGMEM =..
Why 3876? When I saved pic[3867] as data.c then file was 22,7 KB..

Schönen Abend :)
Karol

von Rudolph R. (rudolph)


Lesenswert?

Karol B. schrieb:
> I haven't needed a SD card before, so I worry to use it.

I can not help with that, the last time I used an SD card was for SD2IEC 
and I did not do the software for that one.

> How to prepare image files, adress it for EVE etc? image-convert 0.7 is
> enougth?

That is okay but terribly outdated. :-)
Try the EVE Asset Builder: https://brtchip.com/eve-toolchains/

>/* 100x100 test-picture in .jpg format */
>const uint8_t pic[3867] PROGMEM =..
>Why 3876? When I saved pic[3867] as data.c then file was 22,7 KB..

It really is what it says, a .jpg file, this is why it is used with 
CMD_LOADIMAGE().

von Daniel S. (snipod)


Lesenswert?

Hi Rufolph,
bin heute mal dazu gekommen am Repo zu ziehen und sieht echt alles tip 
top aus...

Ich habe ne Frage bezüglich ner custom Font:
1. Mit Hilfe des EVE Asset Builders erstelle ich mir eine .rawh File
2. Aus diesem mache ich dann eine Header Datei, mit den Daten als 
uint8_t Array.
3. Das Array lade ich mit EVE_memWrite_sram_buffer? Oder 
EVE_cmd_loadimage? an Position X
4. Ich setze die Font mit EVE_cmd_setfont2(12, X, 32) an das Handle 12 - 
sofern die Font bei ASCII 32 beginnt
5. ich kann die Font normal nutzen auf dem Handle 12

Irgendwo hab ich nen Fehler... und wie wäre das mit setfont(1) - dafür 
muss man ja noch bisschen was Einstellen

von Rudolph R. (rudolph)


Lesenswert?

Ich habe in der einfachen Demo auch einen UTF-8 font mit drin der bei 
BT81x displays in das externe FLASH geladen werden und von da benutzt 
werden kann.
Also im ASTC format.
Mit den FT81x ist man auf 127 Zeichen beschränkt.

Der ist in meinem letzten Foto auch zu sehen:
https://www.mikrocontroller.net/attachment/488936/20210114_193133.jpg
Das "EVE Demo" ist nicht so ganz original so. :-)

Wie man da hin kommt habe ich hier mal beschrieben:
http://www.lcdforums.com/forums/viewtopic.php?f=45&t=6894&sid=c3e51632d7eac81d3d95d1a32d81c7c4

Aber ich habe das gerade mal ausprobiert und einen Font mit dem EVE 
Asset Builder in das "Legacy" Format umgewandelt.

Die .rawh die dabei raus kommt würde ich einfach ignorieren.
Die ebenfalls generierte .c als Beispiel zeigt im Grunde wie das in den 
EVE kommt:
#define FONT_HANDLE       (1)
#define FONT_FILE_ADDRESS (RAM_G + 1000)
#define FIRST_CHARACTER   (32)

Gpu_Hal_LoadImageToMemory(phost, "../../../L8/ARCADE_R_12_L8.raw", 
FONT_FILE_ADDRESS, LOAD);

Gpu_CoCmd_SetFont2(phost, FONT_HANDLE, FONT_FILE_ADDRESS, 
FIRST_CHARACTER);
Gpu_CoCmd_Text(phost, 50, 50, FONT_HANDLE, 0, "AaBbCcDdEeFf");

Also die .raw wird in dem Beispiel einfach an RAM_G+1000 geschrieben, so 
wie das beim Konvertieren eingestellt war.
Also das muss man schon wissen wohin das soll.

Was ich jetzt machen würde und was ich gerade soweit ausprobiert habe, 
ich würde ja die .raw mit dem "Asset Compressor" packen, auf die Art 
habe ich aus der 13kB .raw für den Font gerade eine 3kB .zlib gemacht.

Dann mit dem "BIN2C" Modul im EVE Asset Compressor daraus ein .c file 
generieren mit dem Array.

Das würde ich bei mir in die tft_data.c / tft_data.h einbauen.
Und es einfach mit CMD_INFLATE laden:

EVE_cmd_inflate(MEM_FONT, font_array, sizeof(font_array));

Danach dann noch irgendwo das hier wie bei FTDI / BRT:
EVE_cmd_setfont2(12,MEM_FONT,32);
EVE_cmd_text(EVE_HSIZE/2, 15, 12, EVE_OPT_CENTERX, "EVE Demo");

Ich habe jetzt nur nich probiert ob der Font so angezeigt wird, ich 
wüsste aber auch keinen Grund warum nicht.

von Matrix O. (Firma: Matrix Orbital) (matrixorbital)


Angehängte Dateien:

Lesenswert?

Hello Everyone! First of all thank you to Rudolph for all the work he 
has done, we are thankful!

I also wanted to show two new EVE4 displays, a 10.1" 1280x800 and a 4" 
720x720 we are just about to release!

von Rudolph R. (rudolph)


Lesenswert?

Matrix O. schrieb:
> Hello Everyone! First of all thank you to Rudolph for all the work he
> has done, we are thankful!

Thank you for your kind words!
It has been a while but I am still enjoying the ride. :-)

> I also wanted to show two new EVE4 displays, a 10.1" 1280x800 and a 4"
> 720x720 we are just about to release!

Sweet!
Looks like I am buying a bigger 3D printer for my lab at work this year. 
:-)

von Karol (Gast)


Lesenswert?

Matrix O. schrieb:
> I also wanted to show two new EVE4 displays, a 10.1" 1280x800

> there have been some challenges with the code... but here it is!

Could you tell something more about it?

Can I easily use this lcd with Rudolph library?

von Rudolph R. (rudolph)


Lesenswert?

Karol schrieb:
> Can I easily use this lcd with Rudolph library?

You will, I have not put in profiles for these as I have not seen the 
exact specs yet but that should be merely a formality.
BT817/BT818 support with the new commands and registers is in since 
Bridgetek officially launched these.

von Daniel S. (snipod)


Lesenswert?

Rudolph R. schrieb:

> Dann mit dem "BIN2C" Modul im EVE Asset Compressor daraus ein .c file
> generieren mit dem Array.
>
> Das würde ich bei mir in die tft_data.c / tft_data.h einbauen.
> Und es einfach mit CMD_INFLATE laden:
>
> EVE_cmd_inflate(MEM_FONT, font_array, sizeof(font_array));
>
> Danach dann noch irgendwo das hier wie bei FTDI / BRT:
> EVE_cmd_setfont2(12,MEM_FONT,32);
> EVE_cmd_text(EVE_HSIZE/2, 15, 12, EVE_OPT_CENTERX, "EVE Demo");
>
> Ich habe jetzt nur nich probiert ob der Font so angezeigt wird, ich
> wüsste aber auch keinen Grund warum nicht.

Perfekt, habe es genau so ausprobiert und es funktioniert jetzt.
Ich hatte wohl zwei fehler :) EVE_cmd_inflate anstatt 
EVE_cmd_inflate_burst... und anscheinend möchte er die font nicht an 
stelle 0 schreiben, schreibe ich sie an EVE_RAM_G + 1000 (also 1000) 
klappts.

Das mit dem Bin2c Modul ist echt nützlich, hatte mir dafür schon mein 
eigenes Tool programmiert, aber das kann ich jetzt getrost wegwerfen :) 
Habe nicht mitbekommen, dass es mittlerweile die 2.1 gibt vom Asset 
Builder.

Ich arbeite aktuell noch mit dem FT815Q, da mein Prototyp mit dem NHD 
Display läuft... mein fertiges Display mit eigener Platine hat aber 
einen BT815Q und funktioniert mittlerweile auch sehr gut :) Warte nur 
noch auf mein Panel mit Touch... Für die Serie gehe ich dann vielleicht 
sogar direkt zum 817q über. Muss mir noch mal anschauen was das für die 
Platine bedeutet (vielleicht ist er ja sogar drop in kompatibel...)



Eine Frage zum Fash Builder:
Wenn ich jetzt zB einige Bilder und Font(s) im Flash ablegen möchte, 
würde ich da die komprimierten oder unkomprimierten Daten nehmen? Wenn 
ich das richtig verstanden habe, muss ich ohnehin alles in den RAM_G 
laden, weshalb - sofern genug Platz da ist - es nicht unbedingt Sinnvoll 
ist, die Assets zu komprimieren, oder?

von Daniel S. (snipod)


Lesenswert?

Ah und noch eine Frage (sorry...) zu den Pointern im RAM_G.

Wenn ich mehrere Assets (Bild, Font, was auch immer) in den RAM_G laden 
möchte, dann muss ja der Pointer des nächsten Assets, der Pointer des 
vorheriges Assets + die RAW Größe sein.

Bsp.:
Font_1 : PTR = 1000, RAW_SIZE = 32638
Font_2 : PTR = FONT_1.PTR + FONT_1.RAW_SIZE = 33638, RAW_SIZE = 50152
...

Ich habe das mal exemplarisch versucht, aber bekomme die zweite Font 
einfach nicht zum Laufen. Wenn ich jeweils nur eine der beiden Fonts 
lade, funktionieren sie.
1
    ESP_LOGI("hmi", "writing light to: %u", MEM_ADR_MONTSERRAT_LIGHT_16);
2
    EVE_cmd_inflate(MEM_ADR_MONTSERRAT_LIGHT_16, Montserrat_Light_16_L8_ZLib, sizeof(Montserrat_Light_16_L8_ZLib));
3
    uint32_t size = EVE_cmd_getptr();
4
    ESP_LOGI("hmi", "ptr: %u", size);
5
    ESP_LOGI("hmi", "writing black to: %u", MEM_ADR_MONTSERRAT_BLACK_20);
6
    EVE_cmd_inflate(MEM_ADR_MONTSERRAT_BLACK_20, Montserrat_Black_20_L8_ZLib, sizeof(Montserrat_Black_20_L8_ZLib));
7
    size = EVE_cmd_getptr();
8
    ESP_LOGI("hmi", "ptr: %u", size);

Resultat:
I (1000) hmi: writing light to: 1000
I (1063) hmi: ptr: 33638
I (1063) hmi: writing black to: 50152
I (1152) hmi: ptr: 105020

(soweit) ja eigentlich alles gut... nur dass meine zweite font nicht 
mehr richtig funktioniert :(

Was mach ich denn nur falsch...?

von Rudolph (Gast)


Lesenswert?

Daniel S. schrieb:
> Ich hatte wohl zwei fehler :)
> EVE_cmd_inflate anstatt EVE_cmd_inflate_burst...

Äh, was? Es gibt keine EVE_cmd_inflate_burst(). :-)
Es gibt so ein paar Kommandos die komplett untauglich für Display-Listen 
sind, die eben CMD_INFLATE und CMD_LOADIMAGE.

> und anscheinend möchte er die font nicht an stelle 0 schreiben,
> schreibe ich sie an EVE_RAM_G + 1000 (also 1000) klappts.

Na das wird ja in dem EVE Asset Builder eingestellt beim Konvertieren,
Default-Wert ist 1000, warum auch immer.

> Habe nicht mitbekommen, dass es mittlerweile die 2.1 gibt vom Asset
> Builder.

Dazu habe es auch keine Ankündigung.

> Für die Serie gehe ich dann vielleicht
> sogar direkt zum 817q über. Muss mir noch mal anschauen was das für die
> Platine bedeutet (vielleicht ist er ja sogar drop in kompatibel...)

Ja, die sind drop-in kompatibel.

> Eine Frage zum Fash Builder:
> Wenn ich jetzt zB einige Bilder und Font(s) im Flash ablegen möchte,
> würde ich da die komprimierten oder unkomprimierten Daten nehmen? Wenn
> ich das richtig verstanden habe, muss ich ohnehin alles in den RAM_G
> laden, weshalb - sofern genug Platz da ist - es nicht unbedingt Sinnvoll
> ist, die Assets zu komprimieren, oder?

Nun, das kommt darauf an, ASTC komprimierte Bilder und Fonts kann man 
direkt aus dem Flash benutzen, mein Demo-Code benutzt doch einen UTF-8 
Font aus dem Flash.
Dafür muss man die .glpyh und die .xfont in das Flash schreiben, direkt 
so zusammen und dann beim Start die .xfont irgendwohin in das RAM_G 
kopieren.

Man muss nur etwas aufpassen, die Bandbreite von dem Flash ist begrenzt, 
ich hatte schon seltsame Fehler mit zu vielen Bildern auf einmal und bei 
Fonts mit zu vielen unterschiedlichen Zeichen.

Und selbst wenn man einen Font aus dem RAM_G benutzt, die sind richtig 
gut komprimierbar, weil das viele einzelne Bilder sind.

> Wenn ich mehrere Assets (Bild, Font, was auch immer) in den RAM_G laden
> möchte, dann muss ja der Pointer des nächsten Assets, der Pointer des
> vorheriges Assets + die RAW Größe sein.
>
> Bsp.:
> Font_1 : PTR = 1000, RAW_SIZE = 32638
> Font_2 : PTR = FONT_1.PTR + FONT_1.RAW_SIZE = 33638, RAW_SIZE = 50152

Plus vielleicht mal ein paar Bytes für Alignment.
Ich tendiere dazu die Adressen auf 0xnnnn00 zu setzen.

> (soweit) ja eigentlich alles gut... nur dass meine zweite font nicht
> mehr richtig funktioniert :(

Hast Du beim Konvertieren des zweiten Fonts denn die Adresse an der 
dieser liegen wird denn mit angegeben?

Die Glyphen müssen ja irgendwie gefunden werden, in den Daten für den 
Font sind die Adressen eincodiert.

Wenn man einen UTF-8 font für die BT81x konvertiert dann stehen diese 
Daten in der .xfont Datei.
Und wenn man eine .glyph und eine .xfont mit dem EVE Asset Builder in 
das FLASH brennt, dann werden die Daten in der .xfont automatisch 
angepasst.

von Daniel S. (snipod)


Lesenswert?

Rudolph schrieb:
> Äh, was? Es gibt keine EVE_cmd_inflate_burst(). :-)
> Es gibt so ein paar Kommandos die komplett untauglich für Display-Listen
> sind, die eben CMD_INFLATE und CMD_LOADIMAGE.

Ähh sorry, ich meinte natürlich CMD_SETFONT2...

Rudolph schrieb:
> Na das wird ja in dem EVE Asset Builder eingestellt beim Konvertieren,
> Default-Wert ist 1000, warum auch immer.

Das war der richtige hint. Ich war davon ausgegangen, dass die Addressen 
in der Tabelle am Anfang der Font relativ zur Startadresse sind. Dass 
die Font natürlich genau wissen muss, wo sie liegt... Kaum stellt man 
das mit richtig ein, funktioniert das einwandfrei.
Vielen Dank ;)

Rudolph schrieb:
> Ja, die sind drop-in kompatibel.

1A dann tausch ich die grad auf der BOM aus :)

Rudolph schrieb:
> Wenn man einen UTF-8 font für die BT81x konvertiert dann stehen diese
> Daten in der .xfont Datei.
> Und wenn man eine .glyph und eine .xfont mit dem EVE Asset Builder in
> das FLASH brennt, dann werden die Daten in der .xfont automatisch
> angepasst.

Das muss ich dann auch noch versuchen. Auf meinem PCB habe ich mal 128 
MB Flash platziert - kostet ja nix... Muss mir nur überlegen wie ich das 
Sinnvollerweise für eine eventuelle "serien" Fertigung mache.

von Rudolph R. (rudolph)


Lesenswert?

Look at what I found:
https://riverdi.com/product-category/intelligent-displays/bt817q/

Earlier this week Riverdi launched a complete lineup of BT817 displays.
I could not find any of these at distributors yet.

I am a wee bit concerned about the touch controller Riverdi is using.
It is a ILI2132A from Ilitek and I have no idea yet if the BT817 
directly supports it or if it needs to be patched - and if so, how.

Also there is no sample-code yet from Riverdi.
Their Github repository is not getting much attention.

I just checked the datasheets and the displays with the same size do 
have the same display parameters listed.
All the datasheets do have a "PRELIMINARY" watermark though.
Well, the parameters may be wrong as it is the case with at least the 
RVT50UQB for example.

von Ioan Mihai Cozac (Gast)


Lesenswert?

How works the rotation in case of the primitives, for example a square 
with the corners to the margins of the screen, also rotated 45 deg? Has 
someone succes with this? I have tried but failed so far, CMD_ROTATE 
shows only garbage on the screen instead of the rotated symbols. The 
JPEGs rotate properly.

von Rudolph R. (rudolph)


Lesenswert?

Ioan Mihai Cozac schrieb:
> How works the rotation in case of the primitives, for example a
> square
> with the corners to the margins of the screen, also rotated 45 deg? Has
> someone succes with this? I have tried but failed so far, CMD_ROTATE
> shows only garbage on the screen instead of the rotated symbols. The
> JPEGs rotate properly.

Please add a couple of lines do demonstrate what you mean.
And perhaps two images.

von Ioan Mihai Cozac (Gast)


Angehängte Dateien:

Lesenswert?

I try to make my own spinner, 2 sectors rotating around a circle.
The sample code is this:
1
  float t = (spin / 360.00) * PI;
2
  int r = (int)(100 * cos(t));  // SPIN RADIUS
3
  FT8_cmd_dl(COLOR_MASK(0, 0, 0, 0));
4
  FT8_cmd_dl(STENCIL_OP(FT8_INCR, FT8_INCR));
5
  FT8_cmd_dl(DL_BEGIN | FT8_RECTS);
6
  FT8_cmd_dl(LINE_WIDTH(1 * 16));
7
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
8
  FT8_cmd_dl(VERTEX2F(540 * 16, 230  * 16));
9
  FT8_cmd_dl(VERTEX2F(340 * 16, 330 * 16));
10
  FT8_cmd_dl(VERTEX2F(440 * 16, 430 * 16));
11
  FT8_cmd_dl(DL_BEGIN | FT8_POINTS);
12
  FT8_cmd_dl(POINT_SIZE(60 * 16));
13
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
14
  FT8_cmd_dl(STENCIL_FUNC(FT8_GEQUAL, 2, 255));
15
  FT8_cmd_dl(COLOR_MASK(255, 255, 255, 255));
16
  FT8_cmd_dl(DL_COLOR_RGB | RED);
17
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
18
  FT8_cmd_dl(LINE_WIDTH(10 * 16));
19
  FT8_cmd_dl(DL_COLOR_RGB | WHITE);
20
  FT8_cmd_dl(POINT_SIZE(40 * 16));
21
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
22
  /*
23
  FT8_cmd_dl(DL_BEGIN | FT8_BITMAPS);
24
  FT8_cmd_dl(CMD_LOADIDENTITY);
25
  FT8_cmd_rotate((45 / 360) * 65536);
26
  FT8_cmd_dl(CMD_SETMATRIX);
27
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
28
  */
29
  FT8_cmd_dl(DL_COLOR_RGB | BLACK);
30
  //FT8_cmd_number(420, 315, 28, 0, spin);
31
  //FT8_cmd_number(420, 330, 28, 0, r);
I know its an old library version but i make tests on an older display, 
if it works i add the methods to the newer software.
The spin var is a loop counter for the rotating effect.
If i add the commented part it shows the garbage pixels, like the second 
picture.

In the example codes from FTDI/Bridgetek there are many moving parts but 
i saw no rotating squares yet. Maybe in the LOGO animation but i am not 
sure.

von Rudolph R. (rudolph)


Lesenswert?

Hmm, I have no idea what these fragments are.
And where is the square in this?

My take on this would be to use an image of the outer segments with 
alpha channel and put a dot in the center of it.

I just tried this in EVE Screen Editor and it works.
Only the image I quickly cobbled up with paint.net was a bit fuzzy on 
the outer ring when being rotated.

von Ioan Mihai C. (mihaicozac)


Lesenswert?

The square was just a general idea for the spinning concept, in my 
sketch there are 2 squares, the red ones, but only a part of them are 
visible (they go through masking and stencil so only the sector part is 
visible.
So is seams that the rotation works only on bitmaps not on primitives, i 
should take a part of the screen and process as a bitmap but this takes 
room in GRAM and with my main program it is almost full already. I will 
try the old road again with many thin segments placed in circle side by 
side, although this method implies a very long display list.

von Anguel S. (anguel)


Lesenswert?

Hallo Rudolph,

ich schaue schon länger in Richtung FTDI/BRT EVE, hatte mich aber bis 
heute aufgrund der schlechten Doku nicht so ganz daran getraut :-) Heute 
habe ich es endlich gewagt und mir die gefühlt 101 Appnotes und 
zugehörige Beispiele von BRT angeschaut und sogar angefangen zu lesen. 
Wollte ursprünglich den Screen Designer nutzen, der aber nur mit deren 
Nischen-MCU FT9xx funktioniert. Zwischenzeitlich bin ich immer wieder 
auf deine qualifizierten Beiträge in den Foren und deine Lib gestoßen - 
Respekt!

Rudolph R. schrieb:

> Anstatt das jedesmal wieder und komplett redundant zu übergeben habe ich
> den entscheidenden Parameter "cmdOffset" zu einer globalen Variable
> gemacht

Das war eigentlich das Erste was mich bei deren erster "API" gestört 
hat.
Vielleicht war es Absicht, damit sich das "cmdOffset" beim Entwickler 
ins Gehirn einbrennt ;-)

> 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.

Es ist für mich nicht ganz nachvollziehbar, warum die so viele Anläufe 
und Appnotes brauchen. Vor allem scheinen die immer noch keine logische 
und universelle Lösung zu haben. Evtl. Bachelorarbeiten oder 
Praktikanten? Dass das auch mit dem inzwischen lange verfügbaren eigenen 
Screen Editor noch nicht kompatibel ist, wundert mich noch mehr.
Und was soll der Mist mit Keil bei STM32 bei einer angeblich inzwischen 
portablen Lösung. Inzwischen ist GCC der offizielle Compiler der 
offiziellen STM32CubeIDE und der ist wieder mal nicht dabei...
Ich wette, dass die min. 100x mehr Chips verkauft hätten, wenn die eine 
anständige Library mit anständiger Doku mal entwickelt hätten.

> Nur ist mein Code aktuell mit dem gleichen Controller eine ganze Ecke
> schneller.

Gibt es momentan eigentlich etwas, was deine Lib nicht kann, was die 
neue von BRT kann? Kann man mit deiner Lib evtl. auch auf dem PC 
emulieren?

Werde mir wohl die neuen Riverdi-Diplays mit BT817 zulegen, wenn die mal 
verfügbar sind. Aber deren Lib wollte ich mir nicht auch noch antun, 
oder was meinst du dazu?

Viele Grüße,

Anguel

von Rudolph R. (rudolph)


Lesenswert?

Anguel S. schrieb:
...
Hrmm, kein Kommentar. :-)

> Gibt es momentan eigentlich etwas, was deine Lib nicht kann, was die
> neue von BRT kann? Kann man mit deiner Lib evtl. auch auf dem PC
> emulieren?

Das ist genau das worüber ich noch gar nicht nachgedacht habe.
Wenn ich unter Windows mit EVE spielen möchte dann starte ich den EVE 
Screen Editor.
Matrix Orbital hat in der Richtung was gemacht.

Rein funktional habe ich bis hoch zum BT817/BT818 alles drin.

Bridgetek hat noch Support für BeagleboneBlack, MSP430, FT9xx, 
PIC18F46K22 und RaspberryPi mit der BRT_AN_025.
Mit keinen von denen habe ich jemals was gemacht und auch keine Anfragen 
in der Richung gehabt.

> Werde mir wohl die neuen Riverdi-Diplays mit BT817 zulegen, wenn die mal
> verfügbar sind. Aber deren Lib wollte ich mir nicht auch noch antun,
> oder was meinst du dazu?

Deren Lib basiert ja auf der von Bridgtek, was das mit dem "phost" soll 
ist mir immer noch nicht ganz klar.
Die funktioniert sicher auch.
Und sie haben Support für Linux. (äh, okay?)

Auf jeden Fall werde ich die Timings für die neuen Module noch einbauen, 
bisher ist die Doku allerdings noch etwas dünn, so Preliminary, und 
darauf in den nächsten Wochen an gar ein RVT101HVBNWC00-B  heran zu 
kommen mache ich mir gerade nicht viel Hoffnung.
Ich muss mal schauen was die mit dem neuen Touch-IC machen.

: Bearbeitet durch User
von Anguel S. (anguel)


Lesenswert?

Rudolph R. schrieb:

> Matrix Orbital hat in der Richtung was gemacht.

Danke, schaue ich mir mal an.

> Deren Lib basiert ja auf der von Bridgtek, was das mit dem "phost" soll
> ist mir immer noch nicht ganz klar.

Ist wirklich eigenartig. Wollten die damit vielleicht mal mehrere 
Displays gleichzeitig ansteuern können?

> Ich muss mal schauen was die mit dem neuen Touch-IC machen.

Habe Riverdi gestern diesbezüglich mal gefragt, die sagten das ginge 
alles über den EVE chip, oder meinst du "Teufel im Detail" und so? ;-)

Wie ist das eigentlich mit der Kalibrierung bei diesen neuen 
Capacitive-Touch Panels, Riverdi sagte, dass man nur ein Display 
kalibrieren müsste und diese Daten dann für alle verwenden, wobei ich 
mich dann natürlich frage, warum die diese Daten dann nicht einfach 
irgendwo fest definieren.

Achso, noch eine generelle Frage: Werden eigentlich bei EVE diese 
Tag-Events schon beim Touch ausgelöst, oder kann man das auch so machen, 
dass die erst beim Wegnehmen des Fingers getriggert werden und das dann 
nur wenn man noch im Bereich des Buttons ist, also wie bei einem echten 
Touch-OS (iOS, Android)? Ich habe vor Kurzem nämlich mit 4DSystems 
Displays und deren Entwicklungsumgebung gearbeitet und das nervige war, 
dass man da mit dem Finger einmal über das Display ziehen konnte und 
alle Buttons auf dem Weg wurden dann mal eben getriggert, was IMHO für 
ein halbwegs professionelles Gerät ein absolutes No-Go ist. Das komische 
Verhalten ließ sich da auch nicht ändern :-)

Grüße

Anguel

von Rudolph (Gast)


Lesenswert?

Anguel S. schrieb:
>> Deren Lib basiert ja auf der von Bridgtek, was das mit dem "phost" soll
>> ist mir immer noch nicht ganz klar.
>
> Ist wirklich eigenartig. Wollten die damit vielleicht mal mehrere
> Displays gleichzeitig ansteuern können?

Das mag sein, für sowas aber 99% der Anwendungen auszubremsen ist etwas 
seltsam, zumal ich für sowas auch noch kein Beispiel gesehen habe.
Was ich im Moment mache ist eine kleine Platine mit einem CAN-FD fähigen 
Controller mit in das Gehäuse zu packen.
Damit könnte ich auch mehrere davon parallel betreiben.

>> Ich muss mal schauen was die mit dem neuen Touch-IC machen.
>
> Habe Riverdi gestern diesbezüglich mal gefragt, die sagten das ginge
> alles über den EVE chip, oder meinst du "Teufel im Detail" und so? ;-)

Ja, genau, Details, der Touch-Controller taucht in den Bridgetek 
Unterlagen erstmal nicht auf.
Eine Mail hatte ich auch geschickt, aber praktisch keine Antworten 
erhalten.

> Wie ist das eigentlich mit der Kalibrierung bei diesen neuen
> Capacitive-Touch Panels, Riverdi sagte, dass man nur ein Display
> kalibrieren müsste und diese Daten dann für alle verwenden, wobei ich
> mich dann natürlich frage, warum die diese Daten dann nicht einfach
> irgendwo fest definieren.

Das funktioniert bestenfalls für die Displays aus einer 
Produktionscharge.
Die Kalibrierung macht man ja weil so ein Touchsreen einen Versatz zum 
Display haben kann und zudem noch gedreht sein kann.

Ich bin da auch gerne faul und speichere die Werte in der Software, 
teilweise geht das sogar über Familien hinweg, etwa EVE2-50G und 
EVE3-50G.
Und dann werden mal die Panels in der Produktion geändert und man hat 
zwei gleiche Modelle aus der selben Familie bei dem der Touch mit dem 
Daten von dem jeweils anderen Display gar nicht funktioniert.
Ist mir mit den EVE3-43G passiert, ich hatte schon länger eines und dann 
vier neue für ein Projekt gekauft.
Die vier neuen funktionieren mit einem Satz Daten, kein Problem, aber 
nicht mit den Daten vom alten Display.
Und da kann man dem Hersteller auch nichts vorwerfen, der kann ja nicht 
zusichern, dass die Dinger von jetzt bis immer exakt gleich hergestellt 
werden.

> Achso, noch eine generelle Frage: Werden eigentlich bei EVE diese
> Tag-Events schon beim Touch ausgelöst,

Ja, werden sie.

> oder kann man das auch so machen,
> dass die erst beim Wegnehmen des Fingers getriggert werden und das dann
> nur wenn man noch im Bereich des Buttons ist, also wie bei einem echten
> Touch-OS (iOS, Android)?

Also mein Android macht das auch nicht anders, wäre auch etwas nervig 
wenn ein Tastendruck erst beim loslassen erkannt werden würde.

> Ich habe vor Kurzem nämlich mit 4DSystems
> Displays und deren Entwicklungsumgebung gearbeitet und das nervige war,
> dass man da mit dem Finger einmal über das Display ziehen konnte und
> alle Buttons auf dem Weg wurden dann mal eben getriggert, was IMHO für
> ein halbwegs professionelles Gerät ein absolutes No-Go ist. Das komische
> Verhalten ließ sich da auch nicht ändern :-)

Mein aktuelles Projekt ist etwas mit Slider und Buttons überladen, also 
die Fläche ist knapp für die 4 großen Slider und 11 Buttons.
Und damit man keine Buttons auslöst wenn man mit dem Finger über den 
Rand eines Sliders geht habe ich da eine Verriegelung eingebaut.

Dazu lese ich jetzt REG_TOUCH_RAW_XY zusätzlich ein und reagiere auf den 
Tag 0x00 nur noch wenn REG_TOUCH_RAW_XY == 0xffffffff.
Damit kann ich mit dem Finger über das ganze Display streichen, 
ausgelöst wird dann nur das Event für das erste Objekt das ich treffe.

EVE ist da relativ stumpf, berührt man was steht das im REG_TOUCH_TAG 
Register.
Aber weil das so einfach ist, kann man das gewünschte Verhalten in 
Software kontrollieren, etwa das bei dem Druck auf einen Button nur 1 
Event generiert wird.

von Anguel S. (anguel)


Lesenswert?

Rudolph schrieb:

> Was ich im Moment mache ist eine kleine Platine mit einem CAN-FD fähigen
> Controller mit in das Gehäuse zu packen.

Habe ich schon auf deinem Github Account gesehen. Nur schade, dass du 
kein STM32 Fan bist ;-) Habe mir deine EVE-Lib mal kurz angeschaut, 
sieht schon alles sehr durchdacht und performant aus :-) Werde wohl 
gleich damit losstarten, wenn ich mal ein Display habe. Übrigens nutze 
ich den neuen STM32G4, sollte aber dank STM-HAL alles die gleiche Suppe 
sein wie die F-Serie. Muss nur schauen, dass ich das ganze ins 
STM32CubeIDE reinbekomme, dein STM32-Beispiel ist PlatformIO und auch 
noch Arduino, sollte aber kein Riesenproblem sein.

> Ja, genau, Details, der Touch-Controller taucht in den Bridgetek
> Unterlagen erstmal nicht auf.
> Eine Mail hatte ich auch geschickt, aber praktisch keine Antworten
> erhalten.

Wundert mich nicht bei Bridgetek. So ein Chaos sieht man selbst in 
dieser Branche selten. Ich hoffe mal, dass Riverdi die Touchscreens 
irgendwie zumindest angetestet hat, bevor die es in den Markt werfen. 
Die haben dazu gemeint:
"CTP is directly connected to EVE chip. You can read coordinates by EVE, 
but generally You use widgets and for example You make tag on button and 
read tag or check event. "

> Das funktioniert bestenfalls für die Displays aus einer
> Produktionscharge.
> Die Kalibrierung macht man ja weil so ein Touchsreen einen Versatz zum
> Display haben kann und zudem noch gedreht sein kann.

Aaaaha, muss ich mir merken. Riverdi meinte dazu:
"Calibration is only to fullfill EVE calibration matrix.
EVE4 - no need calibration, because CTP has the same resolution as LCD.
EVE3 has different CTP, so it needs to be calibrated.
It’s one command – touching 3 point.
You can make calibration once, read calibration matrix 
REG_TOUCH_TRANSFORM_A-F  and save it, then use for all devices. "

> Also mein Android macht das auch nicht anders, wäre auch etwas nervig
> wenn ein Tastendruck erst beim loslassen erkannt werden würde.

Interessant. Probier mal bei deinem Android das aus: Touchelement (z.B. 
Button) berühren aber nicht loslassen, dann Finger wegziehen ohne 
loszulassen, dann außerhalb des Elements loslassen. Bei mir wird das 
Element dann nicht aktiviert. Ist bei iOS, Windows, etc. genau dasselbe. 
Kann man auch mit der Maus testen.
Übrigens hat jemand etwas hier von einer Sticky-Tag-Implementierung 
geschrieben:
http://www.brtcommunity.com/index.php?topic=147.10;wap2
Bin aber nicht ganz sicher, ob er sowas meint.

> Mein aktuelles Projekt ist etwas mit Slider und Buttons überladen, also
> die Fläche ist knapp für die 4 großen Slider und 11 Buttons.
> Und damit man keine Buttons auslöst wenn man mit dem Finger über den
> Rand eines Sliders geht habe ich da eine Verriegelung eingebaut.
>
> Dazu lese ich jetzt REG_TOUCH_RAW_XY zusätzlich ein und reagiere auf den
> Tag 0x00 nur noch wenn REG_TOUCH_RAW_XY == 0xffffffff.
> Damit kann ich mit dem Finger über das ganze Display streichen,
> ausgelöst wird dann nur das Event für das erste Objekt das ich treffe.

Genau sowas meine ich! Aber das ist wahrscheinlich (noch) nicht in 
deiner EVE-Lib drin, oder?

> Aber weil das so einfach ist, kann man das gewünschte Verhalten in
> Software kontrollieren, etwa das bei dem Druck auf einen Button nur 1
> Event generiert wird.

Das ist wohl einer der Vorteile der Lower-Level-Programmierung der 
Dinger.

Grüße
Anguel

von Rudolph (Gast)


Lesenswert?

Anguel S. schrieb:
>> Was ich im Moment mache ist eine kleine Platine mit einem CAN-FD fähigen
>> Controller mit in das Gehäuse zu packen.
>
> Habe ich schon auf deinem Github Account gesehen. Nur schade, dass du
> kein STM32 Fan bist ;-)

Och, kann man so nicht sagen, ich finde die eigentlich ganz nett soweit.
Zumindest die aktuelleren Modelle.
Nur kann ich mit STM32 einfach beruflich nichts anfangen, da es die 
nicht in Automotive qualifiziert gibt.

Ich habe auch was vor mit dem STM32H7Bxxx, das kann ich momentan nur 
nicht mal anfangen, weil ich die Dinger einfach nicht in die Finger 
bekomme.
ST hat scheinbar gerade etwas Probleme den Markt zu bedienen.

> Habe mir deine EVE-Lib mal kurz angeschaut,
> sieht schon alles sehr durchdacht und performant aus :-) Werde wohl
> gleich damit losstarten, wenn ich mal ein Display habe. Übrigens nutze
> ich den neuen STM32G4, sollte aber dank STM-HAL alles die gleiche Suppe
> sein wie die F-Serie. Muss nur schauen, dass ich das ganze ins
> STM32CubeIDE reinbekomme, dein STM32-Beispiel ist PlatformIO und auch
> noch Arduino, sollte aber kein Riesenproblem sein.

Ich habe auch ein PlatformIO Projekt das querbeet für mehrere STM32 
compiliert, so ohne Arduino.
Nur bin ich da noch nicht weiter gekommen das wirklich mit einer 
lauffähigen main.c zu versehen.

>> Ja, genau, Details, der Touch-Controller taucht in den Bridgetek
>> Unterlagen erstmal nicht auf.
>> Eine Mail hatte ich auch geschickt, aber praktisch keine Antworten
>> erhalten.
>
> Wundert mich nicht bei Bridgetek.

Nee, Riverdi habe ich gefragt, die haben den CTP schliesslich
mit dem Display verheiratet.

> "CTP is directly connected to EVE chip. You can read coordinates by EVE,
> but generally You use widgets and for example You make tag on button and
> read tag or check event. "

Super, die Frage ist doch ob man was dafür machen muss damit der CTP und 
EVE sich überhaupt verstehen, und wenn ja, was denn.

Matrix Orbital nutzt ja zum Beispiel gerne die GT911, dafür muss man die 
FT813 patchen und die BT815 konfigurieren.

>> Die Kalibrierung macht man ja weil so ein Touchsreen einen Versatz zum
>> Display haben kann und zudem noch gedreht sein kann.
>
> Aaaaha, muss ich mir merken. Riverdi meinte dazu:
> "Calibration is only to fullfill EVE calibration matrix.
> EVE4 - no need calibration, because CTP has the same resolution as LCD.
> EVE3 has different CTP, so it needs to be calibrated.
> It’s one command – touching 3 point.
> You can make calibration once, read calibration matrix
> REG_TOUCH_TRANSFORM_A-F  and save it, then use for all devices. "

Also manchmal frage ich mich ob sich da jemand mit beschäftigt der sich 
da wirklich auskennt.
Es könnte sein das die Touch-Matrix anders in das Display integriert 
ist, so das es keinen Versatz oder Drehung geben kann.
Das wäre aber nicht das gleiche wie das der Touch die gleiche Auflösung 
wie das Panel hat.

Auf den Produkt-Seiten bei Riverdi findet sich aktuell auch zum Beispiel 
sowas:
2x Pixel Mode
Another feature implemented to EVE4 graphics controller for the first 
time is ‘2x pixel mode’. In this mode, picture is being refreshed 
simultaneously on two independent halves of the display which shortens 
the process by half and makes rapid changes of the image displayed super 
smooth.

Davon liest man im Programming Manual nur nichts, ich wüsste auch gar 
nicht wie sowas überhaupt möglich sein sollte, so mit einem Satz 
Leitungen zum Panel und einem Controller auf dem Panel.

REG_PCLK_2X Definition
Bit 0: graphics engine outputs 1 or 2 pixels per PCLK.
0 means 1 pixel per clock,
1 means 2 pixel per clock.
Core scan out 2 pixel data per system clock

>> Dazu lese ich jetzt REG_TOUCH_RAW_XY zusätzlich ein und reagiere auf den
>> Tag 0x00 nur noch wenn REG_TOUCH_RAW_XY == 0xffffffff.
>> Damit kann ich mit dem Finger über das ganze Display streichen,
>> ausgelöst wird dann nur das Event für das erste Objekt das ich treffe.
>
> Genau sowas meine ich! Aber das ist wahrscheinlich (noch) nicht in
> deiner EVE-Lib drin, oder?

Das ist Anwendungs-Ebene, damit hat die Lib selber erstmal nichts zu 
tun.
Und von daher funktioniert das schon.

In der tft.c aus meinem Beispiel habe ich in der TFT_touch() ja 
zumindest schon einen einfachen toggle-lock für den Button mit drin.
Der wird mit dem Button gesetzt und mit dem Tag 0 wieder gelöscht.
Erweitert habe ich das jetzt nur so das REG_TOUCH_RAW_XY == 0xffffffff 
damit das toggle_lock = 0; ausgeführt wird.
So reicht dann ein drücken-halten-wegwischen nicht mehr, man muss auch 
los lassen, bevor der Button neu betätigt werden kann.
Hmm ja, vielleicht erweitere ich einfach mal das Beispiel entsprechend.

von Anguel S. (anguel)


Lesenswert?

Rudolph schrieb:

> Nur kann ich mit STM32 einfach beruflich nichts anfangen, da es die
> nicht in Automotive qualifiziert gibt.

Ach daher kommt deine Affinität zu CAN-FD :-) Ich mache zwar nix mit 
Automotive aber CAN-FD ist schon eine tolle Sache. Verbinde jetzt auch 
einige Boards damit untereinander.

> Ich habe auch was vor mit dem STM32H7Bxxx, das kann ich momentan nur
> nicht mal anfangen, weil ich die Dinger einfach nicht in die Finger
> bekomme.
> ST hat scheinbar gerade etwas Probleme den Markt zu bedienen.

Die Nucleo-Boards für STM32G4 gab es letztens noch, bei den größeren MCU 
sieht es wahrscheinl. anders aus. Ansonsten habe ich mich jetzt erstmal 
auf STM32 HAL festgelegt, in den neuen Versionen scheint es in 
Verbindung mit CubeMX gar nicht so schlecht zu laufen. Ok, vielleicht 
nicht so performant, aber dafür ist es einfach neue Sachen zu 
implementieren, auch CAN-FD.

> Super, die Frage ist doch ob man was dafür machen muss damit der CTP und
> EVE sich überhaupt verstehen, und wenn ja, was denn.

Das war eigentlich auch meine Frage, aber da diese Antwort kam und ich 
mich mit dem Thema noch nicht auskenne, bin ich davon ausgegangen, dass 
es auf Anhieb laufen sollte.

> Also manchmal frage ich mich ob sich da jemand mit beschäftigt der sich
> da wirklich auskennt.

Puh, bei einer polnischen Firma hatte ich das zumindest gehofft. Das 
wäre doch wieder ein Ding, wenn Riverdi so komplexe Hardware entwirft 
und nicht mal klar ist, ob alles zusammen funktioniert...

> In der tft.c aus meinem Beispiel habe ich in der TFT_touch() ja
> zumindest schon einen einfachen toggle-lock für den Button mit drin.
> Der wird mit dem Button gesetzt und mit dem Tag 0 wieder gelöscht.
> Erweitert habe ich das jetzt nur so das REG_TOUCH_RAW_XY == 0xffffffff
> damit das toggle_lock = 0; ausgeführt wird.
> So reicht dann ein drücken-halten-wegwischen nicht mehr, man muss auch
> los lassen, bevor der Button neu betätigt werden kann.
> Hmm ja, vielleicht erweitere ich einfach mal das Beispiel entsprechend.

Super, ich schaue es mir auf jeden Fall genauer an.

Da ich kein Display habe, schaufele ich momentan Visual Studio 2019 
Community auf die SSD, damit ich mal den Emulator antesten kann. So 
wirklich klare Doku dazu habe ich irgendwie auch nicht gefunden. Mal 
sehen, ob es nach Gefühl klappt ;-)

von Rudolph (Gast)


Lesenswert?

Anguel S. schrieb:
> Die Nucleo-Boards für STM32G4 gab es letztens noch,

Ich möchte eine Platine designen, das bringt nur nichts wenn es die 
Teile nicht gibt.
Ein Nucleo gibt es für den Stein auch nicht.

>> Also manchmal frage ich mich ob sich da jemand mit beschäftigt der sich
>> da wirklich auskennt.
>
> Puh, bei einer polnischen Firma hatte ich das zumindest gehofft. Das
> wäre doch wieder ein Ding, wenn Riverdi so komplexe Hardware entwirft
> und nicht mal klar ist, ob alles zusammen funktioniert...

Oh, das habe ich nicht gemeint, ich meinte im Support und Marketing.
Ich glaube denen schon, dass die Module laufen.

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Ich habe gerade mal in meine platformio.ini ein paar Zeilen zusätzlich 
geworfen:

[env:STM32G474]
board = nucleo_g474re
build_flags = -D STM32G4

Und beim bauen hat sich PlatformIO einfach das nächste Paket gezogen. 
:-)

Environment    Status    Duration
-------------  --------  ------------
STM32L073      SUCCESS   00:00:07.293
STM32F030      SUCCESS   00:00:06.566
STM32F103      SUCCESS   00:00:06.966
STM32F303      SUCCESS   00:00:08.502
STM32F446      SUCCESS   00:00:11.042
STM32G474      SUCCESS   00:00:10.078

In der 
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target.h
steckt ein Block für STM32 und STM32cube.

Das compiliert zwar so, also im Grunde genommen, das funktioniert dann 
nur noch nicht, weil in der main.c und in der EVE_target.c bisher nur 
ein bischen was spezifisch für den STM32F446 drin ist.

Das taugt noch lange nicht als Beispiel, aber ich nutze STM32 dann ja 
eben auch bisher nicht wirklich.

Ich würde übrigens gerne eine Platine mit einem STM32H7B0RBT6 bauen.
Es gibt da draußen nur keine.

von Anguel S. (anguel)


Lesenswert?

Rudolph R. schrieb:

> STM32G474      SUCCESS   00:00:10.078
Cool! Sowas nenne ich Cross-Platform, nicht das was Bridgetek versucht 
:-)
Woher wusstest du, dass ich den G474 habe? ;-)

> In der
> https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target.h
> steckt ein Block für STM32 und STM32cube.
Du meinst wahrscheinlich eher die EVE_target.c, oder?
Normalerweise konfiguriere ich alles schön im CubeMX und der erzeugt 
dann die Konfig-Dateien die man als nette Option separat von der main() 
ausgeben kann. In der main() hat man dann nur noch ein MX_SPI2_Init() 
oder so ähnlich, das macht es noch leichter an andere STM32 anpassbar, 
wegen Pins und so. Nur so als Idee.

> Das taugt noch lange nicht als Beispiel, aber ich nutze STM32 dann ja
> eben auch bisher nicht wirklich.
Mir wurde es ganz gut klar, das einzig verwirrende war vielleicht, dass 
es ein Arduino-Projekt ist.

> Ich würde übrigens gerne eine Platine mit einem STM32H7B0RBT6 bauen.
> Es gibt da draußen nur keine.
Hmmm, ich hab nur ganz kurz geschaut, aber ich hatte damals das Gefühl, 
dass die keine Crypto-Chips in Nucleo-Boards u.ä. verbauen, evtl. wegen 
Gesetz und so, kann mich aber auch stark täuschen.

Habe jetzt übrigens den EVE-Emulator angeschmissen. Ist ganz nett, 
spielt sogar die Sounds ab. Der lässt sich bestimmt an deine Lib 
anpassen, eigentlich müsstest du nur den MCU-spezifischen Teil 
abgreifen, da ich aber zugegebenermaßen nicht soo erfahren bin, war es 
mir beim durchschauen doch etwas zu unübersichtlich, was da genau auf 
unterster Ebene passiert.
Ansonsten sind das die Platform-Demos, die auch für den Emulator 
konfiguriert sind:
https://brtchip.com/wp-content/uploads/2021/02/EveApps.v1.2-rc3.zip
und das ist der zugehörige Platform-Guide, wo alles beschrieben ist:
http://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_391-EVE-Platform-Guide.pdf

von Rudolph R. (rudolph)


Lesenswert?

Anguel S. schrieb:
>> STM32G474      SUCCESS   00:00:10.078
> Cool! Sowas nenne ich Cross-Platform, nicht das was Bridgetek versucht
> :-)

Naja, das ist jetzt weniger mein Verdienst, als der von ST mit ihrer HAL 
Library und PlatformIO.

> Woher wusstest du, dass ich den G474 habe? ;-)

Ich habe einfach nur in PlatformIO nach einem unterstütztem Nucleo Board 
gesucht.
Man kann zwar auch Boards in PlatformIO hinzufügen, aber man muss sich 
das Leben für sowas ja nicht unnötig schwer machen. :-)

>> In der
>> https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target.h
>> steckt ein Block für STM32 und STM32cube.
> Du meinst wahrscheinlich eher die EVE_target.c, oder?

Jain, die Kernfunktionen sind als static Inline in der EVE_target.h zu 
finden, zusätzliche Funktionen wie für DMA habe ich in der EVE_target.c.

> Normalerweise konfiguriere ich alles schön im CubeMX und der erzeugt
> dann die Konfig-Dateien die man als nette Option separat von der main()
> ausgeben kann. In der main() hat man dann nur noch ein MX_SPI2_Init()
> oder so ähnlich, das macht es noch leichter an andere STM32 anpassbar,
> wegen Pins und so. Nur so als Idee.

Wenn ich primär mit STM32 arbeiten würde, würde ich das auch so machen, 
oder so ähnlich. :-)

>> Das taugt noch lange nicht als Beispiel, aber ich nutze STM32 dann ja
>> eben auch bisher nicht wirklich.
> Mir wurde es ganz gut klar, das einzig verwirrende war vielleicht, dass
> es ein Arduino-Projekt ist.

Arduino ist eben perfekt für sowas,

Das Beispiel baut mal eben Querbeet für diversen Plattformen:
uno                        SUCCESS   00:00:07.905
avr_pro                    SUCCESS   00:00:03.838
nano328                    SUCCESS   00:00:03.425
adafruit_metro_m4          SUCCESS   00:00:20.071
samd21_m0-mini             SUCCESS   00:00:07.731
ESP32                      SUCCESS   00:00:14.852
ESP8266_d1_mini            SUCCESS   00:00:11.784
nucleo_f446re              SUCCESS   00:00:21.354
teensys41                  SUCCESS   00:00:10.126
adafruit_feather_nrf52840  SUCCESS   00:00:15.965

Für den Metro-M4, den ESP32, das Nucleo 446 und den Teensy
ist dann aber noch jeweils spezieller Code in der EVE_target.c der SPI 
per DMA erlaubt.

Ich bin jetzt nicht wirklich ein Fan von Arduino im allgemeinen, aber 
für das Beispiel nimmt mir das erstmal alles ab was 
Controller-spezifisch ist.
Ich muss mich nicht mit so lästigen Dingen herum schlagen wie man den 
Takt konfiguriert, Timer und so, aber man kann an den Arduino Klassen 
vorbei gehen.
Mein AVR Code geht einfach mal direkt auf die Hardware für den SPI, das 
Nucleo 446 nutzt HAL, ESP32 den ESP-IDF Treiber.

Um mit dem STM32 Beispiel das gleiche zu erreichen bräuchte ich für dann 
für jeden Controller wieder speziellen Code.

>> Ich würde übrigens gerne eine Platine mit einem STM32H7B0RBT6 bauen.
>> Es gibt da draußen nur keine.
> Hmmm, ich hab nur ganz kurz geschaut, aber ich hatte damals das Gefühl,
> dass die keine Crypto-Chips in Nucleo-Boards u.ä. verbauen, evtl. wegen
> Gesetz und so, kann mich aber auch stark täuschen.

Also der ATSAME51 hat auch ein AES Modul, den bestelle ich einfach so 
bei DigiKey.
ST hat ja auch dickere H7 im Sortiment für die es auch kaufbare 
Nucleo-144 Boards gibt.
Der STM32H7B0RBT6 steht bei ST auf "active", dennoch gibt es nur einen 
Distributor bei dem ich ein Paket mit 960 Stück kaufen könnte.
Ich muss noch mal ein paar Vergleichen, eventuell hat der noch einen 
großen Bruder, leider ist das bei ST auf der Webseite etwas 
unübersichtlich und zum Teil auch falsch.

> Habe jetzt übrigens den EVE-Emulator angeschmissen.

Hmm, okay. :-)
Wenn ich mal ganz kurz was ausprobieren möchte dann werfe ich den EVE 
Screen Editor an, mit dem kann man auch sehen was der aus den Befehlen 
so macht.
Ansonsten liegen hier genug Displays zum Ausprobieren. :-)

von Anguel S. (anguel)


Lesenswert?

Rudolph R. schrieb:.
> Ich muss noch mal ein paar Vergleichen, eventuell hat der noch einen
> großen Bruder, leider ist das bei ST auf der Webseite etwas
> unübersichtlich und zum Teil auch falsch.

Im Datenblatt ist ein Vergleich mit ähnlichen Modellen:
https://www.st.com/resource/en/datasheet/stm32h7b0rb.pdf

Sonst haben die spezielle Software zum MCU Vergleich:
https://www.st.com/en/development-tools/st-mcu-finder.html

Oder du lädst dir die STM32CubeIDE, dann kannst du den im CubeMX sogar 
per GUI fertigkonfigurieren und schauen ob du dann alle nötigen Module, 
Pins, Clocks so nutzen kannst ;-)

von Rudolph R. (rudolph)


Lesenswert?

Stimmt, an das STM32CubeMX hatte ich nicht gedacht.

Es gibt noch drei, zumindest auf dem Papier.
Die stehen alle auf "Active" und "Product is in mass production".
Nur kann nicht mal ST einen Distributor dafür nennen.
Der STM32H7B0RBT6 ist dabei der kleinste mit "nur" 128k FLASH.

Tja nun, dann eben nicht, vielleicht später mal.

von Daniel S. (snipod)


Lesenswert?

Hi Rudolph,
ich habe noch mal eine Frage:
Ich teste gerade mein Custom PCB mit meinem Custom Display.
Ich habe nen BT815Q drauf und das CTP arbeitet mit einem GT911.
Touch funktioniert soweit gut, nur wenn ich den extended Mode für 
Multitouch aktiviere, geht touch nicht mehr.
Interessanterweise freezed der Bildschirm dann im kalibrieren sogar, 
also im Kalibrierbildschirm "flashen" die Punkte nicht mehr.

Deaktiviere ich den Extended Mode wieder, geht alles...

Hast Du / jemand eine Idee?

Viele Grüße

von Rudolph (Gast)


Lesenswert?

Ich kann gerade nicht nachsehen oder das zitieren, aber ich meine 
Kalibrieren geht nicht im Extended Mode.
Also erst Kalibrieren, bzw. die kalibrier-Werte schreiben, dann 
umschalten.

von Rudolph R. (rudolph)


Lesenswert?

Kapitel 3.4.4 Capacitive Touch Engine, Seite 40:
"Note: The calibration process of the touch screen should only be 
performed in compatibility mode."

von Daniel S. (snipod)


Lesenswert?

Perfekt, hat so geklappt... Dummer Fehler :)

Vielen Dank

von Bernd (Gast)


Lesenswert?

Hallo Rudi,
ich bin's mal nach langer Zeit wieder - Bernd. Do You remember..?
Ganz banale Frage zum FT813: Bei den C-Tatch-Displays gibt es 
gravierende Unterschiede bei der Berührungsempfindlichkeit.
Während man beim Resistive mit REG_TOUCH_RZTHRESH die Empfindlichkeit 
einstellen kann, habe ich einfach nichts dergleichen zum C-Touch 
("REG_TOUCH_CZTHRESH" z.B.) finden können.
Ich arbeite im Kompatibilitätsmodus (als nur 1 Touch)...
Gibt es irgendwie die Möglichkeit, dass zu beeinflussen???

von Bernd (Gast)


Lesenswert?

Noch was dazu:
Damit Du mich nicht falsch verstehst: Bei manchen Displays muss man 
regelrecht "raufdrücken", damit es reagiert (das ist weniger das 
Problem), bei anderen berührt man hauchzart das Glas und es reagiert. 
DAS ist das Problem, weil, wenn man dann stärker Drückt, ist der Touch 
wieder weg. Heißt: Eine Taste, die ich betätige, soll ja nur EINMAL als 
betätigt eingestuft werden, so lange bis ich sie wieder loslasse. Aber 
trotz halten, wird dann schon je nach dem, wie stark man hält, ein 2. 
Touch gewertet (ungünstig z.B. bei einer Code-Tastatur).

Ich habe nun schon das "Warten auf Loslassen" (Register 
REG_CTOUCH_TOUCH_XY muss statt 1x nun 100 mal in 1ms Abstand 
hintereinander je $80 sein) entsprechend verändert. Ist zwar besser - 
klar, aber hält man doch noch etwas länger, statt nur kurz zu tippen, 
kommt es trotzdem noch immer mal zur 2. Reaktion. Ist doch blöd!!!
Bernd

von Rudolph R. (rudolph)


Lesenswert?

Hmmm, interessant.
Mit Cap-Touch hatte ich bisher überhaupt keine Probleme, alle Displays 
die ich bisher benutzt habe reagieren auf eine leichte Berührung und das 
die bei stärker drücken den Touch verlieren ist mir weder bisher 
aufgefalen, oder den Kollegen, noch kann ich das gerade nachvollziehen.

Die EVE3 die ich gerade verwende benutzen ja GT911, kein Problem.
Gegenüber resistive touch lief das bisher einfach immer stressfrei, 
bestenfalls musste ich mal die Kalibrierung verfeinern.

Ich habe mal nachgesehen und es gibt wohl wirklich keine Register dafür 
die Empfindlichkeit einzustellen oder was anders zu konfigurieren.
Unter den ganzen undokumentierten Registern für die mal ein Name 
durchgerutscht ist habe ich auch gerade nichts gefunden.

Datenblätter zu Touch Controllern zu finden ist allerdings eine 
Herausforderung.
Was man so findet ist uralt, unvollständig und geleaked.

Wenn da was geht müsste man vermutlich den Touch-Controller Code patchen 
und den Touch-Controller noch mal resetten.

Interessant in der Richtung ist noch der "Custom Touch Firmware 
compiler" im EVE Asset Builder für die BT817/BT818.
Bisher habe ich das allerdings noch nicht zum Laufen gebracht.
Aber dann gibt es auch sowieso noch einen erheblichen Mangel an real 
existierenden BT817 Modulen.

von Bernd Ickert (Gast)


Lesenswert?

4 Wochen habe ich nahezu täglich an einem Projekt mit dem C-Touch 
gesessen und dabei ein "frei fliegendes" Display mit Cover-Lens benutzt. 
NUN habe ich das fertige Gerät mit einem in einem Kunststoff-Gehäuse 
eingebauten Display (gleiche Bauart, aber mit Glas so groß wie Display, 
nicht überstehend) testen wollen. Außerdem befindet sich über dem 
Display-Ausschnitt ein 0,5mm starker Metall-Blendrahmen, der quasi die 
Display-Oberfläche am technischen Rand berührt. Berührungen des 
Metallrahmens lösen bereits einen Touch aus!
Messungen zeigen, dass das Metallgehäuse des Display nicht auf GND 
liegt! Ein aufgeklebtes Stück Massekabel (mit Tape) verbessert die 
Situation nicht wirklich und hält auch nicht so richtig bzw. gibt keinen 
stabilen Kontakt. Auflöten kann man ja wohl kaum ein Kabel an das 
Display-Gehäuse !!!! Auch Masse auf dem Blendrahmen bringt nicht so viel 
Besserung.

Ich meinte mal IRGENDWANN und IRGENDWO gelesen gehabt zu haben, dass die 
Empfindlichkeit an die Glasstärke angepasst werden kann (z.B. 2mm Glas 
noch drüber...). Kann aber auch im Zusammenhang mit einem ganz anderen 
Berührungs-Taster gewesen sein...!!!???
Na Danke, dass Du mir bestätigen konntest, dass es beim FT813 den 
Parameter eben nicht gibt!

von Rudolph (Gast)


Lesenswert?

Also sowas ist schon böse, Metall sollte man wohl generell um das 
Display herum vermeiden.
Aber was weiß ich schon, ich habe keine Erfahrung mit richtigen 
Produkten, ich verwende die fertigen Module mit dem Glas davor vom 
Hersteller und meine Gehäuse sind aus dem 3D-Drucker.
Meine Stückzahlen sind sehr überschaubar.

Auf jeden Fall habe ich gestern in der BRT Community die Frage 
abgeworfen ob und wie man den Touch-Controller konfigurieren kann.

In Deinem Fall ist es vielleicht besser den Touch-Controller an den 
Host-Controller zu hängen, so zum selber konfigurieren.
Man kann dem FT81x ja auch Touch-Events per SPI schicken.
Gemacht habe ich das allerdings noch nicht.

von Rudolph R. (rudolph)


Lesenswert?

Anyone around with a Teensy 4.1?
I would like to know if the Teensy 4.1 target that I added a little 
while ago actually works, especially the DMA support for it.

There already is an entry for it in the platformio.ini of the Arduino 
example project:
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO

von Rudolph R. (rudolph)


Lesenswert?

I am in the process of adding the profiles for the Riverdi EVE4 display 
to EVE_config.h.

But the data is not that reliable so far with all the datasheets still 
in beta and although I ordered one it won't be here anytime soon.

So, does anyone already have one of these already?

von Rudolph R. (rudolph)


Lesenswert?

Okay, I added profiles for all the EVE4 modules from Riverdi, from 3.5" 
to 10.1".
If you can test it, please do so and give me a note if anything fails.

von Johannes (Gast)


Lesenswert?

Hat schonmal jemand vesucht auf dem statischen Background zwei 
Farbverläufe (CMD_Gradient) untereinander/nebeneinander darzustellen? 
Laut FTDI-Datenblatt soll man die Scissor-Funktion verwenden können. 
Wenn ich per Scissor die obere Hälfte des Displays mit einem Farbverlauf 
und die untere Hälfte des Displays ebenfalls mit Scissor mit einem 
zweiten Farbverlauf belege, kommt es zu dem Effekt, dass manche Widgets 
auf dem zuerst gezeichneten Farbverlauf verschwinden. Texte, Slider und 
Progress werden auf beiden Farbverläufen angezeigt, Buttons aber zum 
Beispiel nicht mehr, wenn sie auf dem zuerst gezeichneten Bereich 
liegen.

Gibt es dafür Workarounds?

von Rudolph R. (rudolph)


Lesenswert?

Es ist nicht so als ob ich sowas schon mal gemacht hätte. :-)
Aber ich habe gerade mal ein wenig mit dem EVE Screen Editor gespielt 
und bin darauf gekommen, dass ein "RESTORE_CONTEXT" hilft:

Kopier das  mal in den ESE:
CLEAR(1, 1, 1)
SCISSOR_XY(0, 0)
SCISSOR_SIZE(800, 240)
CMD_GRADIENT(0, 0, 0x00AAFF, 800, 200, 0xFFFF00)
SCISSOR_XY(0, 240)
SCISSOR_SIZE(800, 240)
CMD_GRADIENT(0, 240, 0xcc00FF, 0, 480, 0x00FF00)
RESTORE_CONTEXT
CMD_BUTTON(139, 132, 120, 36, 27, 0, "Button")
CMD_BUTTON(115, 287, 120, 36, 27, 0, "Button")
CMD_SCROLLBAR(325, 153, 16, 160, 0, 120, 60, 480)
CMD_TOGGLE(435, 188, 40, 27, 0, 0, "on\xFFoff")

Man muss ja eigentlich nur die "Scissors" wieder los werden.

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

I finally got around trying out the target for the RP2040 on the 
Raspberry Pi Pico - no DMA yet but seems to be doing just fine. :-)

This is done as a baremetal target in PlatformIO using 
https://github.com/Wiz-IO/framework-wizio-pico

von Rudolph R. (rudolph)


Lesenswert?

And the RP2040 target works with DMA now. :-)
This brings down "Time1" to 15µs.

von c-hater (Gast)


Lesenswert?

Rudolph R. schrieb:

> And the RP2040 target works with DMA now. :-)
> This brings down "Time1" to 15µs.

Sehr schön. Ich spiele privat auch gerade mit dem Pico rum, allerdings 
nicht in Kombination mit den BT81x-Displays, sondern mit einem simplen 
parallelen RGB-LCD (960x160), sprich: ich baue an einem Framebuffer mit 
12bit-Pixeln. Aber das nur nebenbei.

Meine Frage dreht sich schon um die BT81x, konkret um ein Riverdi 
800x480 mit BT816, das ich zum Testen hier habe und an einem 
AVR128DA-Host verwende. Da bin ich an ganz anderer Stelle (also nicht 
bei der Hostkommunikation, auf du dich offensichtlich fokussierst) auf 
ein Bandbreitenproblem gestoßen.

Also, ich habe eine funktionierende Testanwendung, in der dein fast 
unveränderter EVE-Code verwendet wird (nur Anpassung an den AVR128DA und 
Unterstützung für AVR-Host-Flash >64kB) und auch noch kleine Teile aus 
deiner Demo, eigentlich nur noch das Performance-Display.
Meine Testanwendung (Slideshow mit animiertem Logo und teiltransparentem 
Framewindow) ist sehr einfach gestrickt, im Prinzip benutzt sie neben 
den kleinen Resten aus deiner Demo ausschließlich vier Bilder, die sich 
im Flash des Riverdi-Boards befinden. Diese Bilder werden direkt aus dem 
Flash gerendert. Das funktioniert auch wunderbar, so lange die Qualität 
der Bilder hinreichend gering ist oder halt nicht alle davon 
gleichzeitig benutzt werden. Ansonsten fängt's an zu "Ruckeln", je nach 
benötigter Bandbreite mehr oder weniger.

Die Ruckelgrenze für die Summe der komprimierten Datenströme der Bilder 
liegt irgendwo knapp unter 180Mbit/s, so weit habe ich das mit meiner 
Testanwendung schon "ausgeklingelt".
Das Problem ist: Dieser Wert liegt ganz erheblich unter dem, was ich 
erwartet hätte (die Bandbreite der Flashanbindung des BT816 sollte bei 
deutlich über 280Mbit/s liegen, bei QSPI mit 72MHz). Eine andere 
Beschränkung ist nirgendwo dokumentiert.

Hast du irgendwelche Hinweise? Also insbesondere auf irgendwas von mir 
in der Doku übersehenes?

von Rudolph R. (rudolph)


Lesenswert?

Mit den Riverdi Displays habe ich das noch nicht probiert,
hatte ich mir eigentlich noch vorgenommen.

Aber ja, die Bandbreite ist begrenzt und der Takt mit dem das QSPI flash 
betrieben wird liegt wohl beim halben Systemtakt, also 36MHz.
Dazu kommt aber noch, dass die tatsächlich erreichbare Bandbreite 
scheinbar vom verwendeten Speicher und vom Layout der Platine abhängig 
sind.
Ich habe Platinen von unterschiedlichen Herstellern die sich bei etwas 
höherer Ausnutzung des externen Speichers unterschiedlich verhalten.
Mit dem Speed-Test im ProgFlash Tool kommen ich über diverse Chips mit 
dem EVE3-43G von Matrix Orbital nur so auf 10MB/s.
Ich weiß jetzt allerdings auch nicht genau was der Test eigentlich 
macht.

Wobei diese Platine im Vergleich zu zwei anderen von anderen Herstellern 
dabei noch am besten funktioniert.

Ein etwas fieserer Test ist ein Bild von 256x256 aus dem Flash 
anzuzeigen und dabei zu drehen.

Ich bin schon echt gespannt wie das mit einem EVE4 Display von Riverdi 
bei 1280x600 laufen wird.
Nach den bisherigen Erfahrungen mit dem BT817 braucht man das SRAM 
durchaus noch und solle das Flash eher dezent einsetzen.
Ein fetter UTF-8 Font im Flash ist schon toll, ab 40 Punkten oder so 
sollte man dann aber besser den Fontcache einschalten wenn man viel Text 
hat.

c-hater schrieb:
> nur Anpassung an den AVR128DA

Also grundsätzlich interessiert mich das ja schon, die letzten Monate 
habe ich ja vor allem bei den unterstützten Targets aufgerüstet.

Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar, 
der ist praktisch ein ATSAMC20 mit halbem Takt, halbem Speicher und AVR 
Kern.
Das Argument das wäre ein AVR zieht irgenwie auch nicht wenn die 
Software ganz anders aussieht und man sich trotzdem neu einarbeiten 
muss.

Nun ja, den RP2040 habe ich nach erfolgreicher "Portierung" auch erstmal 
wieder zur Seite gelegt, mit dem kann ich auch nicht wirklich was 
anfangen.
Und nach einem tieferen Blick in das SDK bin ich eher enttäuscht, dabei 
habe ich nur an der Oberfläche gekratzt.

c-hater schrieb:
> Unterstützung für AVR-Host-Flash >64kB)

Also grundsätzlich ist das drin:
1
static inline uint8_t fetch_flash_byte(const uint8_t *data)
2
{
3
#if defined (__AVR_HAVE_ELPM__)  /* we have an AVR with more than 64kB FLASH memory */
4
return(pgm_read_byte_far(data));
5
#else
6
return(pgm_read_byte_near(data));
7
#endif
8
}

Zum Beispiel mit dem AT90CAN128 habe ich das auch schon benutzt.
Und das fetch_flash_byte() müsste auch das einzige sein das überhaupt 
angepasst werden müsste wenn der AVR128DA das anders macht als die alten 
AVRs.

von Johannes (Gast)


Lesenswert?

@Rudolph: Du hattest am Anfang des Thread mal geschrieben, dir wäre noch 
keine wirkliche Lösung für das Umlaut-Probleme der Werks-Fonts 
eingefallen. Hast du zwischenzeitlich mal irgendeinen Workaround 
gesehen, oder gibt es eine vernünftige Lösung? Die User-Fonts sind je 
ebenfalls auf 128 Zeichen begrenzt.

Ich arbeit mit FT812 an NHD 7" 480x800 mit SAMC21.

Gruß,
Johannes

von Rudolph R. (rudolph)


Lesenswert?

Nein, zu Fonts mit den FT81x habe ich keine richtige Lösung.
Konvertieren in Bilder geht und macht auch schon mal die Display-Liste 
schlanker, ist aber aufwendig und unflexibel.

Zum Glück können wir aber seitdem es die BT81x gibt UTF-8 Fonts 
verwenden.
Das ist jetzt auch etwas aufwendig die Fonts zu konvertieren, vor allem 
muss man schon mal mit der Größe spielen.
Aber wenn man da durch ist macht das Spaß, mein Editor steht auf UTF-8 
und somit kann ich das einfach so eintippen.

Also von daher würde ich empfehlen auf einen BT815 zu wechseln.
Ja, und ich würde ganz stark empfehlen von Resistiv-Touch auf 
Kapazitiv-Touch zu wechseln.
Ich weiß aber auch, Newhaven hat keine BT81x.
Von dem was aktuell tatsächlich direkt zu bekommen wäre würde ich ein 
EVE3-70G von Matrix Orbital kaufen.

Was ich hoffe irgendwann mal in die Finger bekommen zu können wäre ein 
EVE4x-101G-IPS.
Oder von Riverdi ein RVT70HSBNWC00-B oder ein RVT101HVBNWC00-B.
In USA würde ich nach Crystalfontz schauen.
Die neuen von Riverdi sind alle in IPS, bei den "-B" Modellen bekommt 
man auch noch Optical Bonding oben drauf.
Nur hapert das da etwas an der Verfügbarkeit.

TME listet zwar zum Beispiel die neuen Riverdi Displays schon, die haben 
nach der Webseite aber noch nicht mal bestellt und die Lieferzeit wird 
mit 16 Wochen angegeben - ich hoffe doch das ändert sich vor dem Sommer 
noch.

von Spyy (Gast)


Lesenswert?

Hi Rudolph,

ich habe in Deinem code gesehen das Du in EVE_Init schreibst:
if EVE_GEN > 2
  EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
#endif

Wieso 46Hex? Ich bekomme dann hier ca 34 Mhz statt 72 und im Manual 
steht man soll 24dez für 72Mhz reinschreiben.

Grüße und Danke

Torsten

von Rudolph R. (rudolph)


Lesenswert?

Boah, schock doch nicht so. :-)

EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */

Das ist schon richtig, nur nachdem ich mich gerade durch die ganze 
Dokumentation gewühlt habe nicht so ganz offensichtlich.
Je länger ich da drauf schaue, desto mehr Zweifel bekomme ich, eindeutig 
geht anders. :-)

Mit dem zweiten Byte in der CLKSEL Sequenz legt man den Multiplikator
für die PLL fest.
Bits 0 bis 5 sind für den Multiplikator selber:
0 - default
1 - ungülig, reserviert
2 bis 6 für eine Frequenz von 24MHz (2) bis 72MHz (6) bei 12MHz Takt
7 bis 31 ungültig

Bits 6 und 7 sind die "PLL range"
0 bei Multiplikator 0, 2 oder 3
1 bei Multiplikator 4, 5 oder 6

0x46: 01000110
Also Multiplikator 6 und - wofür auch immer - Bit 6 gesetzt.

Und 34MHz wäre mir zwar schon länger aufgefallen, zum Beispiel könnte 
ich dann nicht alle 20ms eine neue Display-Liste schicken.
Aber ich habe gerade mal den Takt nachgemessen über REG_CLOCK.
Ich lese REG_CLOCK gerade in der Touch-Funktion aus, bilde die Differenz 
zum alten Wert und speicher den Wert.
Damit habe ich aktuell in der Anzeige stehen: 36236x
Die letzte Stelle zappelt, sagen wir mal das ist eine 6.
362365 Takte alle 5ms, also Mal 200 -> 72473000 Takte pro Sekunde

5ms? Wirklich? :-)

Mein Logik-Analyzer meint dazu:
5,0003 ms
5,000375 ms
5,0004 ms
5,000625 ms

von Spyy (Gast)


Lesenswert?

uff...ich wollte Dich nicht schocken....:( ;)

Also ich schreibe da ne 24 rein...habe ich aus der Doku...die ist 
wirklich etwas schwierig....was Du schreibst klingt logisch aber
Wenn ich dort 46Hex reinschreibe läuft das bei mir "nur auf 3 
Töppen"..ist irgendwie komisch...Ich lasse mir jede Sekunde die 
Differenz alt/neu des CLOCK Registers ausgeben...da steht dann bei 24 
z.B. 72356841...bei 46 Hex 36854752 oder habe ich da ein Denkfehler?

komisch ist auch der PLL2 wenn ich damit die Framerate des Displays 
anpassen möchte ft81xCmdPclkfreq(42000000L, 0), dann ändert sich die 
Framerate aber das ganze Bild hat ne Farbverschiebung...

Hast Du einen externen Quarz? Ich habe keinen, ist mir auch unklar warum 
das auch ohne geht bzw. warum dann überhaupt einer Vorgesehen ist...

...komisch...

von Spyy (Gast)


Lesenswert?

Rudolph R. schrieb:
> Anyone around with a Teensy 4.1?
> I would like to know if the Teensy 4.1 target that I added a little
> while ago actually works, especially the DMA support for it.

ja, ja, ja...;-).ich mache das mit dem Teensy 4.1 leider mit DMA ohne 
Erfolg, habe mir aber nur Teile von Dir angesehen und dann wollte ich 
das selber programmieren und verstehen....

von Rudolph (Gast)


Lesenswert?

Wo hast Du die 24 her und wie genau schreibst Du das in den Chip?

Die PLL2 ist etwas seltsam zu benutzen, da habe ich ein wenig dran 
geknobelt bis das so lief wie ich das wollte.
Farbverschiebung habe ich normalerweise nicht. CSPREAD steht auf Null?

Die meisten meiner Module haben einen externen Quarz.
Ein externer Quarz ist auf jeden Fall genauer und stabiler über die 
Temperatur, wie weit das wichtig ist für EVE ist mir aber auch nicht 
ganz klar.

Spyy schrieb:
> ja, ja, ja...;-).ich mache das mit dem Teensy 4.1 leider mit DMA ohne
> Erfolg, habe mir aber nur Teile von Dir angesehen und dann wollte ich
> das selber programmieren und verstehen....

Dagegen habe ich ganz sicher nichts einzuwenden, ich wäre Dir dennoch 
dankbar wenn Du das mal ausprobieren würdest. :-)

von Spyy (Gast)


Lesenswert?

Rudolph schrieb:
> Wo hast Du die 24 her und wie genau schreibst Du das in den Chip?

Das habe ich aus dem Manual BT817/8 Advanced Embedded Video Engine 
Datasheet Version 1.1 Kapitel 4.1.5 Host command Seite 15, da steht so 
beiläufig:
2 to 6 times the osc frequency (i.e. 24 to 72MHz with 12MHz oscillator) 
in der Beschreibung für 61h CLKSEL.

Was passiert denn bei Dir wenn Du ne 24 da rein schreibst?

Ähm beim nochmal lesen soll das wahrscheinlich 24Mhz bis 72Mhz für x2 
bis x6 heissen...

von Rudolph (Gast)


Lesenswert?

Ich möchte keine 24 mit dem CLKSEL Kommando übergeben, das wäre ein 
ungültiger Wert. :-)

Bleibt die Frage, was machst Du da genau?
Das ist ja ein Host-Kommando und als ich gestern danach gesucht habe 
konnte ich zwar die Empfehlung von Bridgetek finden den Takt für die 
BT81x auf 72MHz zu setzen, aber kein Beispiel wie man das machen soll.
Alles was ich spontan finden konnte waren CLKSEL Kommandos ohne 
Parameter und somit nur für die Default 60MHz.
Damit habe ich gerade nur meinen Code der das so macht.

von Spyy (Gast)


Lesenswert?

Ich mache das so:
Serial.println("Waking up EVE chip");// Wake-up FT81x
ft81xPowerDown();  // 1) lower PD#
delay(100);    // 2) hold for 100ms
ft81xPowerUp();    // 3) raise PD#
delay(100);// 4) wait for another 100ms before sending any commands
sendCommand(FT81x_CMD_CLKINT);  //send command "CLKEXT"
delay(20);
//sendCommand(FT81x_CLKSEL); => das würde dann 60 Mhz machen
ft81xCmdParamWrite(FT81x_CLKSEL, 24);  //select the system clock
delay(10);
sendCommand(FT81x_ACTIVE);//send host command "ACTIVE" to wake up
SPI_TO_EVE_FAST;
delay(300);    // Give some time to process
....
mit ft81xCmdParamWrite:
inline void ft81xCmdParamWrite(unsigned char ftCommand, unsigned char 
ftParameter)
{
  EVE_CS_PIN_LOW;    // Set CS# low
  SPI.transfer(ftCommand);// Send command
  SPI.transfer(ftParameter);// Commands consist a parameter
  SPI.transfer(0x00);  // Send last zero byte
  EVE_CS_PIN_HIGH;  // Set CS# high
}

Fragen im BRT Forum ?

von Spyy (Gast)


Lesenswert?

Ich muss ja gestehen, dass ich das gesamte EVE board selbst mit Fusion 
360 layoutet habe...aber bei dem Routen vom SPI kann man ja eigentlich 
nicht viel falsch machen. Ich betreibe den zunächst mit 4 Mhz für die 
Init und fahre den dann auf 30 Mhz hoch. Es scheint allerdings so, dass 
ich den drosseln muss, da der EVE cmd fifo damit überlastet wird im 
Zusammenhang mit dem Teensy Takt von 600 Mhz.
Der Teensy hat 600 Mhz und ich habe eine SPI Zykluszeit für ein command 
schreiben (ohne DMA) von ca. 4-6 µs. Wenn ich mir den FIFO Status 
ausgeben lasse sieht man, dass der es nicht schafft die Daten 
wegzuschreiben. Aber vielleicht habe ich da ja auch was falsch 
verstanden. Ich dachte eigentlich der Fifo hat 4096 Bytes kann also ca. 
1000 commands puffern, aber wahrscheinlich fülle ich den voll auf und 
dann kommt der Puffer in Schwierigkeiten....es ist alles ein wenig 
verwirrend...
Wieviel commands/sec schafft EVE denn bei 72 Mhz ?

von Rudolph (Gast)


Lesenswert?

Spyy schrieb:
> Ich mache das so:
...

Das sieht jetzt spontan nicht falsch aus.
Ein wenig ineffizient und langsamer als es sein müsste, aber nicht 
falsch.

Spyy schrieb:
> Ich muss ja gestehen, dass ich das gesamte EVE board selbst mit Fusion
> 360 layoutet habe

Mit Fusion 360 kann man Layouts erstellen? Interessant.

Spyy schrieb:
> aber bei dem Routen vom SPI kann man ja eigentlich
> nicht viel falsch machen.

Also 30MHz sind schon ganz schön Analog.
Mit meinen Boards kann ich zwar locker bis über 30MHz schreiben, aber 
schon lange nicht mehr sauber lesen.

Spyy schrieb:
> Ich betreibe den zunächst mit 4 Mhz für die
> Init und fahre den dann auf 30 Mhz hoch. Es scheint allerdings so, dass
> ich den drosseln muss, da der EVE cmd fifo damit überlastet wird im
> Zusammenhang mit dem Teensy Takt von 600 Mhz.

Der Takt an sich überlastet den nicht, da geht auch noch mehr.
Bei Tests hatte ich den Takt auch schon auf 40MHz. Auf MISO kam zwar nur 
noch Unsinn, aber die Anzeige war korrekt.

Spyy schrieb:
> Der Teensy hat 600 Mhz und ich habe eine SPI Zykluszeit für ein command
> schreiben (ohne DMA) von ca. 4-6 µs.

Das sind aber schon lange Kommandos bei 30MHzs, so mit 12+ Bytes.

> Wenn ich mir den FIFO Status ausgeben lasse sieht man,
> dass der es nicht schafft die Daten wegzuschreiben.
> Aber vielleicht habe ich da ja auch was falsch
> verstanden. Ich dachte eigentlich der Fifo hat 4096 Bytes kann also ca.
> 1000 commands puffern, aber wahrscheinlich fülle ich den voll auf und
> dann kommt der Puffer in Schwierigkeiten....es ist alles ein wenig
> verwirrend...

Schreibst Du direkt in RAM_CMD oder über REG_CMDB_WRITE?

> Wieviel commands/sec schafft EVE denn bei 72 Mhz ?

Kommt schwer auf die Kommandos an, an in der Regel deutlich mehr als man 
rein stopfen kann oder muss.
Wenn Du die Kommandos auch ausführen lässt und dann noch den FIFO Status 
zurück liest, dann sollte der FIFO praktisch immer leer sein.

Darüber habe ich schon lange aufgehört mir Sorgen zu machen, einzig wenn 
man mehr als 4k in den FIFO schicken muss, etwa für ein Bild, dann muss 
man auch mal kurz warten bis der FIFO wieder frei ist.
So wie ich das mache ist nicht mal optimal, es wäre gar nicht notwendig 
zu warten bis der FIFO komplett leer ist, ich übertrage Bilder aber 
ohnehin nur beim Start des Programmes einmal.

von Spyy (Gast)


Lesenswert?

...hm.... ich glaube ich muss nochmal neu anfangen...:(

von Spyy (Gast)


Lesenswert?

Hi,

also Dein Beispiel läuft auf Teensy 4.1 mit und ohne DMA...das ganze 
Bild flackert aber so ca. jede Sekunde mal kurz...als wenn die 
Displaylist irgendwie ein Problem hat...wie es bei meiner Applikation 
auch war, gefühlt wenn die Transfers in den Fifo zu schnell waren...

Sonst sehr cool....

Grüße

von Rudolph R. (rudolph)


Lesenswert?

Also das flackern ist nicht normal und mit einmal die Sekunde ist das 
eigentlich nichts was mein Programm machen sollte.
Die Transfers in den FIFO sind nicht so schnell, das sind ja nur 
irgendwas um 200 Byte alle 20ms.
Aber vielleicht ist das was, das mein Programm nicht macht, aber tun 
sollte?

Kann es sein das der Teensy einen Watchdog hat der bedient werden will?
Das würde ich eigentlich außerhalb der loop() erwarten.

Und das ich das mit DMA für den Teensy recht zügig umsetzen konnte lag 
vor allem daran, dass die SPI Klasse für den Teensy 4.1 DMA direkt 
unterstützt.
Das war mit Abstand am Einfachsten.
Leider kennt Arduino kein DMA und so macht das jeder etwas anders.

Sonst ist das aber alles fit? Da wird nicht zum Beispiel irgendwas zu 
heiß?

von Spyy (Gast)


Lesenswert?

Ja sonst alles schick, wird nüscht zu heiss bei 600 MHz...mehr habe ich 
noch nicht probiert...

von Rudolph R. (rudolph)


Lesenswert?

Hast Du einen Logic-Analyzer?
Eine Möglichkeit wäre ja, dass das Ding durch einen Reset läuft.
Und wenn man einen Logik-Analyzer an CS, SCK und MOSI anschliesst müsste 
man das sehen können.

von Holger H. (sachma)


Angehängte Dateien:

Lesenswert?

@Rudolph
ich möchte mich für die super Library bedanken.

ESP32-S2 240MHz DMA
Display: aus Tablet EMPIRE model K701 (7") 1024x600 50 PIN
EVE4-BT818

Grüße
Holger

von Spyy (Gast)


Lesenswert?

Rudolph R. schrieb:
> Hast Du einen Logic-Analyzer?
> Eine Möglichkeit wäre ja, dass das Ding durch einen Reset läuft.
> Und wenn man einen Logik-Analyzer an CS, SCK und MOSI anschliesst müsste
> man das sehen können.

ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte 
Wert gelegt..;-)

Ein Reset bzgl. Watchdog kann ich nicht feststellen...

Ich werde mal ein paar Messungen machen (Register auslesen usw. und 
Anzeigen)
Ich kann aber auch mit meinem Code sehen, wenn ich mit voller 
Geschwindigkeit auf den EVe schreibe schaukelt sich da "ein Berg" auf 
(Ausgabe EVe busy) das heisst er verbringt immer mehr Zeit in der 
while(busy) und auch die SPI zykluszeit steigt in Wellen (schwingt) 
stark an (von 2000µs bis zu 20000µs) für meine gesamte Displayliste. 
Wenn ich dann den SPI ausbremse mit delaymicrosec geht der Wert für SPI 
natürlich hoch aber bleibt konstant und auch der Wert für busy ist dann 
konstant so bei 42µs...

von Rudolph R. (rudolph)


Lesenswert?

Holger H. schrieb:
> ich möchte mich für die super Library bedanken.

Danke für das positive Feedback!

Holger H. schrieb:
> ESP32-S2 240MHz DMA
> Display: aus Tablet EMPIRE model K701 (7") 1024x600 50 PIN
> EVE4-BT818

Nettes Upcycling und man sieht zwar nichts von der BT818 Platine,
aber die ist ganz schön klein.

Hat das Display TTL oder LVDS?



Spyy schrieb:
> ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte
> Wert gelegt..;-)

Ich auch nicht, ein paar Drähte gehen immer. :-)

> Ein Reset bzgl. Watchdog kann ich nicht feststellen...

Das ist schon mal was.

Spyy schrieb:
> Ich kann aber auch mit meinem Code sehen, wenn ich mit voller
> Geschwindigkeit auf den EVe schreibe schaukelt sich da "ein Berg" auf
> (Ausgabe EVe busy) das heisst er verbringt immer mehr Zeit in der
> while(busy) und auch die SPI zykluszeit steigt in Wellen (schwingt)
> stark an (von 2000µs bis zu 20000µs) für meine gesamte Displayliste.
> Wenn ich dann den SPI ausbremse mit delaymicrosec geht der Wert für SPI
> natürlich hoch aber bleibt konstant und auch der Wert für busy ist dann
> konstant so bei 42µs...

Sorry, aber das passt rein konzeptionell überhaupt nicht zu EVE.
Wie Du in dem Bild das Holger gerade gepostet hat sehen kannst, übeträgt 
mein einfaches Test-Programm 224 Bytes an Kommandos für einen Refresh.
Die angezeigte Zeit ist mit DMA nur wie lange das dauert den Puffer zu 
füllen, danach braucht es dann noch mal xxx µs bis der Transfer durch 
ist.
Ein Arduino Uno braucht mit 8MHz SPI so ungefähr 500µs pro Bild bei dem 
Test-Programm.
Und dann ist erstmal Sende-Pause auf dem SPI.
Das nächste was in meinem Test-Programm passiert ist das zwei Register 
gelesen werden, das eine für die Länge der Display-Liste, das andere für 
den Touch, das hat Holger offenbar unterbunden, weil das Display keinen 
Touch hat.
Erst 20ms nach dem Refresh wird der nächste auf den Weg gebracht, der 
CMD-FIFO ist dann ganz sicher leer.
Warum erst 20ms später? Weil der Refresh nicht schneller erfolgen darf 
als EVE die Display-Liste abarbeitet und die Displays haben meistens so 
um die 60Hz.
Ein paar liegen drüber, weil das mit den Parametern nicht richtig 
einstellbar ist, EVE3-50G betreibe ich zum Beispiel mit 73Hz da sich der 
BT815 ja nicht fein einstellen lässt.
Das ist mit PCLK = 2 und bei PCLLK = 3 sind es gleich nur noch 49Hz.
Ein älteres 1024x600 mit FT813 kommt gerade so über 30Hz, da muss ich 
dann auch entsprechend den Refresh langsamer einstellen.

Wenn man das jetzt auf den Framewechsel synchronisieren würde, wofür 
auch immer, dann wäre da bei 73Hz trotzdem ein Abstand zwischen den 
Transfers auf dem SPI von 13,7ms und das reicht locker aus um den FIFO 
mehr als einmal voll zu machen für übertrieben viele Kommandos in einer 
Liste.

Oh ja:
https://user-images.githubusercontent.com/31180093/103809372-b42b9a80-5059-11eb-9906-6e049c975d07.png

Das "DL-size: 900" ist die Länge der Display-Liste die der Kommando 
Co-Prozessor aus den 224 Byte Kommandos generiert.
Das muss man im Blick behalten, das dürfen nicht mehr als 8k werden.
Und zum Beispiel 6 CMD_CLOCK füllen die Display-Liste mal eben zu 10%.

von Rudolph R. (rudolph)


Lesenswert?

Spyy schrieb:
> ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte
> Wert gelegt..;-)

Wie sieht eigentlich der Schaltplan dazu aus und was für ein Display 
benutzt Du überhaupt?

von Holger H. (sachma)


Angehängte Dateien:

Lesenswert?

Rudolph R. schrieb:

> aber die ist ganz schön klein.
die Platine hat 57x32 mm
und ist nur ein Test ob alles läuft, ich hatte zuerst eine BT817 Version
mit LVDS erstellt, leider konnte ich den LVDS-Umsetzer und auch den 
BT817 nicht bekommen. Den LVDS-Umsetzer habe ich mittlerweile auf den 
BT817 warte ich noch.
Da sitzt dann auch ein Eeprom mit drauf und der cap. Touch ist 
herausgeführt.

> Hat das Display TTL oder LVDS?

TTL - LVDS werde ich hier über eine Zusatzplatine 50PIN TTL-> 40PIN LVDS 
aufbauen, so wie ich es mit der VCOM Platine gemacht habe.

von Rudolph R. (rudolph)


Lesenswert?

Schick, das sieht so einfach und aufgeräumt aus.

Irgendwann muss ich sowas vielleicht doch mal machen, einfach um das 
gemacht zu haben, aber so viele Projekt, so wenig Zeit. :-)
Und für QFN kann ich mich dann auch eher nicht so begeistern.

BT817 sind scheinbar etwas knapp im Moment, damit sind die ja nicht 
alleine, der Markt ist insgesamt etwas schwierig.
Ich warte seit 6 Wochen auf ein Display und das wird sich noch weiter 
hin ziehen, ich weiß aber nicht ob der BT817 da das fehlende Teil ist.

von c-hater (Gast)


Lesenswert?

Rudolph R. schrieb:

> Aber ja, die Bandbreite ist begrenzt

Dass sie begrenzt sein muss, war natürlich von vorn herein klar. Die 
Frage war bloß, wo diese Grenze liegt. Ich hatte mich da auf das DB 
verlassen, was dazu ausführt (Unter "4.4 SPI NOR Flash Interface"):

The interface will work at system clock speed (up to 72MHz) at 4
bit mode.

Ich meine: das kann man kaum fehlinterpretieren, dazu ist der Satz zu 
kurz und zu einfach gestrickt.

> und der Takt mit dem das QSPI flash
> betrieben wird liegt wohl beim halben Systemtakt, also 36MHz.

Das sehe ich inzwischen genau so. Erstens deshalb, weil es ja irgendwie 
"das Übliche" wäre und zweitens, weil ich es inzwischen ganz praktisch 
noch deutlich genauer ausgeklingelt habe und dabei auf eine Grenze von 
120..128MBit/s für völlige Ruckelfreiheit gekommen bin.

Das liegt prozentual ziemlich genau so viel unter den 144MBit/s, wie ich 
als Sicherheitsabstand zu den ursprünglich angenommenen 288MBit/s aus 
Erfahrung eingeplant hatte...

> Ein etwas fieserer Test ist ein Bild von 256x256 aus dem Flash
> anzuzeigen und dabei zu drehen.

Was soll dieser Test bezüglich der Bandbreite der Flashanbindung 
bringen? Gedreht (u.a.) wird bei mir nur das animierte Logo. Das ist 
allerdings nur 159x159 Pixel groß.
Die beiden Bilder der Slideshow sind jeweils 570x277 und der 
teiltransparente Frame im Vordergrund ist 800x480.

Vollständiges "Abschalten" aller Transformationen für das Logo hat 
übrigens nur eine minimale Änderung gebracht. So klein, dass man sie 
auch getrost als Meßfehler verbuchen kann.

> Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar

Sie haben ihre Nische, glaub' mir. Sonst müsste ich mich nicht damit 
beschäftigen. ;o)

von Spyy (Gast)


Angehängte Dateien:

Lesenswert?

Rudolph R. schrieb:
> Spyy schrieb:
>> ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte
>> Wert gelegt..;-)
>
> Wie sieht eigentlich der Schaltplan dazu aus und was für ein Display
> benutzt Du überhaupt?

Also Display ist von BuyDisplay 480x480 Platine siehe Bilder...

EvE ist jetz leider abgeraucht, plötzlich viel Strom gezogen und 
knallheiss...
Wie sieht den Deine VOUTV1 Beschaltung mit Kondensatoren aus?

von Spyy (Gast)


Lesenswert?

...Blöd wenn man seinen Beitrag nicht editieren kann...habe ein Foto 
doppelt und Tippfehler...sorry..

von Rudolph R. (rudolph)


Lesenswert?

Spyy schrieb:
>> Wie sieht eigentlich der Schaltplan dazu aus und was für ein Display
>> benutzt Du überhaupt?
>
> Also Display ist von BuyDisplay 480x480 Platine siehe Bilder...

Also das beantwortet die Frage nach der Verschaltung jetzt nicht mal 
ansatzweise. :-)
Also vor allem wie der BT81x versorgt ist und wie der SPI vom Teensy zu 
EVE und zurück gelangt wäre mal interessant. :-)

Ich werde zum Beispiel nicht grundlos Logik-Bausteine in der 
Schnittstelle, ich musste erstmal feststellen das die ATSAMC21 bei 3,3V 
nicht genug Strom liefern können um den SPI jenseits von 8MHz stabil 
laufen zu lassen.
Also jetzt vor allem auch mit den zwei Steckverbindern und dem 
Folien-Flex-Kabel dazwischen.

> EvE ist jetz leider abgeraucht, plötzlich viel Strom gezogen und
> knallheiss...

Mist.

> Wie sieht den Deine VOUTV1 Beschaltung mit Kondensatoren aus?

Ich habe ja noch kein Board designed, mir geht vor allem auf den Keks 
das Displays zum einen nicht ganz einfach beschaffbar sind, zum anderen 
jeder Hersteller mehrere Pin-Belegungen und Stecker für seine Modelle 
hat.

Aber wenn ich ein Board designen würde, das Datenblatt ist zwar 
unübersichtlich, aber es gibt wenigstens etwas Beschreibung zu den Pins 
und es gibt auch noch den Schaltplan von dem BT817 Board von Bridgtek.

An Pin 25 würde ich 4,7µF und 100nF packen.
Das ist mit Pin 2 verbunden, der bekommt 1µF und 100nF.
Und dann noch Pin 57, dem würde ich auch 100nF verpassen.
An Pin 2 vielleicht sogar auch 4,7µF, eine Position weniger in der 
Stückliste.

In den Schaltplänen hat Bridgetek sogar 10µF+100nF an Pin 25.

Wenn man mal in den EVE3 Schaltplan von Matrix Orbital schaut, die haben 
sogar nur 4,7µF und einmal 100nF an den drei Pins zusammen.
Und die laufen stabil, an denen stört mich nur die nicht abgetrennte 
Versorgung für die Hintergrund-Beleuchtung.

von Rudolph R. (rudolph)


Lesenswert?

c-hater schrieb:
>> Ein etwas fieserer Test ist ein Bild von 256x256 aus dem Flash
>> anzuzeigen und dabei zu drehen.
>
> Was soll dieser Test bezüglich der Bandbreite der Flashanbindung
> bringen?

Damit haben die BT81x auf manchen Platinen ein Problem.
Das liegt wohl daran das der Zugriff auf das Flash dann nicht linear 
erfolgt.

c-hater schrieb:
>> Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar
>
> Sie haben ihre Nische, glaub' mir. Sonst müsste ich mich nicht damit
> beschäftigen. ;o)

Der gefällt Dir okay, viel Spass damit.
Das war aber nicht meine Aussage dazu.

Rudolph R. schrieb:
> Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar,
> der ist praktisch ein ATSAMC20 mit halbem Takt, halbem Speicher und AVR
> Kern.
> Das Argument das wäre ein AVR zieht irgenwie auch nicht wenn die
> Software ganz anders aussieht und man sich trotzdem neu einarbeiten
> muss.

Das war jetzt kein das-gibt-es-woanders-besser (STM32), der Witz ist 
doch das Microchip schon seit Jahren den ATSAMC20 im Sortiment hat und 
die AVR128DA sehen aus wie eine im Funktionsumfang reduzierte und 
langsamere Variante davon. Unter dem Aspekt scheint der AVR128DA ein 
komplett überflüssiges Produkt zu sein.

Ich finde nur Argumente gegen den AVR128DA, wie zum Beispiel das der 
kein DMA kann, was wäre denn ein Argument für das Teil?

: Bearbeitet durch User
von Spyy (Gast)



Lesenswert?

So...Schaltung anbei kann man eigentlich nicht viel falsch machen...
Ich habe 2 Spannungsebenen, 3.3V und den Teensy und das Backlight mit 
5V.

Was hat denn das eigentlich auf sich mit den 1.2V VOUT und den 
Kondensatoren, bei den "älteren" EVEs musste man da ja sogar ein Elco 
ranhängen...

Crystal habe ich komplett weggelassen, ist dann ja einfacher und weniger 
Bauteile. Ich bestücke ja mit SMD selber, dass kann schon mal in Arbeit 
ausarten. Die ganze Anpassung an das Display (Backlight, Pins) habe ich 
auf einer eigenen Platine die dann auf dieses "Mainboard" geklibst wird. 
Und ich habe einfach die Widerstandswerte die in Reihe mit den RGB 
Leitungen geschaltet sind (33Ohm) von der Schaltung von den NewHaven 
Displays übernommen. Gibt es da Auslegungskriterien oder probiert man 
das einfach aus bis das Bild auf dem Oszi vernünftig aussieht ?

Grüße

von c-hater (Gast)


Lesenswert?

Rudolph R. schrieb:

> Ich finde nur Argumente gegen den AVR128DA, wie zum Beispiel das der
> kein DMA kann, was wäre denn ein Argument für das Teil?

Die Hauptvorteile sind:
Weiter Bereich der Betriebsspannung (1,8V..5,5V).
Und nicht zu vergessen: der Preis.

Aber ich gebe zu: eine kleine DMA-Einheit wäre schon ganz nett gewesen.

von Rudolph R. (rudolph)


Lesenswert?

Ich habe gerade mal in das Datenblatt der IMXRT1060 geschaut und die 
können pro Pin auf der höchsten Einstellung auch nur typisch 4mA 
liefern.
Keine Idee was da von dem Arduino Core eingestellt wird, oder ob 
überhaupt die Default-Einstellung verändert wird, oder was die 
Default-Einstellung wäre.
Aber wenn das wieder läuft könnte es sich lohnen den SPI mal langsamer 
zu machen, 4MHz, 2MHz oder gar 1MHz.

von Rudolph R. (rudolph)


Lesenswert?

c-hater schrieb:
> Die Hauptvorteile sind:
> Weiter Bereich der Betriebsspannung (1,8V..5,5V).

OK, da gewinnt der AVR128DA, der ATSAMC20 ist "nur" von 2,7V bis 5,5V 
angegeben.

> Und nicht zu vergessen: der Preis.

Och, das gibt sich nicht viel, vor allem nicht bei kleinen Mengen.
Ein ATSAMC20J18A-AUT liegt bei €2,15, das sind 64 Pins und 256k Flash.
Ein ATSAMC21J18A-AUT der auch noch zwei CAN-FD Kanäle hat liegt bei 
knapp über 3 Euro.
Und das sind auch nur Apothekenpreise, wenn auch ohne Mehrwertsteuer.

Bei den Preisen habe ich bisher nicht mal erwägt die Versionen mit 
weniger Speicher zu verwenden, auch wenn ich mit zum Beispiel den 64k 
Versionen ein paar Cent sparen könnte.
Völlig egal wenn das nicht Serie ist.
Und wenn es Serie ist kauft man die Dinger auch nicht mehr in der 
Apotheke.

von c-hater (Gast)


Lesenswert?

Rudolph R. schrieb:

> Och, das gibt sich nicht viel, vor allem nicht bei kleinen Mengen.

Huch? Bei Mouser gibt's den SAM als Einzelstück (Reel-Abschnitt) für 
2,16€. Zzgl. 5€ Strafgebühr für's Abschneiden. Macht satte 7,16€ netto 
total.

Den AVR128DA64 hingegen gibt es als Einzelstück ohne Strafgebühr für 
1,78€. Das ist nicht nur ganz erheblich billiger als das 
SAM-Einzelstück, sondern auch noch in anderer Hinsicht interessant:

Diesen Einzelpreis erreicht man nämlich (natürlich zufällig) bei dem SAM 
erst, wenn man ein komplettes Reel (1500 Stück abnimmt).

Wieder zurück zum AVR128DA64. Reel-Preise dafür gibt es noch nicht. 
Maximale Stückelung ist bisher 250 mit einem Einzelpreis von 1,47€. 
Keine Verhandlungsoption. Scheint also Verkäufermarkt zu sein, sprich: 
ist noch knapp. Aber selbst mit diesem Preis kosten dann 1500 Stück 
2205€.

Das SAM-Reel hingegen kostet 2670€. Allein schon dadurch hat mein 
Brötchengeber bei einer 1500er Serie 475€ extra Cash in de Täsch, ohne 
sich auch nur ein Stück zu bewegen. Das entspricht einer Einsparung von 
18%.

Was aber noch wichtiger ist: der SAM ist schon ewig am Markt. Bei der 
MC-Produktpolitik bedeutet das in der mittelfristigen Projektion: 
mindestens der Preis wird steigen, u.U. droht auch die Abkündigung. Das 
passiert in der Vergangenheit bei MC zwar eher selten, aber eindeutig 
mit zunehmender Häufigkeit.
Für den AVR128 hingegen ist im selben Projektionszeitraum eher mit 
fallenden Preisen zu rechnen (zumindest in Stückzahlen, das Einzelstück 
wird wohl kaum noch viel günstiger werden).

Fazit: schon jetzt ist der AVR128DA für jede Anwendung, für die seine 
Rechenleistung auch genügt, deutlich günstiger. Und in der 
mittelfristigen Zukunft wird der Vergleich mit an Sicherheit grenzender 
Wahrscheinlichkeit noch mehr zum Vorteil des AVR128DA ausfallen.

Aber um letztlich zum eigentlichen Thema zurück zu kommen: das 
Bandbreitenproblem der Flashanbindung der BT81x hat man mit beiden 
Host-Controllern gleichermaßen und sollte es bei der Planung der 
Anwendung entsprechend berücksichtigen. ;o)

von Rudolph R. (rudolph)


Lesenswert?

Wie ich schrieb, bei kleinen Mengen.
Selbstverständlich kann man die bei Mouser auch als Gurtabschnitt ohne 
Reel kaufen und natürlich kostet das aufziehen von Minder-Mengen auf ein 
Reel extra.
Dann bleiben Deine genannten €2,16 zu €1,78 - Peanuts, vor allem wenn 
man dafür DMA, die doppelte Geschwindigkeit und mehr Peripherie bekommt.

Wenn man die bei Microchip direkt kauft kosten die auf Rolle:
ATSAMC20J17A-AUT €1.76
AVR128DA64T-I/PT €1.48

Aber ich würde ich eher mal bei Arrow, Avnet oder EBV anfragen, also 
auch gerade die AVR128DA64 wenn die für die Anwendung ausreichend sind.
Zumal die ATSAMC20J15A-AUT und die ATSAMC20J18A-AUT bei Microchip 
ebenfalls
€1.76 das Stück kosten sollen wenn man eine ganze Rolle bestellt,
da ist gegenüber der regulären Distribution eventuell noch etwas Luft.

Seltsam ist auch, bei den ATSAMC20J sind eine volle Rolle 1500 Stück,
bei den AVR128DA64 sind es aber nur 1200 Stück.
Das ist aber das gleiche Package.
Im Tray sind es bei beiden 260 Stück.

1500 Stück sind aber auch nur Peanuts, also wenn man schon über Preis 
pro Stück fabuliert.

Es gibt übrigens auch noch einen PIC32CM, der ist praktisch identisch 
mit dem ATSAMC20, Microchip hat den "aus Gründen" neu aufgelegt, 
vermutlich um die PIC Kunden an ARM ran zu führen.

Und um auch mal zum Thema zurück zu kommen... :-)
Vielleicht sollte ich mir mal ein DM164151 zulegen.
Einfach mal zu schauen was die da aktuell treiben. :-)

Aber vorher müsste ich eigentlich noch heraus finden warum ich mit dem 
BBC MicroBit V2 keine Anzeige bekomme obwohl der SPI gut aussieht.

: Bearbeitet durch User
von Daniel S. (snipod)


Angehängte Dateien:

Lesenswert?

Hallo,
ich habe mal wieder ein Problem, welches ich nicht durchblicken kann.

Ich lade 3 Fonts und einige Bilder in den EVE. Das Funktioniert soweit 
auch tip top, jetzt habe ich weitere Bilder ergänzt und sobald ich 
dieser neuen verwende funktioniert anscheinend eine Schriftart nicht 
mehr... Im RAM_G sollte noch genug Platz sein.

Die neuen Bilder sind ARGB2 formatiert, alles andere bisher ARGB1555.

Anbei die "Partitionstabelle" vom EVE, sowie Bilder wie es mit und ohne 
reinladen aussieht
1
void drawButton(uint16_t x, uint16_t y, uint16_t w, uint16_t h, uint16_t r, const char *label, uint64_t adr_img, uint16_t w_img, uint16_t h_img, bool highlighted)
2
{
3
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
4
    EVE_cmd_dl_burst(LINE_WIDTH(r * 16)); 
5
    EVE_cmd_dl_burst(DL_COLOR_RGB | (highlighted ? HIGHLIGHT : RAL9001));
6
    EVE_cmd_dl_burst(VERTEX2F(x + r, y + r));
7
    EVE_cmd_dl_burst(VERTEX2F(x + w - r, y + h - r));
8
    EVE_cmd_dl_burst(DL_END);
9
    EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_BLACK);
10
    EVE_cmd_text_burst(x + (w / 2), (y + h + 16), OPENSANS_REGULAR_15, EVE_OPT_CENTER, label);
11
12
    if (adr_img != 0 && w_img != 0 && h_img != 0)
13
    {
14
        EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_WHITE);
15
        EVE_cmd_setbitmap_burst(adr_img, EVE_ARGB2, w_img, h_img);
16
        EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
17
        EVE_cmd_dl_burst(VERTEX2F((x + (w / 2) - (w_img / 2)), (y + (h / 2) - (h_img / 2))));
18
        EVE_cmd_dl_burst(DL_END);
19
    }
20
}

Weiß jemand was hier falsch läuft?

EDIT:// Es ist NUR die OPENSANS_REGULAR_15 die dann nicht mehr geht. Mit 
jeder anderen Schriftart tut es noch

: Bearbeitet durch User
von Daniel S. (snipod)


Lesenswert?

Ich konnte das Problem lösen:

Nach den EVE_cmd_setfont2 muss das BITMAP_HANDLE wieder zurück gesetzt 
werden.

Ich habe die Fonts jetzt auf den Handles 13-15 und setze das Handle nach 
dem laden der Fonts wieder auf 0 EVE_cmd_dl(BITMAP_HANDLE(0));

von Rudolph R. (rudolph)


Lesenswert?

Daniel S. schrieb:
> Nach den EVE_cmd_setfont2 muss das BITMAP_HANDLE wieder zurück gesetzt
> werden.
>
> Ich habe die Fonts jetzt auf den Handles 13-15 und setze das Handle nach
> dem laden der Fonts wieder auf 0 EVE_cmd_dl(BITMAP_HANDLE(0));

Das ist schon etwas seltsam, setfont2 sollte eigentlich nicht
das aktuelle Bitmap-Handle verdrehen.

Handle 15 ist übrigens nicht frei in dem Sinne, das ist "Scratch".
"Bitmap handle 15 is used by the 3D-effect buttons, keys and gradient, 
unless it is set to another bitmap handle using CMD_SETSCRATCH."

Es gibt ohnehin etwas wenig Bitmap-Handles, da hätte ich mir schon 
gewünscht, dass die mindestens verdoppelt werden.
Aber ich nutze zum Beispiel die Fonts 16 bis 25 nie, die würde ich 
einfach neu zuweisen wenn es mal echt knapp werden würde.

von Werner (Gast)


Lesenswert?

Hallo Rudolph,
weisst du, ob der cap. Touch-Controller ILI2130 mit dem FT811 kompatibel 
ist?

Und hast du vielleicht eine Quelle, wo man den FT811 noch beziehen kann 
(oder hast du selbst Restbestände)?

Viele Grüsse
Werner

von Rudolph (Gast)


Lesenswert?

Werner schrieb:
> weisst du, ob der cap. Touch-Controller ILI2130 mit dem FT811 kompatibel
> ist?

Ich kann es nicht sagen, ich habe zuletzt nach den ILI2132A gesucht die 
Riverdi aktuell auf die EVE4 packt und gar nichts dazu gefunden.

Werner schrieb:
> Und hast du vielleicht eine Quelle, wo man den FT811 noch beziehen kann
> (oder hast du selbst Restbestände)?

Ich habe keine, ich verbaue die ja auch nicht auf eigenen Platinen.
Und ich habe kurz mal danach geschaut, das sieht echt nicht gut aus. :-(
Unfassbar, das wird ja immer schlimmer mit Bauteilen.

von Ioan Mihai Cozac (Gast)


Lesenswert?

Spyy schrieb:
> Ich mache das so:
..................................
> //sendCommand(FT81x_CLKSEL); => das würde dann 60 Mhz machen
> ft81xCmdParamWrite(FT81x_CLKSEL, 24);  //select the system clock
> delay(10);
> sendCommand(FT81x_ACTIVE);//send host command "ACTIVE" to wake up
> SPI_TO_EVE_FAST;
> delay(300);    // Give some time to process
> ....
> mit ft81xCmdParamWrite:
> inline void ft81xCmdParamWrite(unsigned char ftCommand, unsigned char
> ftParameter)
> {
>   EVE_CS_PIN_LOW;    // Set CS# low
>   SPI.transfer(ftCommand);// Send command
>   SPI.transfer(ftParameter);// Commands consist a parameter
>   SPI.transfer(0x00);  // Send last zero byte
>   EVE_CS_PIN_HIGH;  // Set CS# high
> }
ft81xCmdParamWrite(FT81x_CLKSEL, 24);
24 ist dezimal Wert glaube ich... das bedeutet 0x18 in hexadezimal.

von Rudolph (Gast)


Lesenswert?

Ioan Mihai Cozac schrieb:
> ft81xCmdParamWrite(FT81x_CLKSEL, 24);
> 24 ist dezimal Wert glaube ich... das bedeutet 0x18 in hexadezimal.

Na, wie ich weiter oben im Detail ausgeführt habe, 24 ist ein ungültiger 
Wert, das wird als 0x18 auch nicht gültiger. :-)

>Mit dem zweiten Byte in der CLKSEL Sequenz legt man den Multiplikator
>für die PLL fest.
>Bits 0 bis 5 sind für den Multiplikator selber:
>0 - default
>1 - ungülig, reserviert
>2 bis 6 für eine Frequenz von 24MHz (2) bis 72MHz (6) bei 12MHz Takt
>7 bis 31 ungültig
>
>Bits 6 und 7 sind die "PLL range"
>0 bei Multiplikator 0, 2 oder 3
>1 bei Multiplikator 4, 5 oder 6
>
>0x46: 01000110
>Also Multiplikator 6 und - wofür auch immer - Bit 6 gesetzt.

von Spyy (Gast)


Lesenswert?

So...nachdem mein neues Board erstmal mehrere Tage beim Zoll verbracht 
hat, habe ich es jetzt wieder zum laufen gebracht....ich muss dann doch 
nochmal darauf zurück kommen....leider, ich weiss ja hier auch nicht 
weiter...

Also ich habe noch mal "gemessen":

Ich habe ne Display/Command list von 204 Bytes => DL-size 692
Ich lasse mir den CmdRead und CmdWrite ausgeben.

Display FPS: 70 Hz
SPI: 1 Mhz-25Mhz => bei 20 Mhz => 21 µs => Signale auf dem Oszi bei 20 
Mhz nicht mehr schön aber OK
Übertragungsrate der Liste jede 1000 ms => OK CmdRd/CmdWr immer gleich
Übertragungsrate der Liste jede 500 ms => OK CmdRd/CmdWr immer gleich
......
Übertragungsrate der Liste jede 50 ms => OK CmdRd/CmdWr immer gleich
Übertragungsrate der Liste jede 30 ms => OK CmdRd/CmdWr immer gleich
Übertragungsrate der Liste jede 25 ms => Teilweise OK CmdRd/CmdWr nicht 
mehr immer gleich (Rd "hinkt" hinterher, Delta erhöht sich, Bild 
flackert)
Übertragungsrate der Liste jede 20 ms => Nicht mehr OK, CmdRd/CmdWr 
nicht mehr gleich (Wr "hinkt" hinterher, Delta erhöht sich, Bild 
flackert stark)

Wenn man jetzt die FPS etwas erhöht wird das wieder besser, hat also 
irgendwas damit zu tun. Jetzt habe ich mal in Deinen Code geschaut, ob 
irgendwo abgefragt wird, ob der EVE zu tun hat bzw. noch Platz hat. Habe 
ich das hier gefunden:

void EVE_start_cmd_burst(void)
{
  uint32_t ftAddress;

#if defined (EVE_DMA)
  if(EVE_dma_busy)
  {
    while (EVE_busy()); /* this is a safe-guard to protect segmented 
display-list building with DMA from overlapping */
  }
#endif

  cmd_burst = 42;
  ftAddress = REG_CMDB_WRITE;

Ich verstehe das so, dass das die Abfrage ist, ob der EVE "bereit" ist 
weitere Daten aufzunehmen. Hier ist aber zu erkennen, dass Du erstmal 
abfragst, ob DMA busy ist und wenn DMA busy ist dann den EVE chip. DMA 
scheint aber immer nicht busy zu sein => dadurch wird der EVE chip nicht 
mehr abgefragt while(EVE_busy()), da das ja in dem if ist. Ich habe das 
mal so geändert (in EVE_busy() ist ja auch die EVE_dma_busy Abfrage 
drin):
  if(EVE_busy())
  {
    while (EVE_busy());     /* this is a safe-guard to protect segmented 
display-list building with DMA from overlapping */
    {
      //Serial.println("EVE Busy");
    }
  }
Da ich das wohl aber nicht so ganz überblicke bleibt das Programm in 
einer Endlosschleife hängen (ich denke bei while(EVE_busy())).
Für das ganze ist übrigens die SPI Geschwindigkeit egal, ist auch so bei 
1 Mhz...

Grüße

Torsten

von Rudolph (Gast)


Lesenswert?

Hast Du mal VSYNC gemessen?
Das klingt jetzt so als hättest Du eher 35 FPS als 70.

von Spyy (Gast)


Lesenswert?

Also ich denke man kann nur mit 1/2 der aktuellen FPS des Displays Daten 
hinschicken und die DL swappen...das kommt ungefähr hin 80 Hz => mit 40 
Hz Daten...

von Spyy (Gast)


Lesenswert?

...ja werde ich noch einmal messen...

von Spyy (Gast)


Lesenswert?

...mich wundert natürlich wieso sonst keiner "diese Probleme" hat, also 
Hardware kann ich mal ausschliessen, keine Ahnung, ob das noch jemand 
mit dem Teensy 4.x gemacht hat. Ist auch unabhängig mit/ohne DMA, immer 
das gleiche Verhalten, ab einer gewissen Updategeschwindigkeit der Liste 
wird die Displayliste "zerschossen" bzw. Rd/Wr laufen auseinander und Wr 
überholt Rd.

von Rudolph R. (rudolph)


Lesenswert?

Was Du noch machen könntest wäre einmal pro Sekunden den Inhalt von 
REG_FRAMES zu lesen und die Differenz zum vorherigen Wert auszugeben.

Edit: eben die Frage im BRT Forum gesehen.
REG_CLOCK geht auch, das ist einfach nur ein 32-Bit Zähler der mit 
Systemtakt läuft.

Und Du könntest mal die kompletten Timing-Werte für das Display über den 
Zaun reichen.

Das Problem hatte ich noch gar nicht, die 20ms habe ich schon querbeet 
über diverse Displays mit diversen MikroControllern benutzt, FT800, 
FT810, FT811, FT811, BT815, BT817.
Und bei dem einen 1024x600 Display mit FT813, bei dem es gar nicht 
möglich ist über 38 FPS zu kommen, lief das wie erwartet nicht richtig 
und hat geflackert, mt 30ms Refresh aber doch.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

@Spyy
Da ich gerade mit einem billigen 24MHz Logik-Analyzer und Pulseview 
herum spiele, hast Du Dir mal angesehen was der Teensy so auf den SPI 
wirft?
Ich musste den SPI etwas runter drehen damit ich mit dem LA überhaupt 
brauchbar messen kann und bin jetzt bei 4MHz.
Aber unter Beibehaltung des 5ms Rasters reicht das locker für 2200 Bytes 
bevor auch nur die nächste Touch-Abfrage übersprungen wird.
Ein Pulseview Trace vom Startup hängt an.

Ich habe gerade mal bei den 904 Bytes die mein Bildwechsel im Moment 
braucht den SPI auf 400kHz runter gedreht.
Der einzige "negative" Effekt ist das der Touch nicht mehr alle 5ms 
abgefragt wird, sondern nur noch alle 20ms, die Übertragung für den 
Bildwechsel dauert so rund 18ms und damit ist der SPI dann einfach drei 
Mal beschäftigt wenn der Touch abgefragt werden soll.

Jetzt habe ich bei 4MHz SPI den Bildwechsel mal auf 15ms / 66Hz 
gestellt.
Das klappt ohne Probleme da ich das EVE3-50G das hier gerade anhängt auf 
74Hz laufen lassen - nicht, weil ich 74Hz brauche, sondern weil der 
BT815 etwas eingeschränkt ist was den Pixel-Clock angeht.

Stelle ich den Bildwechsel auf 10ms blinkt das nicht mal mehr.
Bei 12,5ms funktioniert es auch nicht.
Hmm, drehen wir mal an der Zeitbasis. :-)
Mit Intervallen von 1,7ms läuft es noch wenn ich alle 13,6ms einen 
Bildwechsel mache. :-)

von Daniel S. (snipod)


Lesenswert?

Hi,
kann mir zufällig jemand erklären, wie ich Umlaute in die Fonts bekomme, 
bzw. generell "richtig" mit einem custom character set arbeite?

Was ich versucht habe:
User Defined Charater Set -> Textdatei, UTF-8 codiert mit folgendem 
Inhalt (ohne die Anführungszeichen natürlich...)

" 
!"%&()*+,-./0123456789?ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuv 
wxyzÄÖÜäöüß"

Font generiert, komprimiert, und ab damit in RAM_G

Dann
1
EVE_cmd_setfont2_burst(OPENSANS_REGULAR_22, Adr_OpenSans_Regular_22, 32);
2
EVE_cmd_text_burst(50, 220, OPENSANS_REGULAR_22, EVE_OPT_FILL, " !""%&()*+,-./0123456789?ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyzÄÖÜäöüß");

Leider kommt da aber ziemlicher Kauderwelsch raus :) ich tippe mal 
irgendwas mache ich bei der Adressierung der Buchstaben verkehrt

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Speichert Dein Editor den Text auch wirklich mit UTF-8 Kodierung?
Das Atmel-Studio musste ich erstmal entsprechend umstellen.

Man kann beim Konvertieren übrigens auch alle Zeichen bis zum letzten 
gewünschten Mitnehmen, das wäre in dem Fall "ü" und ich habe mal eine 
entsprechende Charmap-Datei angehängt.

Das Format ist leider so ineffizient gestaltet das so oder so eine 
Glyphe für alle Zeichen bis zum letzten erzeugt wird, bei ungenutzen 
Zeichen ist die zwar leer, belegt aber dennoch den vollen Platz, da kann 
man die dann auch gleich mitnehmen.

Und schaut mal hier: http://www.brtcommunity.com/index.php?topic=127.15
Es gibt einen inoffiziellen EVE-Asset-Builder-setup-2.2.0-rc2.zip
Wesentlich ist da, der ASTC-Encoder wurde auf V2 aktualisiert, damit 
geht das Konvertieren von Fonts richtig schnell.
Nur wie ich schrieb, Bridgtek hat die Version für AVX2 in das Archiv 
gepackt, wenn die eigene CPU keine AVX2 kennt läuft das aber wenn man 
das durch eine entsprechende Version von hier 
https://github.com/ARM-software/astc-encoder ersetzt.

von c-hater (Gast)


Lesenswert?

Rudolph R. schrieb:

> wenn die eigene CPU keine AVX2 kennt

Das kann doch nur eine sehr historische CPU sein, oder?

Ich meine, ich arbeite hier privat regulär mit einem zehn Jahre alten 
Core2Duo E8500. Selbst der kann das schon.

Was den AssetBuilder betrifft: Das war das Erste, was ich durch eigene 
Software ersetzt habe. (Wobei der eigentliche ASTC-Encoder "zugekauft" 
ist, das ist allerdings im BT-Original genauso ;o)

Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes 
Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings 
sehr viel komfortabler als das Original. Vor allem im Bezug auf einen 
AVR8-Host als Zielsystem...

von Rudolph R. (rudolph)


Lesenswert?

c-hater schrieb:
>> wenn die eigene CPU keine AVX2 kennt
>
> Das kann doch nur eine sehr historische CPU sein, oder?

Naja, fast, ich habe einen AMD FX-8320E im Rechner, das war so praktisch 
die dickste CPU die ich vor ein paar Jahren noch für mein AM3+ Mainboard 
bekommen konnte, Markteinführung war September 2014, gekauft im Februar 
2016.
Der hat zwar schon eine ganze Latte an Features, aber kein AVX2.
Die SSE4 Version vom ASTENC ist V2 läuft und ist deutlich schneller als 
die V1.x die vorher beim EVE Asset Builder beilag.

> Ich meine, ich arbeite hier privat regulär mit einem zehn Jahre alten
> Core2Duo E8500. Selbst der kann das schon.

Also laut Wikipedia nicht, der kann nur bis SSE4.1, AVX kam Anfang 2011 
und AVX2 kam Mitte 2013 von Intel.

Ich schiele zwar schon auf einen Ryzen 5600X, aber das letzte Mal das 
ich ein paar Komponenten zusammen gestellt habe um den Rechner 
aufzurüsten war ich viel zu schnell bei über 1000 Euro, so langsam ist 
die Kiste dann auch wieder nicht. :-)
Der Markt ist im Moment auch insgesamt eher unlustig.

c-hater schrieb:
> Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes
> Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings
> sehr viel komfortabler als das Original. Vor allem im Bezug auf einen
> AVR8-Host als Zielsystem...

Die ersten EVE Asset Builder habe ich auch nicht genutzt, sondern lieber 
den Image-Converter aus der Shell.
Nur ist der EAB stetig besser geworden, Bridgetek hat auf meinen 
Vorschlag hin sogar ein ein BIN2C Tool eingebaut. :-)
Braucht man das? Nicht wirklich in dem Sinne, aber jetzt muss ich das 
Tool nicht mehr wechseln.
Und seit den BT815 erzeuge ich Flash Images mit dem EAB und übertrage 
die damit.

von c-hater (Gast)


Lesenswert?

Rudolph R. schrieb:

>> Core2Duo E8500

> Also laut Wikipedia nicht, der kann nur bis SSE4.1, AVX kam Anfang 2011
> und AVX2 kam Mitte 2013 von Intel.

Nun, er selber behauptet von sich, das zu können. Und tatsächlich läuft 
auch die AVX2-Variante des ASTC-Encoders problemlos.
Könnte aber natürlich sein, dass ich beim Auslesen der Feature-Flags was 
falsch gemacht habe und der ASTC-Encoder ein Fallback hat. Guter 
Hinweis, da werde ich wohl nochmal ein wenig nachprüfen müssen.

Obwohl: Selbst wenn nur Fallback, ist es trotzdem locker schnell genug 
für meine Zwecke. Wechsel der Qualitätsstufe einer 800x480-Grafik dauert 
(inclusive der Decodierung des neuen Vorschaubilds und kompletter 
Aktualisierung des GUI) nur ca. 1/10 Sekunde. Damit kann ich gut leben.

> c-hater schrieb:
>> Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes
>> Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings
>> sehr viel komfortabler als das Original. Vor allem im Bezug auf einen
>> AVR8-Host als Zielsystem...

> Und seit den BT815 erzeuge ich Flash Images mit dem EAB und übertrage
> die damit.

Ich lade den Kram immer vom Host hoch. Entweder liegt er im Flash des 
Hosts (wenn dort genug Platz ist) oder es kommt von einer an den Host 
angebundenen SD-Karte. Sehr praktisch für Updates.

Genau dazu, beide Varianten schön einfach "packagen" zu können, dient im 
Wesentlichen der Komfort meines eigenen Asset-Builders. Das einzige, was 
bei der Entwicklung noch ein wenig nervt, ist das Hin- und Herstecken 
der SD-Karte. Dafür baue ich aber auch gerade an einer Lösung, bei der 
der Entwicklungsrechner für das Zielsystem eine virtuelle SD-Karte (und 
einen virtuellen Reset-Button über deren CD-Signal) bereitstellt.

von c-hater (Gast)


Lesenswert?

c-hater schrieb:

> Könnte aber natürlich sein, dass ich beim Auslesen der Feature-Flags was
> falsch gemacht habe

So war es tatsächlich. Der E8500 kann nichtmal AVX, geschweige denn 
AVX2.

> und der ASTC-Encoder ein Fallback hat.

Was damit wohl nachgewiesen ist.

von Rudolph R. (rudolph)


Lesenswert?

c-hater schrieb:
>> und der ASTC-Encoder ein Fallback hat.
>
> Was damit wohl nachgewiesen ist.

Ich habe das gerade noch mal ausprobiert, mit dem EAB 2.2 wird eine 
"astcenc.exe" ausgeliefert die sich so meldet:
ASTC codec v2.1, 64-bit avx2+popcnt
Copyright 2011-2020 Arm Limited, all rights reserved

Und damit bekomme ich in EAB das hier als Fehler: 
ASTCENC_ERR_BAD_CPU_ISA

Also auf meiner geringfügig frischeren CPU von AMD gibt es da kein 
Fallback.
Mit der aktuellen v2.5 auch nicht.

Da die SSE4.1 Version alles andere als langsam ist wäre es wohl schlauer 
das nächste offizielle Archiv damit auszuliefern.

Wir Zeit aufzurüsten, aber Zen4 mit DDR5 ist auch schon am Horizont zu 
sehen. :-)

von Johannes (Gast)


Lesenswert?

Hallo,

hat mal jemand die Library mit einem RVT70xQB getestet?

Habe hier mal an einer laufende Applikation, die bisher NHD70 nutzte ein 
RVT70AQBNWC00 angeschlossen und die Display-Defines geändert. Trotz 
gutem timing (DL <100us) flackert das Display alle paar Sekunden. Es 
wird dann für ein paar Millisekunden dunkel und kommt dannach wieder.

Der Touch funktioniert auch nur gelegentlich...

Gruß,
Johannes

von Johannes (Gast)


Lesenswert?

Kleine Ergänzung: Das Display blitzt im 2-Skunden-Takt sobald ein Button 
in der DL enthalten ist. Eine DL mit Bitmap, Slider und ein paar Texten 
verhält sich normal.

von Rudolph R. (rudolph)


Lesenswert?

Also zumindest das RVT50AQBNWC00 habe ich selber schon benutzt in einem 
Projekt, das ist ja praktisch das gleiche, nur eben kleiner.
Der einzige Unterschied elektrisch ist, das RVT70 braucht mehr Strom.

Wie versorgst Du das Ding denn? Und wie viel Strom verträgt die 
Versorgung?

: Bearbeitet durch User
von Johannes (Gast)


Lesenswert?

Hängt hinter einem TS2596 der 5V macht für die BL und dann ein TS9013 
der 3,3V macht. Spannungen passen und der Low-Drop-Regler wird so nur 
handwarm.

von Rudolph R. (rudolph)


Lesenswert?

Johannes schrieb:
> Hängt hinter einem TS2596 der 5V macht für die BL und dann ein TS9013
> der 3,3V macht. Spannungen passen und der Low-Drop-Regler wird so nur
> handwarm

Okay, wenn die richtig funktionieren sollte das reichen.
Blöderweise hat Riverdi keine vernünftigen Daten, für die 3,3V muss man 
bei der Größe mindestens 200mA vorhalten.
Und für die Beleuchtung so um die 300mA bei 5V.

Wie sieht der Rest zum Display aus?
Und zeigt mal bitte etwas Testcode der nicht funktioniert.

von Johannes (Gast)


Lesenswert?

Problem gelöst. Die DL wurde zu schnell geladen. 20ms Wiederholrate 
scheinen einen Hauch zu schnell zu sein. Bei 25ms funktioneirt alles 
problemlos.

von Rudolph R. (rudolph)


Lesenswert?

Johannes schrieb:
> Problem gelöst. Die DL wurde zu schnell geladen. 20ms Wiederholrate
> scheinen einen Hauch zu schnell zu sein. Bei 25ms funktioneirt alles
> problemlos.

Dann stimmt aber was nicht, mit den Parametern die ich für das Display 
in die EVE_config geschrieben habe, zusammen mit dem Takt für den BT815 
von 72MHz sollte das eigentlich einen Refresh von schlapp 65Hz ergeben.
Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?
Oder sind die 20ms gar keine 20ms?

Die EVE_RVT70 Konfiguration wäre zum Beispiel für ein RVT70AQFNWC00, 
also EVE2 / FT813, damit sollten sich 54Hz ergeben.
Und mit RVT70UQFNWC00 habe ich das auch im Einsatz bei 20ms.

von Daniel S. (snipod)


Angehängte Dateien:

Lesenswert?

Hi Rudolph,
also zuerst mal vielen Dank für die Grandiose Hilfe mal wieder :)

ich habe meine Fonts aus dem Legacy Format auf ASTC umgestellt und das 
funktioniert tip top, auch mit Sonderzeichen.

Zu der Konvertierungsdauer kann ich nur sagen, dass ich es fast nicht 
mitbekomme, dass er überhaupt konvertiert. Es dauert vielleicht eine 
Sekunde und das auf einer - nicht wirklich aktuellen - CPU (AMD Ryzen 7 
1700X)


Nun aber zu einem neuen Problem:
Ich kämpfe mit falsch detektierten Touch punkten - und zwar nur, wenn 
ich im oberen rechten Bildschirmrand etwas anzeige... sehr komisch
Ich zeige auf meinem Screen ein Smartphone-Inspiriertes Menu an:

meine Touchausgabe (zuerst die 5 Tags, dann RawX und RawY) sieht dann 
wie folgt aus:
1
I (67548) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 199 0x  27
2
I (68398) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16
3
I (68403) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16
4
I (68408) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16
5
I (68413) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16

also die Anzahl an falschen Touch Ereignissen ist vertretbar -> erster 
Touch bei 67548, dann drei falsche - naja OK, dann bei 68413 der zweite 
richtige.

Wenn ich das Menü jetzt aber wieder mit Leben Fülle, rastet der Touch 
Controller anscheinend komplett aus, bis er zufällig irgendwas trifft, 
was das Menü wieder ausblendet:
1
I (6433) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 191 0x  1F
2
I (6518) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
3
I (6523) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
4
I (6528) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
5
I (6533) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
6
I (6538) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2FB
7
I (6543) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2FB
8
I (6668) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
9
I (6673) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
10
I (6678) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
11
I (6683) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
12
I (6688) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
13
I (6693) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
14
I (6698) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A3 0x 232
15
I (6704) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A3 0x 232
16
I (6765) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
17
I (6770) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
18
I (6775) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
19
I (6780) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
20
I (7140) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
21
I (7145) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
22
I (7150) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
23
I (7155) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
24
I (7160) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
25
I (7165) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
26
I (7170) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
27
I (7176) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x 1DE
28
I (7182) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x 1DE
29
I (7188) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  41 0x 1E6
30
I (7194) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4D 0x 213
31
I (7200) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4D 0x 213
32
I (7496) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
33
I (7501) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
34
I (7506) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
35
I (7511) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
36
I (7516) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
37
I (7801) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
38
I (7806) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
39
I (7811) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
40
I (7816) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
41
I (7821) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
42
I (7826) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
43
I (7831) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 254
44
I (7837) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 254
45
I (7843) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  B7 0x 264
46
I (7849) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  B7 0x 264
47
I (7855) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 125 0x 288
48
I (7861) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 125 0x 288
49
I (7867) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 194 0x 2A9
50
I (7873) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 2A0
51
I (7879) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 2A0
52
I (8060) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
53
I (8065) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
54
I (8070) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
55
I (8075) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
56
I (8480) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
57
I (8485) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
58
I (8490) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
59
I (8495) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
60
I (8500) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  48 0x 1F7
61
I (8505) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  48 0x 1F7
62
I (8855) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
63
I (8860) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
64
I (8865) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
65
I (8870) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
66
I (8875) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  55 0x 19D
67
I (8880) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  55 0x 19D
68
I (8885) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  55 0x 19D
69
I (8966) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
70
I (8971) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
71
I (8976) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
72
I (8981) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
73
I (9256) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
74
I (9261) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
75
I (9266) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
76
I (9271) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
77
I (9331) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
78
I (9336) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
79
I (9341) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
80
I (9346) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
81
I (9621) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
82
I (9626) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
83
I (9631) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
84
I (9636) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
85
I (9641) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
86
I (9646) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
87
I (9651) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
88
I (9657) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 142 0x 27C
89
I (9663) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 16E 0x 286
90
I (9669) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 16E 0x 286
91
I (9675) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 199 0x 291
92
I (9681) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 199 0x 291
93
I (9687) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19E 0x 28A
94
I (9693) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19E 0x 28A
95
I (9699) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 27C
96
I (9705) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 26F
97
I (9711) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 26F
98
I (9717) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 195 0x 28B
99
I (9723) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 195 0x 28B
100
I (9729) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 194 0x 2A7
101
I (9735) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 194 0x 2A7
102
I (9741) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 192 0x 2AE
103
I (9747) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 192 0x 2AE
104
I (9753) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 16B 0x 252
105
I (9759) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  FE 0x 1F8
106
I (9765) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  FE 0x 1F8
107
I (9770) Touch: 0xF2 0x 0 0x 0 0x 0 0x 0 - 0x  92 0x 1D6
108
I (9776) Touch: 0xF2 0x 0 0x 0 0x 0 0x 0 - 0x  92 0x 1D6
109
I (9782) Touch: 0xF2 0x 0 0x 0 0x 0 0x 0 - 0x8000 0x8000
110
I (11324) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
111
I (11329) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
112
I (11334) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
113
I (11339) Touch: 0x 1 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
114
I (12034) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
115
I (12040) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
116
I (12045) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
117
I (12050) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
118
I (12055) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
119
I (12060) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
120
I (12065) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
121
I (12070) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
122
I (12076) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
123
I (12082) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
124
I (12089) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
125
I (12095) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
126
I (12101) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
127
I (12812) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
128
I (12817) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
129
I (12822) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
130
I (12827) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
131
I (12832) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
132
I (12837) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
133
I (12842) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
134
I (12849) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
135
I (12854) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
136
I (12860) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
137
I (12867) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
138
I (12873) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
139
I (12879) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
140
I (12885) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
141
I (12891) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
142
I (12897) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
143
I (12903) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
144
I (12910) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
145
I (12915) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
146
I (14061) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
147
I (14066) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
148
I (14071) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
149
I (14076) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
150
I (14511) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
151
I (14516) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
152
I (14521) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
153
I (14526) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
154
I (14531) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
155
I (16887) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC
156
I (16892) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC
157
I (16897) Touch: 0xF3 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC
158
I (16902) Touch: 0xF3 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC

Jemand eine Idee was da los ist und was ich dagegen tun kann?

von Rudolph R. (rudolph)


Lesenswert?

Wie schnell ist der SPI?
Probier den mal während der Touch-Phase auf eine kleinere Frequenz zu 
stellen.
Wenn Du einen Logic-Analyzer hast welcher problemlos den Takt auf dem 
SPI mitmacht, dann zieh mal einen Trace davon.

Das kann gut sein, dass der SPI zu schnell ist um sauber zu lesen.
Wenn ich hier den Takt zu hoch drehe kommt ab so 15Mhz Datenmüll zurück,
Schreiben geht deutlich schneller, CLK und MOSI kommen ja zusammen an.

von Rudolph R. (rudolph)


Lesenswert?

Ok, time to try something new. :-)
https://github.com/RudolphRiedel/FT800-FT813/discussions

This might be the place to ask if for example the well moderated BRT 
forum is not your thing or if for example the Matrix Orbital forum is 
not apropriate since you module is from a different manufacturer.
And this here is only one thread afterall.

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


Lesenswert?

Mein bescheidener Beitrag dazu, vielleicht hilft's: Ich hatte ja gerade 
vor ein paar Wochen von meinem Problem mit dem C-Touch berichtet, dass 
immer wieder falsche Koordinaten abgeholt wurden. Die Empfindlichkeit 
des Touch ist dann einfach zu hoch. Sie ist ausgelegt dafür, das Display 
mit einer Glasscheibe zu betreiben. Im Datenblatt des Display sollte 
stehen, wie man das ändern kann. Aber eine große Hilfe ist bereits, die 
Applikation zu erden (Schutzleiter an Masse), bzw. ein entspr. Netzteil 
zu verwenden, dass den Schutzleiter auf Minus durchschleift (die meißten 
China-Netzteile haben ja nicht einmal einen Schutzleiter-Anschluss).

Ich arbeite seit einigen Jahren mit dem FT8xx, seit ca. 2 Jahren mit dem 
FT813. Habe schon recht beachtliche Oberflächen NUR mit den 
"Primitives-Befehlen" gezaubert. Nun aber rufen die Kunden nach 
"schöneren" Grafiken und nach Bitmaps. Rudi, Du sollst es nicht glauben, 
aber ich beginne JETZT den Co-Prozessor einzusetzen. Und da beginnt nun 
mein Problem. Ich bin am Verzweifeln, wälze das Datenblatt von vorn bis 
hinten und verstehe es nicht. Ich bekomme es nicht einmal hin, das 
FTDi-Demo (CMD_Logo) zu laden. Kannst Du mir bitte, bitte in 
"Echtworten" sagen, was ich an welche Adresse senden muss? Ich bin hier 
am "wilden" Probieren. Was übersehe ich da?
Ist es vielleicht genauso einfach (wenn man es denn einmal begriffen 
hat):
Ram_CMD ab Hx308000 setzen (hier auch nach jedem Befehl + 4 ???) gefolgt 
von  HxFFFFFF00 für "CMD_DLSTART". Dann Hx308004 (?) gefolgt von 
CMD_Logo. Wie beenden? Einfach nur Hx3080xx gefolgt von CMD_SWAP ???

von Rudolph R. (rudolph)


Lesenswert?

Das steht in Kapitel 5 vom Programming Guide.

Ich benutze ja in meiner Libray von Anfang an exklusiv nur den 
Co-Prozessor.
Und da gibt es zwei Wege, entweder man schreibt in RAM_CMD und muss 
dabei die ganze Zeit zum Beispiel in einem Offset-Zähler mitrechnen was 
man so geschrieben hat, am Ende schreibt man dann den Wert in 
REG_CMD_WRITE.
Direkt nach Reset stehen REG_CMD_READ und REG_CMD_WRITE auf 0.
Dann schreibt man sagen wir mal 20 Bytes, setzt REG_CMD_WRITE auf 20 und 
was zwischen 0 und 20 steht wird ausgeführt.
Wenn REG_CMD_READ auch 20 hat ist der Co-Prozessor fertig.
Dann geht es ab 20 weiter.
Wenn man in RAM_CMD schreibt gibt es 4096 automatisch einen Überlauf und 
es wird wieder auf Adresse Null geschrieben.
Diesen Überlauf muss man mit im Offset berücksichtigen.

Das ist der "alte" Weg, das ist mit den FT80x kompatibel und das habe 
ich bis Version 4 von meiner Library auch so gemacht.
https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/EVE_commands.c
EVE_begin_cmd() + EVE_inc_cmdoffset()

Mit den FT81x wurden neue Register eingeführt, REG_CMDB_WRITE und 
REG_CMDB_SPACE.
Wenn man ein 32 Bit Wort in REG_CMDB_WRITE schreibt, dann landet das an 
der nächsten freien Position von RAM_CMD und mit jedem weiteren 
Schreiben in REG_CMDB_WRITE wird auch immer wieder an die nächste 
Adresse geschrieben.
Wenn man mit Schreiben aufhört wird REG_CMD_WRITE automatisch gesetzt 
und ausgeführt was in RAM_CMD ist.
Den Offset nicht mitzurechnen spart einiges an Zeit, ist aber nicht
mehr mit den FT80x kompatibel.
Das habe ich in der aktuellen Version 5 umgesetzt.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_commands.c
eve_begin_cmd()

von Daniel S. (snipod)


Lesenswert?

Bernd I. schrieb:
> Mein bescheidener Beitrag dazu, vielleicht hilft's: Ich hatte ja gerade
> vor ein paar Wochen von meinem Problem mit dem C-Touch berichtet, dass
> immer wieder falsche Koordinaten abgeholt wurden. Die Empfindlichkeit
> des Touch ist dann einfach zu hoch. Sie ist ausgelegt dafür, das Display
> mit einer Glasscheibe zu betreiben. Im Datenblatt des Display sollte
> stehen, wie man das ändern kann. Aber eine große Hilfe ist bereits, die
> Applikation zu erden (Schutzleiter an Masse), bzw. ein entspr. Netzteil
> zu verwenden, dass den Schutzleiter auf Minus durchschleift (die meißten
> China-Netzteile haben ja nicht einmal einen Schutzleiter-Anschluss).

Hi,
danke für den Input, aber das war tatsächlich nicht mein Problem.

Mein Problem liegt hier begraben:
1
        EVE_cmd_dl_burst(COLOR_A(0));
2
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
3
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
4
        EVE_cmd_dl_burst(VERTEX2F(menuXPos - 10, HEADER_HEIGHT + 1));
5
        EVE_cmd_dl_burst(VERTEX2F(menuXPos - 1, menuHeightYMax));
6
        EVE_cmd_dl_burst(DL_END);
7
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 1));
8
        EVE_cmd_gradienta_burst(188, HEADER_HEIGHT, 0UL, menuXPos, HEADER_HEIGHT, 0x64000000);
9
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));

sobald ich diesen Schatten mit hinzu nehme, rastet der Touch so aus. 
Ohne, läuft er perfekt. Setze ich hier etwas nicht richtig zurück was 
den Stencil angeht? Allerdings sollte das ja keine Auswirkungen auf den 
Touch haben... Oder ist es wohlmöglich doch ein Firmware-Bug im EVE?

Ich könnte noch mal den Logic Analyzer dranhängen, ich habe eine Logic 
Pro 8, der sollte den Takt schon mitmachen... Dafür müsste ich aber 
wieder Kabel an meine Platine löten, weil ich mal wieder vergessen habe, 
mir den Bus auf Testpunkte zu legen... Ich kann mir aber nicht 
vorstellen, dass bei ca. 96mm Leiterbahnlänge zwischen dem Controller 
und dem EVE es da Probleme gibt bei 40 MHz. Laut Eagle besitzen die 
Traces eine maximale Frequenz weit über 3 GHz.

Falls Ihr unabhängig meiner Beobachtung doch weiter den SPI verdächtigt, 
kann ich entweder die BUS-Geschwindigkeit drosseln, oder doch mal den 
Logic Analyzer anlöten...

Viele Grüße

von Rudolph (Gast)


Lesenswert?

Daniel S. schrieb:
> Mein Problem liegt hier begraben:
>  EVE_cmd_dl_burst(COLOR_A(0));
> ...

Ok, sowas habe ich noch nicht probiert, muss ich mir mal ansehen.
Wenn das die Ursache ist, bitte mal an Bridgetek melden.

Daniel S. schrieb:
>Ich kann mir aber nicht vorstellen, dass bei ca. 96mm Leiterbahnlänge
>zwischen dem Controller und dem EVE es da Probleme gibt bei 40 MHz.

Abgesehen davon, dass der maximale Takt für EVE mit 30MHz angegeben ist 
und es auch darauf ankommt was in den Leitungen, neben den Leitungen und 
unter den Leitungen noch so liegt, dreh doch einfach mal den Takt auf 
8MHz runter und schau was passiert. :-)
Ich weiß halt aus Beobachtung, dass zumindest im meinem Aufbau Senden 
deutlich schneller noch funktioniert als Lesen.
In einem Test konnte ich bis 17MHz noch sauber lesen, aber bis 40MHz 
Schreiben.
Mit einem anderen Controller waren es 12MHz und 35MHz.

>Laut Eagle besitzen die Traces eine maximale Frequenz weit über 3 GHz.

Da habe ich so leichte Zweifel dran, bei 20MHz verfälschen ein paar pF 
schon gut die Messung, das wird zunehmend analog. Und dann müssen beide 
Seiten die Leitungen auch schnell genug treiben können was EAGLE wohl 
eher nicht berücksichtigen wird.

von Johannes (Gast)


Lesenswert?

Rudolph R. schrieb:
> Dann stimmt aber was nicht, mit den Parametern die ich für das Display
> in die EVE_config geschrieben habe, zusammen mit dem Takt für den BT815
> von 72MHz sollte das eigentlich einen Refresh von schlapp 65Hz ergeben.
> Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?
> Oder sind die 20ms gar keine 20ms?

Hi Rudolph,

der 5ms Tick ist exakt 5ms lang. Nutze einen SAMC/D auf 48 MHz. der SPI 
läuft auf 12 MHz.

Welche Parameter könnten denn angepasst werden müssen?

Johannes

von Rudolph (Gast)


Lesenswert?

Johannes schrieb:
>> Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?
>> Oder sind die 20ms gar keine 20ms?
>
> Hi Rudolph,
>
> der 5ms Tick ist exakt 5ms lang. Nutze einen SAMC/D auf 48 MHz. der SPI
> läuft auf 12 MHz.
>
> Welche Parameter könnten denn angepasst werden müssen?

Schau mal in die EVE_config.h ob da wirklich EVE_RiTFT70 aktiv ist.

von Johannes (Gast)


Lesenswert?

Ja, ist wirklich die RiTFT70.

von Rudolph (Gast)


Lesenswert?

Tja, seltsam, vor allem habe ich die EVE_RiTFT50 Einstellung selber 
schon so benutzt, die ist ja mit der EVE_RiTFT70 identisch.

Muss ich mal auf dem Schreibtisch kramen, ein RVT50UQBNWC01 habe ich ja 
und eine Platine mit ATSAMC21 auf 48MHz.
Das lief soweit alles.


Und ohne Bezug, ich hatte vor einiger Zeit ein RVT101HVBNWC00-B 
bestellt, das ist jetzt unterwegs, ich werde berichten. :-)

von Rudolph R. (rudolph)


Lesenswert?

Na toll, FedEx hat das Paket nicht geliefert und im Tracking steht immer 
noch: "Voraussichtlicher Zustelltermin: Freitag, 28. Mai 2021 bis Ende 
des Tages"
Also frühestens am Montag, danke FedEx mir so das WE zu versauen.


Das RVT50UQBNWC01 läuft übrigens einwandfrei auf 20ms mit meinem 
ATSAMC21 Board, nur auf 15ms spinnt der Touch.
Aber das Timing von Display liegt auch bei 15,3ms, also sind 15ms 
schlicht zu schnell.

von Spyy (Gast)


Lesenswert?

Hallo Rudolph,

so nach langer Zeit komme ich mal wieder zu meinem Projekt...

Ich habe mal das hier in die EVE_Init() Routine geschrieben:

  // Write the EVE stats:
  uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
  delay(1000);
  uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
  Serial.print("EVE clock: ");
  Serial.println(eveClockNew - eveClockOld);

Ich lese einfach zweimal im Abstand von 1 Sekunde das CLOCK Register. 
Meine Erwartung wäre, dass ich dann so ein Wert vom 72000000 bekommen 
werde, da ich ja das hier geschrieben habe:
EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
Ich bekomme aber das hier:

Eve init...
EVE PCLK Frequency: 48000000
EVE clock: 34667018

Was bekommst Du für einen Wert, wenn Du das bei Dir machst ?

von Spyy (Gast)


Lesenswert?

REG_CLOCK geht auch, das ist einfach nur ein 32-Bit Zähler der mit
Systemtakt läuft. => siehe letztes Posting

Und Du könntest mal die kompletten Timing-Werte für das Display über den
Zaun reichen.
#if defined (EVE_EVE4_ISFD)
#define Resolution_480x480

#define EVE_HSIZE  (480L)
#define EVE_VSIZE  (480L)
#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (20L)
#define EVE_VOFFSET  (20L)
#define EVE_VCYCLE  (518L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (41L)
#define EVE_HOFFSET  (43L)
#define EVE_HCYCLE   (548L)
#define EVE_PCLK  (1L)
#define EVE_PCLKPOL  (1L)
#define EVE_SWIZZLE  (0L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (1800L)
#define EVE_GEN 4

Ich verwende dieses Display hier:
https://www.buydisplay.com/4-inch-tft-lcd-display-480x480-pixel-with-mipi-interface-for-iot-devices

von Rudolph R. (rudolph)


Lesenswert?

Spyy schrieb:
> Was bekommst Du für einen Wert, wenn Du das bei Dir machst ?

Ich habe nur den Systick-Timer und kein exaktes delay().
Also lese ich alle 200 * 5ms REG_CLOCK und lasse mir die Differenz
zu dem alten Wert anzeigen.

Das sind 72001711 mit einem ATSAMC21 und einem BT815.
Die Abweichung kommt jetzt entweder von meinem Quarz oder dem Quarz auf 
dem Display oder beiden.

Wenn ich das auf REG_FRAMES umstelle bekomme ich 65.

Spyy schrieb:
> Und Du könntest mal die kompletten Timing-Werte für das Display über den
> Zaun reichen.
> #if defined (EVE_EVE4_ISFD)
> #define EVE_VCYCLE  (518L)
> #define EVE_HCYCLE   (548L)
> #define EVE_PCLK  (1L)
#define EVE_GEN 4

Entscheidung für die Bildrate sind diese Werte.
Wenn Du einen BT817 / BT818 mit PCLK = 1 betreibst, dann nutzt der die 
zweite PLL.
Und wenn das Define für EVE_PCLK_FREQ nicht da ist lässt mein Code den 
Default-Wert drin, das sind 60MHz.
Also mit den Werten hast Du einen Pixel-Clock von 60MHz was in einer 
Bildrate von 211 HZ resultiert und etwas außerhalb der Spec liegen 
dürfte.

Probiere es mal mit PCLK = 4, damit wird die zweite PLL nicht verwendet 
und mit den dann geteilten 72MHz sind es 63,4Hz.
Oder mit PCLK = 1 und PCLK_FREQ = 17000000 wären es 59,89Hz, der Aufwand 
lohnt sich wohl aber eher nicht.

Wo kommen die Timing-Werte her? In dem "Datenblatt" von der Webseite 
habe ich die nicht gefunden.

von Spyy (Gast)


Lesenswert?

Rudolph R. schrieb:
> Probiere es mal mit PCLK = 4, damit wird die zweite PLL nicht verwendet
> und mit den dann geteilten 72MHz sind es 63,4Hz.
> Oder mit PCLK = 1 und PCLK_FREQ = 17000000 wären es 59,89Hz, der Aufwand
> lohnt sich wohl aber eher nicht.

Ok habe ich gemacht (PCLK = 4) bekomme dann:

EVE clock: 34661499
EVE frames: 31

=> Irgendwie ist bei mir alles "durch 2" geteilt...31 * 2 => 62Hz


???? wo liegt der Fehler ? Ich habe keinen externen Quarz dran...???

Uff...Sch****e

von Spyy (Gast)


Lesenswert?

und wenn ich in das Register gar nix reinschreibe
  #if EVE_GEN > 2
  //EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
  #endif
=> laut Datenblatt dann default => 60 Mhz
bekomme ich das hier:
EVE clock: 28931524


Also 29 Mhz und mit

von Rudolph R. (rudolph)


Lesenswert?

Wo hast Du keinen externen Quarz dran?
An dem BT817/BT818?
Dann wird ja einfach nur der interne RC-Oszillator verwendet, der hat 
auch 12Mhz. Der ist nur nicht unbedingt so präzise oder 
temperatur-stabil wie ein Quarz oder Resonator.

Wenn ich in dem EVE_RiTFT50 Profil das EVE_HAS_CRYSTAL auskommentiere 
dann komme ich immer noch auf 65Hz.
Aber die Anzeige für den Takt ändert sich jede Sekunde.
72077473
72093395
72077258
72066016
72101521

Jetzt nicht in der Reihenfolge.

Mit Quarz ändern sich höchstens mal die letzten zwei Stellen
72001727
72001719
72001734
72001727
72001726

Da würde ich dann aber eher vermuten das die Sekunde Mess-Intervall auch 
mal ein paar Taktzyklen mehr oder weniger haben kann.

von Rudolph R. (rudolph)


Lesenswert?

Spyy schrieb:
> => laut Datenblatt dann default => 60 Mhz
> bekomme ich das hier:
> EVE clock: 28931524
>
> Also 29 Mhz und mit

Du misst nicht einmal pro Sekunde, sondern zwei Mal?

von Spyy (Gast)


Lesenswert?

Ich habe zu früh auf senden gedrückt...

Ich messe so:
  // Write the EVE stats:
  uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
  delay(1000);
  uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
  Serial.print("EVE clock: ");
  Serial.println(eveClockNew - eveClockOld);

Also Wert lesen dann eine Sekunde warten dann nochmal lesen und 
voneinander abziehen...

Wie auch schon gesagt die Messergebnisse spiegeln auch das reale 
Verhalten wieder...bekomme immer nur 1/2 Framerate und bei ca. 25 ms 
Schreibzyklen Probleme mit der Displaylist..
und das delay(1000) sind wirklich 1 Sekunde...

von Rudolph (Gast)


Lesenswert?

Dazu fällt mir jetzt nicht mehr wirklich was ein.

Miss das mal nachdem die EVE_init() durch ist, packe noch ein 
delay(1000) vor das erste Lesen des Registers und ziehe mal einen Trace 
davon mit dem Logic-Analyzer.

von Spyy (Gast)


Lesenswert?

Ja mir leider auch nicht....aber...

Wenn ich das hier eintrage:
EVE_cmdWrite(EVE_CLKSEL,0x10);

bekomme ich das hier:
EVE PCLK Frequency: 60000000
EVE clock: 72306594
EVE frames: 102

ach so: Ich habe den BT818....also den neuen

Ich glaube das mit dem CLKSEL funktioniert nicht richtig...wenn ich da 
0x00 eintrage bekomme ich keine 60 Mhz....
Erst wenn ich im hohen "nibble" ne 1 eintrage bekomme ich 72

Keine Ahnung, ich habe mal im BRT Forum die Frage gestellt...mal 
sehen...

von Rudolph (Gast)


Lesenswert?

Kannst Du das mit was anderem als dem Teensy ausprobieren?
Etwa mit einem Arduino Uno?

Die Frage wurde im BRT Forum ja schon das letzte Mal nicht wirklich 
beantwortet.
Und die Antwort fand ich jetzt nicht direkt hilfreich.

Vielleicht sollte ich mir mal einen Teensy 4 zulegen.

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


Lesenswert?

Vielen Dank für die Erklärungen zum Co_Prozessor. Das alles, was ab 
Kapitel 5 steht habe ich natürlich auch schon gelesen. Ich nutze auch 
nur noch den FT813, also was mal war, interessiert mich demzufolge auch 
nicht (mehr). Dennoch steht es im Programmer-Guide des FT813 noch so 
drin??!!!
Meine Frage nach KONKRET war ja diese:
Ich sende per SPI 7 Bytes:
Hx302574 (Reg_CMDB_Write) gefolgt von FF FF FF 31 (CMD_LOGO). Richtig? 
Blödsinn? Fertig?!?! Ich nehme an, auch hier muss das Register 
eigentlich mit HxB0.. (statt Hx30...) gesetzt werden, weil ja das erste 
Bit ein H sein muss.
Habe auch beides ausprobiert.
Das ist natürlich nicht das Einzigste, was ich seit Tagen immer wieder 
ausprobiere. Aber bisher geht es einfach nicht.
Einmal das grundlegende Prinzip...!!!! Ich denke schon, dass ich dann 
mit allen anderen Befehlen klar komme. Warum kann so etwas nicht im 
Datenblatt konkret drin stehen?

von Rudolph R. (rudolph)


Lesenswert?

Um per Reg_CMDB_Write das Kommando CMD_LOGO zu senden wäre diese Sequenz 
richtig:

0xb0 0x25 0x78 0x31 0xff 0xff 0xff

Aus mysteriösen Gründen ist nämlich die Byte-Order für die Adressen 
anders als für die Daten.

Das steht auch alles im Datenblatt und Programming Guide, das muss man 
nur erstmal finden.
Da bist Du nicht der Erste der darüber stolpert und ganz sicher nicht 
der Letzte.

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


Lesenswert?

Ich glaub das jetzt nicht!!!!!!!!!! Jetzt läuft tatsächlich die 
Logo-Animation ab!!!! Na vielen herzlichen Dank.

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Das RVT101HVBNWC00-B ist heute angekommen und funktioniert spontan. :-)

Die 10.1" sind schon heftig groß und das Panel ist derbe hell.
Mein Handy schaltet das Bild dunkler weil diese Leucht

Im Moment versorge ich das mit 9V über eine Verpolschutz-Diode.
Damit zieht das ganze System 360mA bei 25% (0x20) PWM für die 
Beleuchtung.

Edit: wenn ich die Beleuchtung abschalte zieht das System noch 185mA.
Mit so 10mA für die 5V Seite liefert der 3,3V Stepdown gerade so um 
500mA um das Display zu versorgen.

Die Hintergrund-Beleuchtung läuft gerade direkt mit den 9V (oder 8,xV 
nach der Diode) und davon werden noch 3,3V per Schaltregler für das 
Display und 5V per LDO für mein Controller-Board erzeugt.

Die nächsten Versionen von meinem Display-Adapter und Controller-Board 
mit Display-Anschluss werden wohl einen 9V Step-Down und einen 3,3V 
Stepdown haben.

Den Pixel-Clock habe ich von 72MHz auf 71MHz runter gedreht, sind immer 
noch 60 FPS, rechnerisch sollten das 58,58 FPS sein.
Das "Frequency" in der Anzeige ist der Takt mit dem der BT817 selber 
läuft.

Jetzt läuft erst mal der nächste Testdruck für das Gehäuse dazu - 5h.

Edit 2: ich musste die Hintergrundbeleuchtung auf 0x10 runter drehen, 
die Leuchtkachel ist mir am Schreibtisch echt zu heftig.
Das sind dann noch 270mA aus 9V.

: Bearbeitet durch User
von Spyy (Gast)


Lesenswert?

Rudolph schrieb:
> Vielleicht sollte ich mir mal einen Teensy 4 zulegen.

Unbedingt!!!! Ich habe hier noch einen liegen...würde ich Dir 
spendieren....

Die Antwort auf meine Frage im BRT 
Forum...ist...ja...etwas...ähm...naja...

von Rudolph (Gast)


Lesenswert?

Der Teensy 4.1 ist schon im Versand, das war die Gelegenheit mal wieder 
bei Reichelt zu bestellen. :-)

von Arnaud S. (arnsch)


Lesenswert?

Guten Tag,

Viele Danken für ihren Arbeit an diese Library ! Einschuldigung, mein 
Deutsch ist ein bisschen schwach, so ich will auf Englisch weiter 
schreiben.

I am currently working on the RiTFT-35-FR (BT816) from Riverdi with a 
Teensy 3.5 and your library.
I now have good results with the display, but still runs into somes 
issues.

As it could help someone, I will first give some infos about what I did 
and the issues I had:

1) I am having good results with the EVE_EVE3_35 configuration, and 
since it is marked as untested in EVE_config.h, I am sure you would be 
happy to know ;)

2) At first I could not display anything due to SPI transmissions errors 
using Teensy 3.5, while it was totally fine with an Arduino Nano.
I found that using terminating resistors on signals generated by Teensy 
(SCK and MOSI) solved this. Currently using 30 Ohms, but it seems the 
value depends on the length of the wires.
From what I read, it seems like a common issue while using SPI with a 
Teensy.

Now, I still sometimes encounter unstabilities while communicating with 
the BT816,
so I tried to lower the SPI clock frequency as much as I could, but I 
can't go below circa 500kHz...
What happens next is that I am still partially able to write and read 
registers, but nothing appears on the screen

I had better read/write performances by using TFT_init() at higher SPI 
speed, and then lowering it, but still nothing on the screen.
I verified the frequency with an oscilloscope, and everything seems 
fine.

Can't tell whether the BT816 or Teensy is the issue here.

Do you have any info on that ?

Guten Abend,

Arnaud

von Rudolph R. (rudolph)


Lesenswert?

Thank you and Englisch is just fine.
While updating all the different platforms in PlatformIO I checked the 
parameter sets for RiTFT-35 and EVE3-35 in my spreadsheet.
And while most of the parameters are the same or close enough,
a couple are not the same.
CLKPOL and SWIZZLE are different.
I'll check with the datasheet.
And as I also noticed now, there is no RiTFT-35 profile in EVE_config.h, 
yet.

Regarding the Teensy 3.5, did you add anything for it to EVE_target.h / 
EVE_target.c? Or are you just using the default Arduino target?

As so far with the Teensy 4.1, I can add it to the platformio.ini and 
check if it compiles, but I can not test it.
Which pins are you using for what?

von Rudolph R. (rudolph)


Lesenswert?

I just added 
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO 
as a first step.

The platformio.ini has a teensy35 target and while it already build with 
the default Arduino setup I went ahead and changed EVE_target.h and 
EVE_target.cpp to put ARDUINO_TEENSY35 on the same target as 
ARDUINO_TEENSY41 which should enable DMA.

And of course EVE_config.h has a profile for RiTFT35 now.

Please test.


For some strange reason the nucleo_f446re target no longer builds after 
I updated the platform to the latest version.


----
Processing nucleo_f446re (platform: ststm32; board: nucleo_f446re; 
framework: arduino)
------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
---------------------------------------------Verbose  mode can be 
enabled via `-v, --verbose` option
CONFIGURATION: 
https://docs.platformio.org/page/boards/ststm32/nucleo_f446re.html
PLATFORM: ST STM32 (14.0.0) > ST Nucleo F446RE
HARDWARE: STM32F446RET6 180MHz, 128KB RAM, 512KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, 
cmsis-dap, jlink)
PACKAGES:
 - framework-arduinoststm32 4.20000.210601 (2.0.0)
 - framework-cmsis 2.50700.210515 (5.7.0)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
Converting src.ino
ImportError: cannot import name 'IS_WINDOWS' from 'platformio.compat' 
(c:\users\ich\.platformio\penv\lib\site-packages\platformio\compat.py):
  File 
"C:\users\ich\.platformio\penv\lib\site-packages\platformio\builder\main 
.py",  line 177:
    env.SConscript("$BUILD_SCRIPT")
  File 
"C:\Users\Ich\.platformio\packages\tool-scons\scons-local-4.1.0\SCons\Sc 
ript\SConscript.py",  line 591:
    return _SConscript(self.fs, *files, **subst_kw)
  File 
"C:\Users\Ich\.platformio\packages\tool-scons\scons-local-4.1.0\SCons\Sc 
ript\SConscript.py",  line 280:
    exec(compile(scriptdata, scriptname, 'exec'), 
call_stack[-1].globals)
...
----

Whatever, not my fault, nothing I did there, I hope this gets fixed.

von Spyy (Gast)


Lesenswert?

Rudolph schrieb:
> Der Teensy 4.1 ist schon im Versand

Ok...super, wäre schön wenn Du von Deinen Erfahrungen hier berichten 
könntest. Aus dem Beitrag von Amaut könnte man ja auch schliessen, das 
es hier ein Problem gibt...

@Amout: The resistor of 30Ω you are using is connected in serial to the 
signal line or signal to ground?

von Rudolph R. (rudolph)


Lesenswert?

I am using one of these with all the third-party boards:
https://github.com/RudolphRiedel/EVE_display-adapter

von Arnaud S. (arnsch)


Lesenswert?

Rudolph R. schrieb:
> Regarding the Teensy 3.5, did you add anything for it to EVE_target.h /
> EVE_target.c? Or are you just using the default Arduino target?

I was using the default Arduino target, and changed a few pin 
definitions to suit my needs:
- PDN changed from 8 to 9
- CS changed from 9 to 10
- SPI Clock Output changed from 13 to 14 (specific to Teensy boards)

Rudolph R. schrieb:
> The platformio.ini has a teensy35 target and while it already build with
> the default Arduino setup I went ahead and changed EVE_target.h and
> EVE_target.cpp to put ARDUINO_TEENSY35 on the same target as
> ARDUINO_TEENSY41 which should enable DMA.
>
> And of course EVE_config.h has a profile for RiTFT35 now.
>
> Please test.

I implemented your changes into my code, and it seems to work.
First took the new screen profile, and then changes in EVE_target.cpp 
and EVE_target.h.
I can't confirm that I have better performances, but it seems to work as 
good as before.

Spyy schrieb:
> @Amout: The resistor of 30Ω you are using is connected in serial to the
> signal line or signal to ground?

I put those resistors in series to the signal line, and placed as close 
as possible to the source of the signal

von Rudolph (Gast)


Lesenswert?

Now I am mildly confused. :-)

What about:
>What happens next is that I am still partially able to write and read
>registers, but nothing appears on the screen
>
>I had better read/write performances by using TFT_init() at higher SPI
>speed, and then lowering it, but still nothing on the screen.

Does it display anything now?

>I can't confirm that I have better performances, but it seems to work as
>good as before.

Going from no output to no output would also mean it is "as good as 
before" :-)

>I was using the default Arduino target, and changed a few pin
>definitions to suit my needs:
>- PDN changed from 8 to 9
>- CS changed from 9 to 10
>- SPI Clock Output changed from 13 to 14 (specific to Teensy boards)

How can SCK0 be changed to pin 14?

Have you tried to directly run my simple demo?
CS is set to pin 9 now in line 1474 though.

I just checked https://www.pjrc.com/teensy/pinout.html
And according to this, SCK is on 13 for Teensy 3.5 and 4.1.
The several CS0 pins must be for Hardware-Controlled chip-select but I 
am directly using an I/O pin, CS = 10 and PDN = 9 is just fine.

What I really do not like about the Teensy, now that I have seen this, 
the SCK pin is not next to MISO and MOSI but on the opposite side.
And that there is a LED with a 470R resistor connected to SCK, looks 
like one of the first things I will do with the Teensy 4.1 is to remove 
the resistor as changing the pin for SCK0 does not seem to be an option.

von Arnaud S. (arnsch)


Lesenswert?

Rudolph schrieb:
> Going from no output to no output would also mean it is "as good as
> before" :-)

I should have been more precise about the results, sorry about that :D

It does display what I want on the screen (basically some static text 
with variables), but I still run into the SPI frequency issue : low 
frequency = no output. So I use 1MHz at the moment.

I also suffer from screen freezes after some time, and am currently 
investigating this... Do you have any recommendations for monitoring the 
screen status ?

SCK0 (and other SPI-involved pins) can be switched using 
SPI.setSCK(_pin_num) which is part of the SPI library, and works for all 
compatible alternate pins
(see https://www.pjrc.com/teensy/td_libs_SPI.html for more info)

Rudolph schrieb:
> Have you tried to directly run my simple demo?

I tweaked some parameters to fit my pin definitions, and it failed. I 
did not investigate any further for the moment. It is on my todolist, I 
can retry to do that tomorrow.

Rudolph schrieb:
> What I really do not like about the Teensy, now that I have seen this,
> the SCK pin is not next to MISO and MOSI but on the opposite side.
> And that there is a LED with a 470R resistor connected to SCK, looks
> like one of the first things I will do with the Teensy 4.1 is to remove
> the resistor as changing the pin for SCK0 does not seem to be an option.

I totally agree, it is quite a mess to use. And this LED is one of the 
reason I changed it to pin 14.

von Rudolph (Gast)


Lesenswert?

My Teensy 4.1 arrived so later I am doing some hands-on experiments with 
it. :-)

My basic demo shows the time it takes for a display-refresh:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg

That is without DMA.

https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/EVE2-50G_ATSAMC21.jpg

And this is with DMA.
The "Bytes" is the number of bytes sent for a display-refresh and 
without DMA this information is not available.

I am always using the same setup across platforms, my main.c or src.ino 
is executing the display functions in a 5ms intervall.
The touch and some debug-information is read every time.
The display-refresh is done every fourth time for 20ms refresh.

So the demo sends 224 bytes and the resulting display-list hast a length 
of 784 bytes, a little less without DMA.
The 51µs are not the time it takes to send 224 bytes, this is only the 
time the controller is busy preparing the DMA buffer.
At 8MHz the SPI is busy for annother 224µs, at 1MHz for annother 1,8ms.
And without DMA this takes longer since there are pauses between the 
bytes depending on the speed of the controller and the SPI 
implementation.

The touch-function is checking if a transfer is ongoing but if there 
would be more bytes to be send at a low speed the first thing that would 
happen is that the next reading of the touch events would be skipped.

So you need to keep an eye on the amount of bytes send, the resulting 
display-list needs to stay below 8k and the packets need to be 
transferred in time.
This is why I never put the logic-analyzer out of reach. :-)

von Spyy (Gast)


Lesenswert?

My Teensy 4.1 arrived so later I am doing some hands-on experiments with
it. :-) => Great!!!!

And if you have time can you please code this into the EVE_Init() near 
the end of function and report the results :)) with the setting 
EVE_cmdWrite(EVE_CLKSEL,0x46);

 Write the EVE stats:
  uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
  delay(1000);
  uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
  Serial.print("EVE clock: ");
  Serial.println(eveClockNew - eveClockOld);

Do you have a BT817 or a BT818 ?

von Spyy (Gast)


Lesenswert?

Arnaud S. schrieb:
> I also suffer from screen freezes after some time, and am currently
> investigating this

This is exacly the reason why i am struggling with my setup too...with 
Teensy 4.1

I am using:
-SPI: 20 Mhz
-DMA for SPI
-Pins: standard for SPI channel 0 (10, 11, 12, 13)
-Display list well below 8k (approx. 3700 bytes)
-Refresh rate of display 102 Hz


With 20 ms data refresh rate to BT818 it stalls immediately (SPI LED is 
full on display freezes), 21 ms works.
Tried to tweak the SPI speed to 10 Mhz or lower makes no difference

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

Well, what shall I say, there might be an issue with the hardware as it 
only started to work after I re-connected the Logic Analyzer.
It pretty much worked right out of the box including DMA.
I only changed CS to 10 and PD to 9.

I also tried a couple of different SPI speeds now, default is 8MHz, 
1/2/4/6 MHz work just fine albeit not necessary at the exact select 
frequency.
6MHz is more like 6.25MHz.
Increasing the speed after TFT_init() also works, 10/12/16/20 MHz, no 
issue.
Setting up 100MHz by accident did not work though. :-)
Going slower than 925kHz is not working in the sense that the Teensy 4.1 
will not clock the SPI any slower than that.
I tried 500k, 200k, now 800k, the result is 925kHz.
So well, there are limitations what the chip can do, not an issue.

Hmm, I just tried to disconnect the Logic Analyzer and I need to keep it 
connected to CS and SCK.
So I am left with a hardware issue in my setup and a couple of pF as 
extra load seem to fix it.

The "shadow" on the display or rather the brighter area is just a 
rolling shutter effect, I took three pictures with my phone and between 
these this is clearly mooving.

To confirm the Frequency and Frames/s measurement I just checked the 5ms 
intervall derived from millis() with the logic-analyzer and the first 
falling edge of CS from one block to annother.
And it is spot-on, 5,00032ms.
The is 64µs more every second if this is stable which at least partly 
accounts for the little more than 72000000.

Oh yes, before I even connected the Teensy 4.1 for the first time I 
removed the LED resistor R1.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

Ich habe jetzt auf das RVT101H gewechselt, 10,1", 1280x800, BT817.
Clock ist auf 20MHz hoch gedreht, CS und SCK sind immer noch mit dem 
Logik-Analzyer verbunden.

Spyy schrieb:
> And if you have time can you please code this into the EVE_Init() near
> the end of function and report the results :)) with the setting
> EVE_cmdWrite(EVE_CLKSEL,0x46);
>
>  Write the EVE stats:
>   uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
>   delay(1000);
>   uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
>   Serial.print("EVE clock: ");
>   Serial.println(eveClockNew - eveClockOld);

I changed it in tft.cpp like this:

uint32_t clock_test;

void TFT_init(void)
{
  if(EVE_init() != 0)
  {
    uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
    delay(1000);
    uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
    Serial.print("EVE clock: ");
    Serial.println(eveClockNew - eveClockOld);
    clock_test =  eveClockNew - eveClockOld;

It compiles, it uploads but I get nothing on the console.
Yes, I also added "Serial.begin(9600);" in src.ino.
So I added that var to print it on screen.

  EVE_cmd_text_var_burst(20, 160, 28, EVE_OPT_FORMAT, "Frequency: 
%d",1,clock_test);

The output of this line is: "Frequency: 72003042"
And the measurement I am taking every second now and printing it to the 
screen shows around 72002400.

von Arnaud S. (arnsch)


Angehängte Dateien:

Lesenswert?

So as promised, I retried your demo, only changed SPI SCK pin to 14, PDN 
and CS, and it worked ! (see demo_result.png).

But only for a rather short duration, after which I ran into the same 
issue as with my actual project : Screen freeze.
I began to monitor registers:
-CMD_READ and CMDB_SPACE to check if there was any issue with the 
commands we sent
-CPURESET to check if the chip was still running.

I am using USB Serial to directly read the values, which are read and 
sent every 500ms. Registers are read after display functions are 
executed.

And my observations are similar for both the demo code and my project:

Everything starts fine and screen is displaying what it should :
CMDB_SPACE = 4092 so RAM_CMD is empty and every commands have been 
executed

-CMD_READ != 0xFFF, so no coprocessor fault !
-CPURESET = 0, coprocessor is running

And then screen freeze,

-CMDB_SPACE != 4092 : RAM_CMD not empty
-CMD_READ != 0xFFF, still no coprocessor fault
-CPURESET = 0, coprocessor is still running

(see demo_registers_log.png : everything is fine for the first 4 
readings, using your demo code)

It is interesting to see that in the case of my project (not the demo, 
see own_project_OK.ng and ...NOK.png), CMDB_SPACE stays the same, and I 
am pretty sure that I am not sending any commands between registers 
readings*, so it seems the chip is not reading commands in RAM_CMD 
anymore.
But that is my own interpreatation, what do you guys think about this ?

*using if(!EVE_busy()) at the beginning of my display function to avoid 
that.

: Bearbeitet durch User
von Spyy (Gast)


Lesenswert?

1000 thanks for your effords!!!

Rudolph R. schrieb:
> The output of this line is: "Frequency: 72003042"

Boah....this is....what the helll...

Ok...the only difference to my setup is i am using a BT818 and no 
external chrystal...

von Spyy (Gast)


Lesenswert?

Arnaud S. schrieb:
> But that is my own interpreatation, what do you guys think about this ?

I have also no explenation for this...can you print out the clock 
frequency of your chip and the framerate of your screen?

The bahaviour of the registers before stalling here was the same you 
see...my feeling is the same, writings to the fifo stop or 
delays...whyever

I have SPI set to 20 Mhz, burst
LED to SCK still connected, standard pins 10, 11, 12,13
I have now 72 MHz with EVE_cmdWrite(EVE_CLKSEL,0x10); (which is an 
illegal setting, but it seems to work), and set the framerate to 102Hz, 
then i can run the demo with update rate of approx. 10 ms, but only with 
approx. 300 bytes of display list (i modified the demo a bit, i have no 
touch)

von Rudolph (Gast)


Lesenswert?

At what speed are you running this?

This very much looks like a hardware issue, also what Spyy reports.
Your Riverdi Click board is nothing but a breakout board, it is 
completely passive and not buffered.
So the SPI is only driven by the MK64FX512VMD12 on your Teensy 3.5.
The drive strength for this 3.3V controller should not exceed 4mA, if 
it is configured to maximimum drive strength to begin with.
Same with the Teensy 4.1 and its IMXRT1062DVJ6A.

My display adapter board has drivers for all signals, one property of 
these is that the ones I am using are 5V tolerant even though these are 
powered with 3.3V, the other property is the decoupling from the 
controller, there is less load on the lines for the controller and their 
drive strength is a lot higher.
I have two 74LVC2G17 for SCK, MOSI, CS and PD plus one 74VHC1GT125 for 
MISO.


I configured my Teensy 4.1 to 20MHz and tried to measure the lines with 
an oscilloscope.
Well, tried, at 20MHz there is not much left to be measured.
And the CS line showed rather slow signal changes, even with no load 
except the probe from the oscilloscope.
I tried to change the frequency but using Arduino 1.8.13 plus 
Teensyduino resulted in no activity at all anymore on the SPI lines 
despite compiling and uploading worked.

Next, where do you get the 3.3V from to power the display?

I have a 3,3V stepdown regulator on my adapter to power the logic and 
the display module.
I can power the backlight from either the input voltage or from the 
generated 3.3V.
For the RVT101H I am supplying my adapter with 9V and use that for the 
backlight as well, most modules require a maximum backlight voltage of 
5V though or are even locked into using the 3.3V for the logic supply.

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


Lesenswert?

Hallo Rudi,
es ist schon zum Verzweifeln. Ich bekomme das einfach nicht hin. Am 
liebsten möchte ich einen Arbeitstag zu Dir kommen und die wichtigsten 
Punkte Stück für Stück durchgehen... Wie hoch ist Dein Tagessatz???
Nachdem nun also die FTDi-Animation funktioniert, möchte ich mal einen 
Buttom setzen. Ich sende an Adresse REG_CMDB_Write:
4 Byte 0D : FF : FF : FF   (CMD_BUTTON)
4 Byte X und Y -Koordinaten (0 : 200 : 0 : 100)
4 Byte Höhe x Breite (0 : 50 : 0 : 30)
2 Byte Font (0 : 31)  - richtige Reihenfolge???
2 Byte Option (0 : 0) - erst mal
4 Byte Text mit "Null" am Ende ("O" : "K" : "Ausrufezeichen" : 0)
Gesamt 20 Byte, also ein Vielfaches von 4.

Ich habe schon verschiedene Varianten (z.B. bei den Koordinaten und/oder 
Höhe und Breite) durch probiert, verschiedene Reihenfolgen der beiden 
Bytes z.B. Hilft alles nichts. Oder müssen die "Nullen" bei Fonts und 
Option vielleicht mit FF aufgefüllt werden, oder, oder ?
Was mache ich hier wieder alles falsch ?????????????????

von Rudolph R. (rudolph)


Lesenswert?

Bernd I. schrieb:
> Am liebsten möchte ich einen Arbeitstag zu Dir kommen und
> die wichtigsten Punkte Stück für Stück durchgehen...
> Wie hoch ist Dein Tagessatz???

Das will ich gar nicht wissen, nicht-selbständig zu arbeiten hat den 
deutlichen Vorteil das ich mich nur minimal mit dem Finanzamt 
herumärgern muss. :-)

Bernd I. schrieb:
> Nachdem nun also die FTDi-Animation funktioniert, möchte ich mal einen
> Buttom setzen. Ich sende an Adresse REG_CMDB_Write:
> 4 Byte 0D : FF : FF : FF   (CMD_BUTTON)
> 4 Byte X und Y -Koordinaten (0 : 200 : 0 : 100)
> 4 Byte Höhe x Breite (0 : 50 : 0 : 30)
> 2 Byte Font (0 : 31)  - richtige Reihenfolge???
> 2 Byte Option (0 : 0) - erst mal
> 4 Byte Text mit "Null" am Ende ("O" : "K" : "Ausrufezeichen" : 0)
> Gesamt 20 Byte, also ein Vielfaches von 4.

Sowas muss ich inzwischen auch nachschauen, wenn nur irgendwer eine 
Library für sowas schreiben würde... :-)

Meine Funktion dazu sieht so aus:
1
void EVE_cmd_button(int16_t x0, int16_t y0, int16_t w0, int16_t h0, int16_t font, uint16_t options, const char* text)
2
{
3
  if(!cmd_burst)
4
  {
5
    eve_begin_cmd(CMD_BUTTON);
6
    spi_transmit((uint8_t)(x0));
7
    spi_transmit((uint8_t)(x0 >> 8));
8
    spi_transmit((uint8_t)(y0));
9
    spi_transmit((uint8_t)(y0 >> 8));
10
    spi_transmit((uint8_t)(w0));
11
    spi_transmit((uint8_t)(w0 >> 8));
12
    spi_transmit((uint8_t)(h0));
13
    spi_transmit((uint8_t)(h0 >> 8));
14
    spi_transmit((uint8_t)(font));
15
    spi_transmit((uint8_t)(font >> 8));
16
    spi_transmit((uint8_t)(options));
17
    spi_transmit((uint8_t)(options >> 8));
18
19
    private_string_write(text);
20
    EVE_cs_clear();
21
  }
22
}

Das eve_begin_cmd() setzt CS, sendet die Adresse, sendet das Kommando,
soweit nichts neues.

Also bei den Daten das niederwertigste Byte zuerst.

0x0d 0xff 0xff 0xff
0xc8 0x00
0x64 0x00
0x46 0x00
0x28 0x00
0x1c 0x00
0x00 0x00
0x4f
0x4b
0x21
0x00

Ja, Breite und Höhe habe ich angepasst und einen kleineren Font 
verwendet.
Das passte nämlich nicht auf den kleinen Button. :-)

Und der Text ist eine Folge von Bytes.

Hmm, wie sieht das eigentlich aus wenn einen UTF-8 Font verwendet und 
auf dem Button "nö!" steht?
So: 0x6e 0xc3 0xb8 0x21 0x00 0x00 0x00 0x00

Also am Ende vom String steht immer 0x00 und die nächsten drei 0x00 sind 
zum Auffüllen bis zum nächsten 32-Bit Wort.

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


Angehängte Dateien:

Lesenswert?

Im Prinzip habe ich es schon so gemacht, nun aber noch einmal penibel 
alles genau so eingegeben, wie Du es aufgeschrieben hast. Geht dennoch 
nicht.
Ich denke das Problem ist folgendes (und ich oute mich jetzt mal wieder 
ein bisschen):
Ich weiß nicht einmal, was ich alles eventuell zuerst noch definieren 
muss. Wie gesagt, bisher habe ich ja ohne Co-Prozessor gearbeitet. Und 
dabei habe ich es nicht einmal geschafft, den Bildschirm am Beginn zu 
löschen (mit RGB = 1,1,1 und bCLEAR - hier habe ich nur senkrechte bunte 
Streifen). Das habe ich seit Jahren ignoriert, indem ich gleich zu 
Beginn (nach der Initialisierung des Display) dann ein RECT in der Größe 
des Display setze (bzw. mehrere RECTS stets um ein Pixel kleiner werdend 
mit dunkler werdender Farbe, so dass sich ein Bildschirm mit 
"beleuchteten" Rand ergibt (siehe Anhang). So beginnt jeder 
Bildschirm-Aufbau und dann folgend die gewünschten Primitives. Mit 
diesen Datenblättern, die einfach so chaotisch aufgebaut sind, habe ich 
so meine Probleme. Vor einem halben Jahr habe ich zum ersten mal einen 
LED-Treiber (IS31FL3737) in Betrieb nehmen wollen. Der kann 144 Einzel- 
bzw. hier 48 RGB in einer 12x12 Matrix ansteuern. Funktioniert nun 
super, NACHDEM ich mir ein Demo-Board (was es zum Glück dafür gab) 
kaufte und dort die I2C-Schnittstelle mitgelesen hatte. Das Datenblatt 
passt genauso in diese Kategorie: Schlimmer geht's nicht. Das hätte ich 
ohne das Board nie herausgefunden.
Naja und so habe ich mir meine Bibliothek für Buttons usw. geschaffen. 
Ich gebe nur noch gegebenenfalls die Koordinaten ein und lasse dann das 
Unterprogramm ausführen und habe auch 3D-Effekte und Farben, wie ich es 
will, die Tasten "versenken" sich beim Betätigen. So sieht eben auf dem 
Foto z.B. meine alpha-numerische Tastatur aus (ohne Co-Prozessor).

Zurück zur eigentlichen Sache:
Wenn ich zuerst MEIN Bildschirm (wie Foto - nur das Grün) auf 
herkömmliche Art setze und dann die Animation starte - das funktioniert. 
Nun passierte beim Experimentieren folgendes: Nach 3 Sekunden (die ich 
einfach warte bis zum Ende der Animation) gab ich mal versuchsweise den 
Befehl: CMD_DLStart und dann den Buttom-Befehl. Da spielte die 
FTDi-Animation ein 2. mal ab!!! Aber kein Buttom kommt.
Mir ist das ganze Prinzip einfach noch völlig unklar: Muss ich den 
gesamten Bildschirm mit 15 Elementen in einem "Atemzug" an den 
Reg_CMDB_Write senden, oder kann ich hier auch anhängen, oder sende ich 
nacheinander die einzelnen Elemente , oder, oder. Oder muss der 
Reg_CMDB_Write etwa gemäß den schon gesendeten Bytes aufaddiert werden 
(Reg_CMDB_Write + Anzahl schon gesendeter Bytes)? Was muss am Beginn 
noch definiert/gesetzt werden (außer alle Register für den richtigen 
Betrieb des Display natürlich)? Also Du merkst: Grundsatzfragen. Wenn 
ich nicht jetzt in diesem Zugzwang wäre, Bitmaps darstellen zu müssen, 
würde ich mir diesen ganzen Ärger nicht antun. Habe auch schon das Netz 
durchforstet, aber eine andere Hilfe, als dieses Forum und solch einen 
Spezialisten, wie Dich, habe ich nicht gefunden.