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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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