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
voidEVE_start_command(uint32_tcommand)
2
{
3
uint32_tftAddress;
4
5
ftAddress=REG_CMDB_WRITE;
6
EVE_cs_set();
7
charspi_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
voidEVE_start_dma_transfer(void)
2
{
3
EVE_cs_set();
4
5
staticspi_transaction_ttrans;
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
Ä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:
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.
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...
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. :-)
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.
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.
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.
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
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?
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
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 */
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.
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
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.
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ß!
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.
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
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.
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
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.
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.
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?
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.
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.
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?
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.
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.
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".
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.
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
constuint8_tpic[3867]PROGMEM=..
Why 3876? When I saved pic[3867] as data.c then file was 22,7 KB..
Schönen Abend :)
Karol
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().
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
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.
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!
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.
:-)
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?
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.
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?
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);
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...?
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.
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.
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.
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.
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.
I try to make my own spinner, 2 sectors rotating around a circle.
The sample code is this:
1
floatt=(spin/360.00)*PI;
2
intr=(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.
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.
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.
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
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.
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
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.
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
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.
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 ;-)
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.
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.
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
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. :-)
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 ;-)
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.
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
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.
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???
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
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.
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!
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.
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?
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.
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?
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.
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
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?
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:
#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.
@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
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.
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
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
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...
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....
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. :-)
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...
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.
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 ?
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 ?
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.
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
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ß?
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.
@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
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...
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%.
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?
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.
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.
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)
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?
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.
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?
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
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.
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.
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.
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)
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.
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
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));
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.
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
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.
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.
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.
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
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...
...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.
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.
@Spyy
Da ich gerade mit einem billigen 24MHz Logik-Analyzer und Pulseview
herum spiele, hast Du Dir mal angesehen was der Teensy so auf den SPI
wirft?
Ich musste den SPI etwas runter drehen damit ich mit dem LA überhaupt
brauchbar messen kann und bin jetzt bei 4MHz.
Aber unter Beibehaltung des 5ms Rasters reicht das locker für 2200 Bytes
bevor auch nur die nächste Touch-Abfrage übersprungen wird.
Ein Pulseview Trace vom Startup hängt an.
Ich habe gerade mal bei den 904 Bytes die mein Bildwechsel im Moment
braucht den SPI auf 400kHz runter gedreht.
Der einzige "negative" Effekt ist das der Touch nicht mehr alle 5ms
abgefragt wird, sondern nur noch alle 20ms, die Übertragung für den
Bildwechsel dauert so rund 18ms und damit ist der SPI dann einfach drei
Mal beschäftigt wenn der Touch abgefragt werden soll.
Jetzt habe ich bei 4MHz SPI den Bildwechsel mal auf 15ms / 66Hz
gestellt.
Das klappt ohne Probleme da ich das EVE3-50G das hier gerade anhängt auf
74Hz laufen lassen - nicht, weil ich 74Hz brauche, sondern weil der
BT815 etwas eingeschränkt ist was den Pixel-Clock angeht.
Stelle ich den Bildwechsel auf 10ms blinkt das nicht mal mehr.
Bei 12,5ms funktioniert es auch nicht.
Hmm, drehen wir mal an der Zeitbasis. :-)
Mit Intervallen von 1,7ms läuft es noch wenn ich alle 13,6ms einen
Bildwechsel mache. :-)
Hi,
kann mir zufällig jemand erklären, wie ich Umlaute in die Fonts bekomme,
bzw. generell "richtig" mit einem custom character set arbeite?
Was ich versucht habe:
User Defined Charater Set -> Textdatei, UTF-8 codiert mit folgendem
Inhalt (ohne die Anführungszeichen natürlich...)
"
!"%&()*+,-./0123456789?ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuv
wxyzÄÖÜäöüß"
Font generiert, komprimiert, und ab damit in RAM_G
Dann
Speichert Dein Editor den Text auch wirklich mit UTF-8 Kodierung?
Das Atmel-Studio musste ich erstmal entsprechend umstellen.
Man kann beim Konvertieren übrigens auch alle Zeichen bis zum letzten
gewünschten Mitnehmen, das wäre in dem Fall "ü" und ich habe mal eine
entsprechende Charmap-Datei angehängt.
Das Format ist leider so ineffizient gestaltet das so oder so eine
Glyphe für alle Zeichen bis zum letzten erzeugt wird, bei ungenutzen
Zeichen ist die zwar leer, belegt aber dennoch den vollen Platz, da kann
man die dann auch gleich mitnehmen.
Und schaut mal hier: http://www.brtcommunity.com/index.php?topic=127.15
Es gibt einen inoffiziellen EVE-Asset-Builder-setup-2.2.0-rc2.zip
Wesentlich ist da, der ASTC-Encoder wurde auf V2 aktualisiert, damit
geht das Konvertieren von Fonts richtig schnell.
Nur wie ich schrieb, Bridgtek hat die Version für AVX2 in das Archiv
gepackt, wenn die eigene CPU keine AVX2 kennt läuft das aber wenn man
das durch eine entsprechende Version von hier
https://github.com/ARM-software/astc-encoder ersetzt.
Rudolph R. schrieb:> wenn die eigene CPU keine AVX2 kennt
Das kann doch nur eine sehr historische CPU sein, oder?
Ich meine, ich arbeite hier privat regulär mit einem zehn Jahre alten
Core2Duo E8500. Selbst der kann das schon.
Was den AssetBuilder betrifft: Das war das Erste, was ich durch eigene
Software ersetzt habe. (Wobei der eigentliche ASTC-Encoder "zugekauft"
ist, das ist allerdings im BT-Original genauso ;o)
Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes
Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings
sehr viel komfortabler als das Original. Vor allem im Bezug auf einen
AVR8-Host als Zielsystem...
c-hater schrieb:>> wenn die eigene CPU keine AVX2 kennt>> Das kann doch nur eine sehr historische CPU sein, oder?
Naja, fast, ich habe einen AMD FX-8320E im Rechner, das war so praktisch
die dickste CPU die ich vor ein paar Jahren noch für mein AM3+ Mainboard
bekommen konnte, Markteinführung war September 2014, gekauft im Februar
2016.
Der hat zwar schon eine ganze Latte an Features, aber kein AVX2.
Die SSE4 Version vom ASTENC ist V2 läuft und ist deutlich schneller als
die V1.x die vorher beim EVE Asset Builder beilag.
> Ich meine, ich arbeite hier privat regulär mit einem zehn Jahre alten> Core2Duo E8500. Selbst der kann das schon.
Also laut Wikipedia nicht, der kann nur bis SSE4.1, AVX kam Anfang 2011
und AVX2 kam Mitte 2013 von Intel.
Ich schiele zwar schon auf einen Ryzen 5600X, aber das letzte Mal das
ich ein paar Komponenten zusammen gestellt habe um den Rechner
aufzurüsten war ich viel zu schnell bei über 1000 Euro, so langsam ist
die Kiste dann auch wieder nicht. :-)
Der Markt ist im Moment auch insgesamt eher unlustig.
c-hater schrieb:> Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes> Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings> sehr viel komfortabler als das Original. Vor allem im Bezug auf einen> AVR8-Host als Zielsystem...
Die ersten EVE Asset Builder habe ich auch nicht genutzt, sondern lieber
den Image-Converter aus der Shell.
Nur ist der EAB stetig besser geworden, Bridgetek hat auf meinen
Vorschlag hin sogar ein ein BIN2C Tool eingebaut. :-)
Braucht man das? Nicht wirklich in dem Sinne, aber jetzt muss ich das
Tool nicht mehr wechseln.
Und seit den BT815 erzeuge ich Flash Images mit dem EAB und übertrage
die damit.
Rudolph R. schrieb:>> Core2Duo E8500> Also laut Wikipedia nicht, der kann nur bis SSE4.1, AVX kam Anfang 2011> und AVX2 kam Mitte 2013 von Intel.
Nun, er selber behauptet von sich, das zu können. Und tatsächlich läuft
auch die AVX2-Variante des ASTC-Encoders problemlos.
Könnte aber natürlich sein, dass ich beim Auslesen der Feature-Flags was
falsch gemacht habe und der ASTC-Encoder ein Fallback hat. Guter
Hinweis, da werde ich wohl nochmal ein wenig nachprüfen müssen.
Obwohl: Selbst wenn nur Fallback, ist es trotzdem locker schnell genug
für meine Zwecke. Wechsel der Qualitätsstufe einer 800x480-Grafik dauert
(inclusive der Decodierung des neuen Vorschaubilds und kompletter
Aktualisierung des GUI) nur ca. 1/10 Sekunde. Damit kann ich gut leben.
> c-hater schrieb:>> Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes>> Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings>> sehr viel komfortabler als das Original. Vor allem im Bezug auf einen>> AVR8-Host als Zielsystem...> Und seit den BT815 erzeuge ich Flash Images mit dem EAB und übertrage> die damit.
Ich lade den Kram immer vom Host hoch. Entweder liegt er im Flash des
Hosts (wenn dort genug Platz ist) oder es kommt von einer an den Host
angebundenen SD-Karte. Sehr praktisch für Updates.
Genau dazu, beide Varianten schön einfach "packagen" zu können, dient im
Wesentlichen der Komfort meines eigenen Asset-Builders. Das einzige, was
bei der Entwicklung noch ein wenig nervt, ist das Hin- und Herstecken
der SD-Karte. Dafür baue ich aber auch gerade an einer Lösung, bei der
der Entwicklungsrechner für das Zielsystem eine virtuelle SD-Karte (und
einen virtuellen Reset-Button über deren CD-Signal) bereitstellt.
c-hater schrieb:> Könnte aber natürlich sein, dass ich beim Auslesen der Feature-Flags was> falsch gemacht habe
So war es tatsächlich. Der E8500 kann nichtmal AVX, geschweige denn
AVX2.
> und der ASTC-Encoder ein Fallback hat.
Was damit wohl nachgewiesen ist.
c-hater schrieb:>> und der ASTC-Encoder ein Fallback hat.>> Was damit wohl nachgewiesen ist.
Ich habe das gerade noch mal ausprobiert, mit dem EAB 2.2 wird eine
"astcenc.exe" ausgeliefert die sich so meldet:
ASTC codec v2.1, 64-bit avx2+popcnt
Copyright 2011-2020 Arm Limited, all rights reserved
Und damit bekomme ich in EAB das hier als Fehler:
ASTCENC_ERR_BAD_CPU_ISA
Also auf meiner geringfügig frischeren CPU von AMD gibt es da kein
Fallback.
Mit der aktuellen v2.5 auch nicht.
Da die SSE4.1 Version alles andere als langsam ist wäre es wohl schlauer
das nächste offizielle Archiv damit auszuliefern.
Wir Zeit aufzurüsten, aber Zen4 mit DDR5 ist auch schon am Horizont zu
sehen. :-)
Hallo,
hat mal jemand die Library mit einem RVT70xQB getestet?
Habe hier mal an einer laufende Applikation, die bisher NHD70 nutzte ein
RVT70AQBNWC00 angeschlossen und die Display-Defines geändert. Trotz
gutem timing (DL <100us) flackert das Display alle paar Sekunden. Es
wird dann für ein paar Millisekunden dunkel und kommt dannach wieder.
Der Touch funktioniert auch nur gelegentlich...
Gruß,
Johannes
Kleine Ergänzung: Das Display blitzt im 2-Skunden-Takt sobald ein Button
in der DL enthalten ist. Eine DL mit Bitmap, Slider und ein paar Texten
verhält sich normal.
Also zumindest das RVT50AQBNWC00 habe ich selber schon benutzt in einem
Projekt, das ist ja praktisch das gleiche, nur eben kleiner.
Der einzige Unterschied elektrisch ist, das RVT70 braucht mehr Strom.
Wie versorgst Du das Ding denn? Und wie viel Strom verträgt die
Versorgung?
Johannes schrieb:> Hängt hinter einem TS2596 der 5V macht für die BL und dann ein TS9013> der 3,3V macht. Spannungen passen und der Low-Drop-Regler wird so nur> handwarm
Okay, wenn die richtig funktionieren sollte das reichen.
Blöderweise hat Riverdi keine vernünftigen Daten, für die 3,3V muss man
bei der Größe mindestens 200mA vorhalten.
Und für die Beleuchtung so um die 300mA bei 5V.
Wie sieht der Rest zum Display aus?
Und zeigt mal bitte etwas Testcode der nicht funktioniert.
Johannes schrieb:> Problem gelöst. Die DL wurde zu schnell geladen. 20ms Wiederholrate> scheinen einen Hauch zu schnell zu sein. Bei 25ms funktioneirt alles> problemlos.
Dann stimmt aber was nicht, mit den Parametern die ich für das Display
in die EVE_config geschrieben habe, zusammen mit dem Takt für den BT815
von 72MHz sollte das eigentlich einen Refresh von schlapp 65Hz ergeben.
Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?
Oder sind die 20ms gar keine 20ms?
Die EVE_RVT70 Konfiguration wäre zum Beispiel für ein RVT70AQFNWC00,
also EVE2 / FT813, damit sollten sich 54Hz ergeben.
Und mit RVT70UQFNWC00 habe ich das auch im Einsatz bei 20ms.
Hi Rudolph,
also zuerst mal vielen Dank für die Grandiose Hilfe mal wieder :)
ich habe meine Fonts aus dem Legacy Format auf ASTC umgestellt und das
funktioniert tip top, auch mit Sonderzeichen.
Zu der Konvertierungsdauer kann ich nur sagen, dass ich es fast nicht
mitbekomme, dass er überhaupt konvertiert. Es dauert vielleicht eine
Sekunde und das auf einer - nicht wirklich aktuellen - CPU (AMD Ryzen 7
1700X)
Nun aber zu einem neuen Problem:
Ich kämpfe mit falsch detektierten Touch punkten - und zwar nur, wenn
ich im oberen rechten Bildschirmrand etwas anzeige... sehr komisch
Ich zeige auf meinem Screen ein Smartphone-Inspiriertes Menu an:
meine Touchausgabe (zuerst die 5 Tags, dann RawX und RawY) sieht dann
wie folgt aus:
also die Anzahl an falschen Touch Ereignissen ist vertretbar -> erster
Touch bei 67548, dann drei falsche - naja OK, dann bei 68413 der zweite
richtige.
Wenn ich das Menü jetzt aber wieder mit Leben Fülle, rastet der Touch
Controller anscheinend komplett aus, bis er zufällig irgendwas trifft,
was das Menü wieder ausblendet:
Wie schnell ist der SPI?
Probier den mal während der Touch-Phase auf eine kleinere Frequenz zu
stellen.
Wenn Du einen Logic-Analyzer hast welcher problemlos den Takt auf dem
SPI mitmacht, dann zieh mal einen Trace davon.
Das kann gut sein, dass der SPI zu schnell ist um sauber zu lesen.
Wenn ich hier den Takt zu hoch drehe kommt ab so 15Mhz Datenmüll zurück,
Schreiben geht deutlich schneller, CLK und MOSI kommen ja zusammen an.
Ok, time to try something new. :-)
https://github.com/RudolphRiedel/FT800-FT813/discussions
This might be the place to ask if for example the well moderated BRT
forum is not your thing or if for example the Matrix Orbital forum is
not apropriate since you module is from a different manufacturer.
And this here is only one thread afterall.
Mein bescheidener Beitrag dazu, vielleicht hilft's: Ich hatte ja gerade
vor ein paar Wochen von meinem Problem mit dem C-Touch berichtet, dass
immer wieder falsche Koordinaten abgeholt wurden. Die Empfindlichkeit
des Touch ist dann einfach zu hoch. Sie ist ausgelegt dafür, das Display
mit einer Glasscheibe zu betreiben. Im Datenblatt des Display sollte
stehen, wie man das ändern kann. Aber eine große Hilfe ist bereits, die
Applikation zu erden (Schutzleiter an Masse), bzw. ein entspr. Netzteil
zu verwenden, dass den Schutzleiter auf Minus durchschleift (die meißten
China-Netzteile haben ja nicht einmal einen Schutzleiter-Anschluss).
Ich arbeite seit einigen Jahren mit dem FT8xx, seit ca. 2 Jahren mit dem
FT813. Habe schon recht beachtliche Oberflächen NUR mit den
"Primitives-Befehlen" gezaubert. Nun aber rufen die Kunden nach
"schöneren" Grafiken und nach Bitmaps. Rudi, Du sollst es nicht glauben,
aber ich beginne JETZT den Co-Prozessor einzusetzen. Und da beginnt nun
mein Problem. Ich bin am Verzweifeln, wälze das Datenblatt von vorn bis
hinten und verstehe es nicht. Ich bekomme es nicht einmal hin, das
FTDi-Demo (CMD_Logo) zu laden. Kannst Du mir bitte, bitte in
"Echtworten" sagen, was ich an welche Adresse senden muss? Ich bin hier
am "wilden" Probieren. Was übersehe ich da?
Ist es vielleicht genauso einfach (wenn man es denn einmal begriffen
hat):
Ram_CMD ab Hx308000 setzen (hier auch nach jedem Befehl + 4 ???) gefolgt
von HxFFFFFF00 für "CMD_DLSTART". Dann Hx308004 (?) gefolgt von
CMD_Logo. Wie beenden? Einfach nur Hx3080xx gefolgt von CMD_SWAP ???
Das steht in Kapitel 5 vom Programming Guide.
Ich benutze ja in meiner Libray von Anfang an exklusiv nur den
Co-Prozessor.
Und da gibt es zwei Wege, entweder man schreibt in RAM_CMD und muss
dabei die ganze Zeit zum Beispiel in einem Offset-Zähler mitrechnen was
man so geschrieben hat, am Ende schreibt man dann den Wert in
REG_CMD_WRITE.
Direkt nach Reset stehen REG_CMD_READ und REG_CMD_WRITE auf 0.
Dann schreibt man sagen wir mal 20 Bytes, setzt REG_CMD_WRITE auf 20 und
was zwischen 0 und 20 steht wird ausgeführt.
Wenn REG_CMD_READ auch 20 hat ist der Co-Prozessor fertig.
Dann geht es ab 20 weiter.
Wenn man in RAM_CMD schreibt gibt es 4096 automatisch einen Überlauf und
es wird wieder auf Adresse Null geschrieben.
Diesen Überlauf muss man mit im Offset berücksichtigen.
Das ist der "alte" Weg, das ist mit den FT80x kompatibel und das habe
ich bis Version 4 von meiner Library auch so gemacht.
https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/EVE_commands.c
EVE_begin_cmd() + EVE_inc_cmdoffset()
Mit den FT81x wurden neue Register eingeführt, REG_CMDB_WRITE und
REG_CMDB_SPACE.
Wenn man ein 32 Bit Wort in REG_CMDB_WRITE schreibt, dann landet das an
der nächsten freien Position von RAM_CMD und mit jedem weiteren
Schreiben in REG_CMDB_WRITE wird auch immer wieder an die nächste
Adresse geschrieben.
Wenn man mit Schreiben aufhört wird REG_CMD_WRITE automatisch gesetzt
und ausgeführt was in RAM_CMD ist.
Den Offset nicht mitzurechnen spart einiges an Zeit, ist aber nicht
mehr mit den FT80x kompatibel.
Das habe ich in der aktuellen Version 5 umgesetzt.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_commands.c
eve_begin_cmd()
Bernd I. schrieb:> Mein bescheidener Beitrag dazu, vielleicht hilft's: Ich hatte ja gerade> vor ein paar Wochen von meinem Problem mit dem C-Touch berichtet, dass> immer wieder falsche Koordinaten abgeholt wurden. Die Empfindlichkeit> des Touch ist dann einfach zu hoch. Sie ist ausgelegt dafür, das Display> mit einer Glasscheibe zu betreiben. Im Datenblatt des Display sollte> stehen, wie man das ändern kann. Aber eine große Hilfe ist bereits, die> Applikation zu erden (Schutzleiter an Masse), bzw. ein entspr. Netzteil> zu verwenden, dass den Schutzleiter auf Minus durchschleift (die meißten> China-Netzteile haben ja nicht einmal einen Schutzleiter-Anschluss).
Hi,
danke für den Input, aber das war tatsächlich nicht mein Problem.
Mein Problem liegt hier begraben:
sobald ich diesen Schatten mit hinzu nehme, rastet der Touch so aus.
Ohne, läuft er perfekt. Setze ich hier etwas nicht richtig zurück was
den Stencil angeht? Allerdings sollte das ja keine Auswirkungen auf den
Touch haben... Oder ist es wohlmöglich doch ein Firmware-Bug im EVE?
Ich könnte noch mal den Logic Analyzer dranhängen, ich habe eine Logic
Pro 8, der sollte den Takt schon mitmachen... Dafür müsste ich aber
wieder Kabel an meine Platine löten, weil ich mal wieder vergessen habe,
mir den Bus auf Testpunkte zu legen... Ich kann mir aber nicht
vorstellen, dass bei ca. 96mm Leiterbahnlänge zwischen dem Controller
und dem EVE es da Probleme gibt bei 40 MHz. Laut Eagle besitzen die
Traces eine maximale Frequenz weit über 3 GHz.
Falls Ihr unabhängig meiner Beobachtung doch weiter den SPI verdächtigt,
kann ich entweder die BUS-Geschwindigkeit drosseln, oder doch mal den
Logic Analyzer anlöten...
Viele Grüße
Daniel S. schrieb:> Mein Problem liegt hier begraben:> EVE_cmd_dl_burst(COLOR_A(0));> ...
Ok, sowas habe ich noch nicht probiert, muss ich mir mal ansehen.
Wenn das die Ursache ist, bitte mal an Bridgetek melden.
Daniel S. schrieb:>Ich kann mir aber nicht vorstellen, dass bei ca. 96mm Leiterbahnlänge>zwischen dem Controller und dem EVE es da Probleme gibt bei 40 MHz.
Abgesehen davon, dass der maximale Takt für EVE mit 30MHz angegeben ist
und es auch darauf ankommt was in den Leitungen, neben den Leitungen und
unter den Leitungen noch so liegt, dreh doch einfach mal den Takt auf
8MHz runter und schau was passiert. :-)
Ich weiß halt aus Beobachtung, dass zumindest im meinem Aufbau Senden
deutlich schneller noch funktioniert als Lesen.
In einem Test konnte ich bis 17MHz noch sauber lesen, aber bis 40MHz
Schreiben.
Mit einem anderen Controller waren es 12MHz und 35MHz.
>Laut Eagle besitzen die Traces eine maximale Frequenz weit über 3 GHz.
Da habe ich so leichte Zweifel dran, bei 20MHz verfälschen ein paar pF
schon gut die Messung, das wird zunehmend analog. Und dann müssen beide
Seiten die Leitungen auch schnell genug treiben können was EAGLE wohl
eher nicht berücksichtigen wird.
Rudolph R. schrieb:> Dann stimmt aber was nicht, mit den Parametern die ich für das Display> in die EVE_config geschrieben habe, zusammen mit dem Takt für den BT815> von 72MHz sollte das eigentlich einen Refresh von schlapp 65Hz ergeben.> Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?> Oder sind die 20ms gar keine 20ms?
Hi Rudolph,
der 5ms Tick ist exakt 5ms lang. Nutze einen SAMC/D auf 48 MHz. der SPI
läuft auf 12 MHz.
Welche Parameter könnten denn angepasst werden müssen?
Johannes
Johannes schrieb:>> Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?>> Oder sind die 20ms gar keine 20ms?>> Hi Rudolph,>> der 5ms Tick ist exakt 5ms lang. Nutze einen SAMC/D auf 48 MHz. der SPI> läuft auf 12 MHz.>> Welche Parameter könnten denn angepasst werden müssen?
Schau mal in die EVE_config.h ob da wirklich EVE_RiTFT70 aktiv ist.
Tja, seltsam, vor allem habe ich die EVE_RiTFT50 Einstellung selber
schon so benutzt, die ist ja mit der EVE_RiTFT70 identisch.
Muss ich mal auf dem Schreibtisch kramen, ein RVT50UQBNWC01 habe ich ja
und eine Platine mit ATSAMC21 auf 48MHz.
Das lief soweit alles.
Und ohne Bezug, ich hatte vor einiger Zeit ein RVT101HVBNWC00-B
bestellt, das ist jetzt unterwegs, ich werde berichten. :-)
Na toll, FedEx hat das Paket nicht geliefert und im Tracking steht immer
noch: "Voraussichtlicher Zustelltermin: Freitag, 28. Mai 2021 bis Ende
des Tages"
Also frühestens am Montag, danke FedEx mir so das WE zu versauen.
Das RVT50UQBNWC01 läuft übrigens einwandfrei auf 20ms mit meinem
ATSAMC21 Board, nur auf 15ms spinnt der Touch.
Aber das Timing von Display liegt auch bei 15,3ms, also sind 15ms
schlicht zu schnell.
Hallo Rudolph,
so nach langer Zeit komme ich mal wieder zu meinem Projekt...
Ich habe mal das hier in die EVE_Init() Routine geschrieben:
// Write the EVE stats:
uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
delay(1000);
uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
Serial.print("EVE clock: ");
Serial.println(eveClockNew - eveClockOld);
Ich lese einfach zweimal im Abstand von 1 Sekunde das CLOCK Register.
Meine Erwartung wäre, dass ich dann so ein Wert vom 72000000 bekommen
werde, da ich ja das hier geschrieben habe:
EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
Ich bekomme aber das hier:
Eve init...
EVE PCLK Frequency: 48000000
EVE clock: 34667018
Was bekommst Du für einen Wert, wenn Du das bei Dir machst ?
Spyy schrieb:> Was bekommst Du für einen Wert, wenn Du das bei Dir machst ?
Ich habe nur den Systick-Timer und kein exaktes delay().
Also lese ich alle 200 * 5ms REG_CLOCK und lasse mir die Differenz
zu dem alten Wert anzeigen.
Das sind 72001711 mit einem ATSAMC21 und einem BT815.
Die Abweichung kommt jetzt entweder von meinem Quarz oder dem Quarz auf
dem Display oder beiden.
Wenn ich das auf REG_FRAMES umstelle bekomme ich 65.
Spyy schrieb:> Und Du könntest mal die kompletten Timing-Werte für das Display über den> Zaun reichen.> #if defined (EVE_EVE4_ISFD)> #define EVE_VCYCLE (518L)> #define EVE_HCYCLE (548L)> #define EVE_PCLK (1L)
#define EVE_GEN 4
Entscheidung für die Bildrate sind diese Werte.
Wenn Du einen BT817 / BT818 mit PCLK = 1 betreibst, dann nutzt der die
zweite PLL.
Und wenn das Define für EVE_PCLK_FREQ nicht da ist lässt mein Code den
Default-Wert drin, das sind 60MHz.
Also mit den Werten hast Du einen Pixel-Clock von 60MHz was in einer
Bildrate von 211 HZ resultiert und etwas außerhalb der Spec liegen
dürfte.
Probiere es mal mit PCLK = 4, damit wird die zweite PLL nicht verwendet
und mit den dann geteilten 72MHz sind es 63,4Hz.
Oder mit PCLK = 1 und PCLK_FREQ = 17000000 wären es 59,89Hz, der Aufwand
lohnt sich wohl aber eher nicht.
Wo kommen die Timing-Werte her? In dem "Datenblatt" von der Webseite
habe ich die nicht gefunden.
Rudolph R. schrieb:> Probiere es mal mit PCLK = 4, damit wird die zweite PLL nicht verwendet> und mit den dann geteilten 72MHz sind es 63,4Hz.> Oder mit PCLK = 1 und PCLK_FREQ = 17000000 wären es 59,89Hz, der Aufwand> lohnt sich wohl aber eher nicht.
Ok habe ich gemacht (PCLK = 4) bekomme dann:
EVE clock: 34661499
EVE frames: 31
=> Irgendwie ist bei mir alles "durch 2" geteilt...31 * 2 => 62Hz
???? wo liegt der Fehler ? Ich habe keinen externen Quarz dran...???
Uff...Sch****e
und wenn ich in das Register gar nix reinschreibe
#if EVE_GEN > 2
//EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
#endif
=> laut Datenblatt dann default => 60 Mhz
bekomme ich das hier:
EVE clock: 28931524
Also 29 Mhz und mit
Wo hast Du keinen externen Quarz dran?
An dem BT817/BT818?
Dann wird ja einfach nur der interne RC-Oszillator verwendet, der hat
auch 12Mhz. Der ist nur nicht unbedingt so präzise oder
temperatur-stabil wie ein Quarz oder Resonator.
Wenn ich in dem EVE_RiTFT50 Profil das EVE_HAS_CRYSTAL auskommentiere
dann komme ich immer noch auf 65Hz.
Aber die Anzeige für den Takt ändert sich jede Sekunde.
72077473
72093395
72077258
72066016
72101521
Jetzt nicht in der Reihenfolge.
Mit Quarz ändern sich höchstens mal die letzten zwei Stellen
72001727
72001719
72001734
72001727
72001726
Da würde ich dann aber eher vermuten das die Sekunde Mess-Intervall auch
mal ein paar Taktzyklen mehr oder weniger haben kann.
Spyy schrieb:> => laut Datenblatt dann default => 60 Mhz> bekomme ich das hier:> EVE clock: 28931524>> Also 29 Mhz und mit
Du misst nicht einmal pro Sekunde, sondern zwei Mal?
Ich habe zu früh auf senden gedrückt...
Ich messe so:
// Write the EVE stats:
uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
delay(1000);
uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
Serial.print("EVE clock: ");
Serial.println(eveClockNew - eveClockOld);
Also Wert lesen dann eine Sekunde warten dann nochmal lesen und
voneinander abziehen...
Wie auch schon gesagt die Messergebnisse spiegeln auch das reale
Verhalten wieder...bekomme immer nur 1/2 Framerate und bei ca. 25 ms
Schreibzyklen Probleme mit der Displaylist..
und das delay(1000) sind wirklich 1 Sekunde...
Dazu fällt mir jetzt nicht mehr wirklich was ein.
Miss das mal nachdem die EVE_init() durch ist, packe noch ein
delay(1000) vor das erste Lesen des Registers und ziehe mal einen Trace
davon mit dem Logic-Analyzer.
Ja mir leider auch nicht....aber...
Wenn ich das hier eintrage:
EVE_cmdWrite(EVE_CLKSEL,0x10);
bekomme ich das hier:
EVE PCLK Frequency: 60000000
EVE clock: 72306594
EVE frames: 102
ach so: Ich habe den BT818....also den neuen
Ich glaube das mit dem CLKSEL funktioniert nicht richtig...wenn ich da
0x00 eintrage bekomme ich keine 60 Mhz....
Erst wenn ich im hohen "nibble" ne 1 eintrage bekomme ich 72
Keine Ahnung, ich habe mal im BRT Forum die Frage gestellt...mal
sehen...
Kannst Du das mit was anderem als dem Teensy ausprobieren?
Etwa mit einem Arduino Uno?
Die Frage wurde im BRT Forum ja schon das letzte Mal nicht wirklich
beantwortet.
Und die Antwort fand ich jetzt nicht direkt hilfreich.
Vielleicht sollte ich mir mal einen Teensy 4 zulegen.
Vielen Dank für die Erklärungen zum Co_Prozessor. Das alles, was ab
Kapitel 5 steht habe ich natürlich auch schon gelesen. Ich nutze auch
nur noch den FT813, also was mal war, interessiert mich demzufolge auch
nicht (mehr). Dennoch steht es im Programmer-Guide des FT813 noch so
drin??!!!
Meine Frage nach KONKRET war ja diese:
Ich sende per SPI 7 Bytes:
Hx302574 (Reg_CMDB_Write) gefolgt von FF FF FF 31 (CMD_LOGO). Richtig?
Blödsinn? Fertig?!?! Ich nehme an, auch hier muss das Register
eigentlich mit HxB0.. (statt Hx30...) gesetzt werden, weil ja das erste
Bit ein H sein muss.
Habe auch beides ausprobiert.
Das ist natürlich nicht das Einzigste, was ich seit Tagen immer wieder
ausprobiere. Aber bisher geht es einfach nicht.
Einmal das grundlegende Prinzip...!!!! Ich denke schon, dass ich dann
mit allen anderen Befehlen klar komme. Warum kann so etwas nicht im
Datenblatt konkret drin stehen?
Um per Reg_CMDB_Write das Kommando CMD_LOGO zu senden wäre diese Sequenz
richtig:
0xb0 0x25 0x78 0x31 0xff 0xff 0xff
Aus mysteriösen Gründen ist nämlich die Byte-Order für die Adressen
anders als für die Daten.
Das steht auch alles im Datenblatt und Programming Guide, das muss man
nur erstmal finden.
Da bist Du nicht der Erste der darüber stolpert und ganz sicher nicht
der Letzte.
Das RVT101HVBNWC00-B ist heute angekommen und funktioniert spontan. :-)
Die 10.1" sind schon heftig groß und das Panel ist derbe hell.
Mein Handy schaltet das Bild dunkler weil diese Leucht
Im Moment versorge ich das mit 9V über eine Verpolschutz-Diode.
Damit zieht das ganze System 360mA bei 25% (0x20) PWM für die
Beleuchtung.
Edit: wenn ich die Beleuchtung abschalte zieht das System noch 185mA.
Mit so 10mA für die 5V Seite liefert der 3,3V Stepdown gerade so um
500mA um das Display zu versorgen.
Die Hintergrund-Beleuchtung läuft gerade direkt mit den 9V (oder 8,xV
nach der Diode) und davon werden noch 3,3V per Schaltregler für das
Display und 5V per LDO für mein Controller-Board erzeugt.
Die nächsten Versionen von meinem Display-Adapter und Controller-Board
mit Display-Anschluss werden wohl einen 9V Step-Down und einen 3,3V
Stepdown haben.
Den Pixel-Clock habe ich von 72MHz auf 71MHz runter gedreht, sind immer
noch 60 FPS, rechnerisch sollten das 58,58 FPS sein.
Das "Frequency" in der Anzeige ist der Takt mit dem der BT817 selber
läuft.
Jetzt läuft erst mal der nächste Testdruck für das Gehäuse dazu - 5h.
Edit 2: ich musste die Hintergrundbeleuchtung auf 0x10 runter drehen,
die Leuchtkachel ist mir am Schreibtisch echt zu heftig.
Das sind dann noch 270mA aus 9V.
Rudolph schrieb:> Vielleicht sollte ich mir mal einen Teensy 4 zulegen.
Unbedingt!!!! Ich habe hier noch einen liegen...würde ich Dir
spendieren....
Die Antwort auf meine Frage im BRT
Forum...ist...ja...etwas...ähm...naja...
Guten Tag,
Viele Danken für ihren Arbeit an diese Library ! Einschuldigung, mein
Deutsch ist ein bisschen schwach, so ich will auf Englisch weiter
schreiben.
I am currently working on the RiTFT-35-FR (BT816) from Riverdi with a
Teensy 3.5 and your library.
I now have good results with the display, but still runs into somes
issues.
As it could help someone, I will first give some infos about what I did
and the issues I had:
1) I am having good results with the EVE_EVE3_35 configuration, and
since it is marked as untested in EVE_config.h, I am sure you would be
happy to know ;)
2) At first I could not display anything due to SPI transmissions errors
using Teensy 3.5, while it was totally fine with an Arduino Nano.
I found that using terminating resistors on signals generated by Teensy
(SCK and MOSI) solved this. Currently using 30 Ohms, but it seems the
value depends on the length of the wires.
From what I read, it seems like a common issue while using SPI with a
Teensy.
Now, I still sometimes encounter unstabilities while communicating with
the BT816,
so I tried to lower the SPI clock frequency as much as I could, but I
can't go below circa 500kHz...
What happens next is that I am still partially able to write and read
registers, but nothing appears on the screen
I had better read/write performances by using TFT_init() at higher SPI
speed, and then lowering it, but still nothing on the screen.
I verified the frequency with an oscilloscope, and everything seems
fine.
Can't tell whether the BT816 or Teensy is the issue here.
Do you have any info on that ?
Guten Abend,
Arnaud
Thank you and Englisch is just fine.
While updating all the different platforms in PlatformIO I checked the
parameter sets for RiTFT-35 and EVE3-35 in my spreadsheet.
And while most of the parameters are the same or close enough,
a couple are not the same.
CLKPOL and SWIZZLE are different.
I'll check with the datasheet.
And as I also noticed now, there is no RiTFT-35 profile in EVE_config.h,
yet.
Regarding the Teensy 3.5, did you add anything for it to EVE_target.h /
EVE_target.c? Or are you just using the default Arduino target?
As so far with the Teensy 4.1, I can add it to the platformio.ini and
check if it compiles, but I can not test it.
Which pins are you using for what?
I just added
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO
as a first step.
The platformio.ini has a teensy35 target and while it already build with
the default Arduino setup I went ahead and changed EVE_target.h and
EVE_target.cpp to put ARDUINO_TEENSY35 on the same target as
ARDUINO_TEENSY41 which should enable DMA.
And of course EVE_config.h has a profile for RiTFT35 now.
Please test.
For some strange reason the nucleo_f446re target no longer builds after
I updated the platform to the latest version.
----
Processing nucleo_f446re (platform: ststm32; board: nucleo_f446re;
framework: arduino)
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------------------------Verbose mode can be
enabled via `-v, --verbose` option
CONFIGURATION:
https://docs.platformio.org/page/boards/ststm32/nucleo_f446re.html
PLATFORM: ST STM32 (14.0.0) > ST Nucleo F446RE
HARDWARE: STM32F446RET6 180MHz, 128KB RAM, 512KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic,
cmsis-dap, jlink)
PACKAGES:
- framework-arduinoststm32 4.20000.210601 (2.0.0)
- framework-cmsis 2.50700.210515 (5.7.0)
- toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
Converting src.ino
ImportError: cannot import name 'IS_WINDOWS' from 'platformio.compat'
(c:\users\ich\.platformio\penv\lib\site-packages\platformio\compat.py):
File
"C:\users\ich\.platformio\penv\lib\site-packages\platformio\builder\main
.py", line 177:
env.SConscript("$BUILD_SCRIPT")
File
"C:\Users\Ich\.platformio\packages\tool-scons\scons-local-4.1.0\SCons\Sc
ript\SConscript.py", line 591:
return _SConscript(self.fs, *files, **subst_kw)
File
"C:\Users\Ich\.platformio\packages\tool-scons\scons-local-4.1.0\SCons\Sc
ript\SConscript.py", line 280:
exec(compile(scriptdata, scriptname, 'exec'),
call_stack[-1].globals)
...
----
Whatever, not my fault, nothing I did there, I hope this gets fixed.
Rudolph schrieb:> Der Teensy 4.1 ist schon im Versand
Ok...super, wäre schön wenn Du von Deinen Erfahrungen hier berichten
könntest. Aus dem Beitrag von Amaut könnte man ja auch schliessen, das
es hier ein Problem gibt...
@Amout: The resistor of 30Ω you are using is connected in serial to the
signal line or signal to ground?
Rudolph R. schrieb:> Regarding the Teensy 3.5, did you add anything for it to EVE_target.h /> EVE_target.c? Or are you just using the default Arduino target?
I was using the default Arduino target, and changed a few pin
definitions to suit my needs:
- PDN changed from 8 to 9
- CS changed from 9 to 10
- SPI Clock Output changed from 13 to 14 (specific to Teensy boards)
Rudolph R. schrieb:> The platformio.ini has a teensy35 target and while it already build with> the default Arduino setup I went ahead and changed EVE_target.h and> EVE_target.cpp to put ARDUINO_TEENSY35 on the same target as> ARDUINO_TEENSY41 which should enable DMA.>> And of course EVE_config.h has a profile for RiTFT35 now.>> Please test.
I implemented your changes into my code, and it seems to work.
First took the new screen profile, and then changes in EVE_target.cpp
and EVE_target.h.
I can't confirm that I have better performances, but it seems to work as
good as before.
Spyy schrieb:> @Amout: The resistor of 30Ω you are using is connected in serial to the> signal line or signal to ground?
I put those resistors in series to the signal line, and placed as close
as possible to the source of the signal
Now I am mildly confused. :-)
What about:
>What happens next is that I am still partially able to write and read>registers, but nothing appears on the screen>>I had better read/write performances by using TFT_init() at higher SPI>speed, and then lowering it, but still nothing on the screen.
Does it display anything now?
>I can't confirm that I have better performances, but it seems to work as>good as before.
Going from no output to no output would also mean it is "as good as
before" :-)
>I was using the default Arduino target, and changed a few pin>definitions to suit my needs:>- PDN changed from 8 to 9>- CS changed from 9 to 10>- SPI Clock Output changed from 13 to 14 (specific to Teensy boards)
How can SCK0 be changed to pin 14?
Have you tried to directly run my simple demo?
CS is set to pin 9 now in line 1474 though.
I just checked https://www.pjrc.com/teensy/pinout.html
And according to this, SCK is on 13 for Teensy 3.5 and 4.1.
The several CS0 pins must be for Hardware-Controlled chip-select but I
am directly using an I/O pin, CS = 10 and PDN = 9 is just fine.
What I really do not like about the Teensy, now that I have seen this,
the SCK pin is not next to MISO and MOSI but on the opposite side.
And that there is a LED with a 470R resistor connected to SCK, looks
like one of the first things I will do with the Teensy 4.1 is to remove
the resistor as changing the pin for SCK0 does not seem to be an option.
Rudolph schrieb:> Going from no output to no output would also mean it is "as good as> before" :-)
I should have been more precise about the results, sorry about that :D
It does display what I want on the screen (basically some static text
with variables), but I still run into the SPI frequency issue : low
frequency = no output. So I use 1MHz at the moment.
I also suffer from screen freezes after some time, and am currently
investigating this... Do you have any recommendations for monitoring the
screen status ?
SCK0 (and other SPI-involved pins) can be switched using
SPI.setSCK(_pin_num) which is part of the SPI library, and works for all
compatible alternate pins
(see https://www.pjrc.com/teensy/td_libs_SPI.html for more info)
Rudolph schrieb:> Have you tried to directly run my simple demo?
I tweaked some parameters to fit my pin definitions, and it failed. I
did not investigate any further for the moment. It is on my todolist, I
can retry to do that tomorrow.
Rudolph schrieb:> What I really do not like about the Teensy, now that I have seen this,> the SCK pin is not next to MISO and MOSI but on the opposite side.> And that there is a LED with a 470R resistor connected to SCK, looks> like one of the first things I will do with the Teensy 4.1 is to remove> the resistor as changing the pin for SCK0 does not seem to be an option.
I totally agree, it is quite a mess to use. And this LED is one of the
reason I changed it to pin 14.
My Teensy 4.1 arrived so later I am doing some hands-on experiments with
it. :-)
My basic demo shows the time it takes for a display-refresh:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg
That is without DMA.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/EVE2-50G_ATSAMC21.jpg
And this is with DMA.
The "Bytes" is the number of bytes sent for a display-refresh and
without DMA this information is not available.
I am always using the same setup across platforms, my main.c or src.ino
is executing the display functions in a 5ms intervall.
The touch and some debug-information is read every time.
The display-refresh is done every fourth time for 20ms refresh.
So the demo sends 224 bytes and the resulting display-list hast a length
of 784 bytes, a little less without DMA.
The 51µs are not the time it takes to send 224 bytes, this is only the
time the controller is busy preparing the DMA buffer.
At 8MHz the SPI is busy for annother 224µs, at 1MHz for annother 1,8ms.
And without DMA this takes longer since there are pauses between the
bytes depending on the speed of the controller and the SPI
implementation.
The touch-function is checking if a transfer is ongoing but if there
would be more bytes to be send at a low speed the first thing that would
happen is that the next reading of the touch events would be skipped.
So you need to keep an eye on the amount of bytes send, the resulting
display-list needs to stay below 8k and the packets need to be
transferred in time.
This is why I never put the logic-analyzer out of reach. :-)
My Teensy 4.1 arrived so later I am doing some hands-on experiments with
it. :-) => Great!!!!
And if you have time can you please code this into the EVE_Init() near
the end of function and report the results :)) with the setting
EVE_cmdWrite(EVE_CLKSEL,0x46);
Write the EVE stats:
uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
delay(1000);
uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
Serial.print("EVE clock: ");
Serial.println(eveClockNew - eveClockOld);
Do you have a BT817 or a BT818 ?
Arnaud S. schrieb:> I also suffer from screen freezes after some time, and am currently> investigating this
This is exacly the reason why i am struggling with my setup too...with
Teensy 4.1
I am using:
-SPI: 20 Mhz
-DMA for SPI
-Pins: standard for SPI channel 0 (10, 11, 12, 13)
-Display list well below 8k (approx. 3700 bytes)
-Refresh rate of display 102 Hz
With 20 ms data refresh rate to BT818 it stalls immediately (SPI LED is
full on display freezes), 21 ms works.
Tried to tweak the SPI speed to 10 Mhz or lower makes no difference
Well, what shall I say, there might be an issue with the hardware as it
only started to work after I re-connected the Logic Analyzer.
It pretty much worked right out of the box including DMA.
I only changed CS to 10 and PD to 9.
I also tried a couple of different SPI speeds now, default is 8MHz,
1/2/4/6 MHz work just fine albeit not necessary at the exact select
frequency.
6MHz is more like 6.25MHz.
Increasing the speed after TFT_init() also works, 10/12/16/20 MHz, no
issue.
Setting up 100MHz by accident did not work though. :-)
Going slower than 925kHz is not working in the sense that the Teensy 4.1
will not clock the SPI any slower than that.
I tried 500k, 200k, now 800k, the result is 925kHz.
So well, there are limitations what the chip can do, not an issue.
Hmm, I just tried to disconnect the Logic Analyzer and I need to keep it
connected to CS and SCK.
So I am left with a hardware issue in my setup and a couple of pF as
extra load seem to fix it.
The "shadow" on the display or rather the brighter area is just a
rolling shutter effect, I took three pictures with my phone and between
these this is clearly mooving.
To confirm the Frequency and Frames/s measurement I just checked the 5ms
intervall derived from millis() with the logic-analyzer and the first
falling edge of CS from one block to annother.
And it is spot-on, 5,00032ms.
The is 64µs more every second if this is stable which at least partly
accounts for the little more than 72000000.
Oh yes, before I even connected the Teensy 4.1 for the first time I
removed the LED resistor R1.
Ich habe jetzt auf das RVT101H gewechselt, 10,1", 1280x800, BT817.
Clock ist auf 20MHz hoch gedreht, CS und SCK sind immer noch mit dem
Logik-Analzyer verbunden.
Spyy schrieb:> And if you have time can you please code this into the EVE_Init() near> the end of function and report the results :)) with the setting> EVE_cmdWrite(EVE_CLKSEL,0x46);>> Write the EVE stats:> uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);> delay(1000);> uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);> Serial.print("EVE clock: ");> Serial.println(eveClockNew - eveClockOld);
I changed it in tft.cpp like this:
uint32_t clock_test;
void TFT_init(void)
{
if(EVE_init() != 0)
{
uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
delay(1000);
uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
Serial.print("EVE clock: ");
Serial.println(eveClockNew - eveClockOld);
clock_test = eveClockNew - eveClockOld;
It compiles, it uploads but I get nothing on the console.
Yes, I also added "Serial.begin(9600);" in src.ino.
So I added that var to print it on screen.
EVE_cmd_text_var_burst(20, 160, 28, EVE_OPT_FORMAT, "Frequency:
%d",1,clock_test);
The output of this line is: "Frequency: 72003042"
And the measurement I am taking every second now and printing it to the
screen shows around 72002400.
So as promised, I retried your demo, only changed SPI SCK pin to 14, PDN
and CS, and it worked ! (see demo_result.png).
But only for a rather short duration, after which I ran into the same
issue as with my actual project : Screen freeze.
I began to monitor registers:
-CMD_READ and CMDB_SPACE to check if there was any issue with the
commands we sent
-CPURESET to check if the chip was still running.
I am using USB Serial to directly read the values, which are read and
sent every 500ms. Registers are read after display functions are
executed.
And my observations are similar for both the demo code and my project:
Everything starts fine and screen is displaying what it should :
CMDB_SPACE = 4092 so RAM_CMD is empty and every commands have been
executed
-CMD_READ != 0xFFF, so no coprocessor fault !
-CPURESET = 0, coprocessor is running
And then screen freeze,
-CMDB_SPACE != 4092 : RAM_CMD not empty
-CMD_READ != 0xFFF, still no coprocessor fault
-CPURESET = 0, coprocessor is still running
(see demo_registers_log.png : everything is fine for the first 4
readings, using your demo code)
It is interesting to see that in the case of my project (not the demo,
see own_project_OK.ng and ...NOK.png), CMDB_SPACE stays the same, and I
am pretty sure that I am not sending any commands between registers
readings*, so it seems the chip is not reading commands in RAM_CMD
anymore.
But that is my own interpreatation, what do you guys think about this ?
*using if(!EVE_busy()) at the beginning of my display function to avoid
that.
1000 thanks for your effords!!!
Rudolph R. schrieb:> The output of this line is: "Frequency: 72003042"
Boah....this is....what the helll...
Ok...the only difference to my setup is i am using a BT818 and no
external chrystal...
Arnaud S. schrieb:> But that is my own interpreatation, what do you guys think about this ?
I have also no explenation for this...can you print out the clock
frequency of your chip and the framerate of your screen?
The bahaviour of the registers before stalling here was the same you
see...my feeling is the same, writings to the fifo stop or
delays...whyever
I have SPI set to 20 Mhz, burst
LED to SCK still connected, standard pins 10, 11, 12,13
I have now 72 MHz with EVE_cmdWrite(EVE_CLKSEL,0x10); (which is an
illegal setting, but it seems to work), and set the framerate to 102Hz,
then i can run the demo with update rate of approx. 10 ms, but only with
approx. 300 bytes of display list (i modified the demo a bit, i have no
touch)
At what speed are you running this?
This very much looks like a hardware issue, also what Spyy reports.
Your Riverdi Click board is nothing but a breakout board, it is
completely passive and not buffered.
So the SPI is only driven by the MK64FX512VMD12 on your Teensy 3.5.
The drive strength for this 3.3V controller should not exceed 4mA, if
it is configured to maximimum drive strength to begin with.
Same with the Teensy 4.1 and its IMXRT1062DVJ6A.
My display adapter board has drivers for all signals, one property of
these is that the ones I am using are 5V tolerant even though these are
powered with 3.3V, the other property is the decoupling from the
controller, there is less load on the lines for the controller and their
drive strength is a lot higher.
I have two 74LVC2G17 for SCK, MOSI, CS and PD plus one 74VHC1GT125 for
MISO.
I configured my Teensy 4.1 to 20MHz and tried to measure the lines with
an oscilloscope.
Well, tried, at 20MHz there is not much left to be measured.
And the CS line showed rather slow signal changes, even with no load
except the probe from the oscilloscope.
I tried to change the frequency but using Arduino 1.8.13 plus
Teensyduino resulted in no activity at all anymore on the SPI lines
despite compiling and uploading worked.
Next, where do you get the 3.3V from to power the display?
I have a 3,3V stepdown regulator on my adapter to power the logic and
the display module.
I can power the backlight from either the input voltage or from the
generated 3.3V.
For the RVT101H I am supplying my adapter with 9V and use that for the
backlight as well, most modules require a maximum backlight voltage of
5V though or are even locked into using the 3.3V for the logic supply.
Hallo Rudi,
es ist schon zum Verzweifeln. Ich bekomme das einfach nicht hin. Am
liebsten möchte ich einen Arbeitstag zu Dir kommen und die wichtigsten
Punkte Stück für Stück durchgehen... Wie hoch ist Dein Tagessatz???
Nachdem nun also die FTDi-Animation funktioniert, möchte ich mal einen
Buttom setzen. Ich sende an Adresse REG_CMDB_Write:
4 Byte 0D : FF : FF : FF (CMD_BUTTON)
4 Byte X und Y -Koordinaten (0 : 200 : 0 : 100)
4 Byte Höhe x Breite (0 : 50 : 0 : 30)
2 Byte Font (0 : 31) - richtige Reihenfolge???
2 Byte Option (0 : 0) - erst mal
4 Byte Text mit "Null" am Ende ("O" : "K" : "Ausrufezeichen" : 0)
Gesamt 20 Byte, also ein Vielfaches von 4.
Ich habe schon verschiedene Varianten (z.B. bei den Koordinaten und/oder
Höhe und Breite) durch probiert, verschiedene Reihenfolgen der beiden
Bytes z.B. Hilft alles nichts. Oder müssen die "Nullen" bei Fonts und
Option vielleicht mit FF aufgefüllt werden, oder, oder ?
Was mache ich hier wieder alles falsch ?????????????????
Bernd I. schrieb:> Am liebsten möchte ich einen Arbeitstag zu Dir kommen und> die wichtigsten Punkte Stück für Stück durchgehen...> Wie hoch ist Dein Tagessatz???
Das will ich gar nicht wissen, nicht-selbständig zu arbeiten hat den
deutlichen Vorteil das ich mich nur minimal mit dem Finanzamt
herumärgern muss. :-)
Bernd I. schrieb:> Nachdem nun also die FTDi-Animation funktioniert, möchte ich mal einen> Buttom setzen. Ich sende an Adresse REG_CMDB_Write:> 4 Byte 0D : FF : FF : FF (CMD_BUTTON)> 4 Byte X und Y -Koordinaten (0 : 200 : 0 : 100)> 4 Byte Höhe x Breite (0 : 50 : 0 : 30)> 2 Byte Font (0 : 31) - richtige Reihenfolge???> 2 Byte Option (0 : 0) - erst mal> 4 Byte Text mit "Null" am Ende ("O" : "K" : "Ausrufezeichen" : 0)> Gesamt 20 Byte, also ein Vielfaches von 4.
Sowas muss ich inzwischen auch nachschauen, wenn nur irgendwer eine
Library für sowas schreiben würde... :-)
Meine Funktion dazu sieht so aus:
Das eve_begin_cmd() setzt CS, sendet die Adresse, sendet das Kommando,
soweit nichts neues.
Also bei den Daten das niederwertigste Byte zuerst.
0x0d 0xff 0xff 0xff
0xc8 0x00
0x64 0x00
0x46 0x00
0x28 0x00
0x1c 0x00
0x00 0x00
0x4f
0x4b
0x21
0x00
Ja, Breite und Höhe habe ich angepasst und einen kleineren Font
verwendet.
Das passte nämlich nicht auf den kleinen Button. :-)
Und der Text ist eine Folge von Bytes.
Hmm, wie sieht das eigentlich aus wenn einen UTF-8 Font verwendet und
auf dem Button "nö!" steht?
So: 0x6e 0xc3 0xb8 0x21 0x00 0x00 0x00 0x00
Also am Ende vom String steht immer 0x00 und die nächsten drei 0x00 sind
zum Auffüllen bis zum nächsten 32-Bit Wort.
Im Prinzip habe ich es schon so gemacht, nun aber noch einmal penibel
alles genau so eingegeben, wie Du es aufgeschrieben hast. Geht dennoch
nicht.
Ich denke das Problem ist folgendes (und ich oute mich jetzt mal wieder
ein bisschen):
Ich weiß nicht einmal, was ich alles eventuell zuerst noch definieren
muss. Wie gesagt, bisher habe ich ja ohne Co-Prozessor gearbeitet. Und
dabei habe ich es nicht einmal geschafft, den Bildschirm am Beginn zu
löschen (mit RGB = 1,1,1 und bCLEAR - hier habe ich nur senkrechte bunte
Streifen). Das habe ich seit Jahren ignoriert, indem ich gleich zu
Beginn (nach der Initialisierung des Display) dann ein RECT in der Größe
des Display setze (bzw. mehrere RECTS stets um ein Pixel kleiner werdend
mit dunkler werdender Farbe, so dass sich ein Bildschirm mit
"beleuchteten" Rand ergibt (siehe Anhang). So beginnt jeder
Bildschirm-Aufbau und dann folgend die gewünschten Primitives. Mit
diesen Datenblättern, die einfach so chaotisch aufgebaut sind, habe ich
so meine Probleme. Vor einem halben Jahr habe ich zum ersten mal einen
LED-Treiber (IS31FL3737) in Betrieb nehmen wollen. Der kann 144 Einzel-
bzw. hier 48 RGB in einer 12x12 Matrix ansteuern. Funktioniert nun
super, NACHDEM ich mir ein Demo-Board (was es zum Glück dafür gab)
kaufte und dort die I2C-Schnittstelle mitgelesen hatte. Das Datenblatt
passt genauso in diese Kategorie: Schlimmer geht's nicht. Das hätte ich
ohne das Board nie herausgefunden.
Naja und so habe ich mir meine Bibliothek für Buttons usw. geschaffen.
Ich gebe nur noch gegebenenfalls die Koordinaten ein und lasse dann das
Unterprogramm ausführen und habe auch 3D-Effekte und Farben, wie ich es
will, die Tasten "versenken" sich beim Betätigen. So sieht eben auf dem
Foto z.B. meine alpha-numerische Tastatur aus (ohne Co-Prozessor).
Zurück zur eigentlichen Sache:
Wenn ich zuerst MEIN Bildschirm (wie Foto - nur das Grün) auf
herkömmliche Art setze und dann die Animation starte - das funktioniert.
Nun passierte beim Experimentieren folgendes: Nach 3 Sekunden (die ich
einfach warte bis zum Ende der Animation) gab ich mal versuchsweise den
Befehl: CMD_DLStart und dann den Buttom-Befehl. Da spielte die
FTDi-Animation ein 2. mal ab!!! Aber kein Buttom kommt.
Mir ist das ganze Prinzip einfach noch völlig unklar: Muss ich den
gesamten Bildschirm mit 15 Elementen in einem "Atemzug" an den
Reg_CMDB_Write senden, oder kann ich hier auch anhängen, oder sende ich
nacheinander die einzelnen Elemente , oder, oder. Oder muss der
Reg_CMDB_Write etwa gemäß den schon gesendeten Bytes aufaddiert werden
(Reg_CMDB_Write + Anzahl schon gesendeter Bytes)? Was muss am Beginn
noch definiert/gesetzt werden (außer alle Register für den richtigen
Betrieb des Display natürlich)? Also Du merkst: Grundsatzfragen. Wenn
ich nicht jetzt in diesem Zugzwang wäre, Bitmaps darstellen zu müssen,
würde ich mir diesen ganzen Ärger nicht antun. Habe auch schon das Netz
durchforstet, aber eine andere Hilfe, als dieses Forum und solch einen
Spezialisten, wie Dich, habe ich nicht gefunden.
Bernd I. schrieb:> Nach 3 Sekunden (die ich> einfach warte bis zum Ende der Animation) gab ich mal versuchsweise den> Befehl: CMD_DLStart und dann den Buttom-Befehl. Da spielte die> FTDi-Animation ein 2. mal ab!!! Aber kein Buttom kommt.
Das ist seltsam, wenn das wirklich kein CMD_LOGO war muss das noch
irgendwo im Speicher gewesen sein.
> Mir ist das ganze Prinzip einfach noch völlig unklar: Muss ich den> gesamten Bildschirm mit 15 Elementen in einem "Atemzug" an den> Reg_CMDB_Write senden, oder kann ich hier auch anhängen, oder sende ich> nacheinander die einzelnen Elemente , oder, oder.
Die Kommandos können alle einzeln geschickt werden, das hat allerdings
den Nachteil das man auch jedes Mal die 3-Byte Adresse für
Reg_CMDB_Write senden muss.
Das geht auch in kleinen Kommando-Gruppen oder eben als komplettes
Paket.
Ich mache das für gewöhnlich als ganzes Paket, zum einen geht das am
schnellsten, zum anderen benutze ich ohnehin vorzugsweise DMA.
> Oder muss der Reg_CMDB_Write etwa gemäß den schon gesendeten> Bytes aufaddiert werden> (Reg_CMDB_Write + Anzahl schon gesendeter Bytes)?
Nein, das ist das tolle an REG_CMDB_WRITE, einmal als Adresse angeben am
Anfang des Transfers und für zumindest die nächsten 4k am Stück passiert
alles automatisch.
> Was muss am Beginn> noch definiert/gesetzt werden (außer alle Register für den richtigen> Betrieb des Display natürlich)? Also Du merkst: Grundsatzfragen.
Glaub mal nicht, dass ich mich damit nicht herum schlagen musste. :-)
Eine Display-Liste mit dem Coprozessor zu erstellen ist ja erstmal nicht
anders als direkt in den Speicher der Display-Listen zu schreiben.
Es gibt eben am Anfang das CMD_DLSTART was nichts anderes macht als dem
Co-Prozessor zu sagen, lege mal eine Display-Liste an.
Das DL_DISPLAY am Ende ist ja nichts weiter als eine Nullbyte-Kennung
für die Raster-Einheit das die Liste da zu Ende ist, das kennst Du ja
auch schon.
Und CMD_SWAP ist dann als letzes auch nichts anderes als DLSWAP_FRAME
direkt in das REG_DLSWAP Register zu schreiben, nur weiß der
Co-Prozessor damit dann auch, dass das alles war für die Display-Liste.
Nach dem CMD_DLSTART habe ich immer:
(DL_CLEAR_RGB | WHITE)
(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG)
TAG(0)
Wobei TAG(0) eigentlich überflüssig sein sollte, aber ich habe keine
Idee mehr wann und warum ich das da reingesetzt habe und es funktioniert
so. :-)
Als nächstes benutze ich CMD_APPEND und das ist das erste spezielle
Kommando, damit kopiert der Co-Prozessor ein zuvor vorbereitetes
Fragment Display-List aus RAM_G in die neue Display-Liste, da packe ich
immer alles rein was ich bei einem Bildwechsel nicht ändert.
Naja, und so weiter, man bekommt mit dem Co-Prozessor einfach mehr
Funktionen, von den Display-Listen Kommandos die einfach nur kopiert
werden braucht man aber dennoch reichlich.
> Wenn ich nicht jetzt in diesem Zugzwang wäre,> Bitmaps darstellen zu müssen,> würde ich mir diesen ganzen Ärger nicht antun.
Also eigentlich braucht man dafür den Co-Prozessor nicht, das ist
nicht einfacher.
Statt CMD_SETBITMAP kann man das auch über die Display-Listen Kommandos
machen, das ist mit CMD_SETBITMAP nur bequemer.
BITMAP_LAYOUT, BITMAP_SIZE, BITMAP_SOURCE, etc.
Dann braucht man ein (DL_BEGIN | EVE_BITMAPS), VERTEX2F und DL_END.
Buttons gehen auch "von Hand", wenn man viel braucht fressen die als
CMD_BUTTON ohnehin schnell die Display-Liste.
Aber die Widgets zu ersetzen wäre mir echt zu anstrengend.
Ganz vorne dabei CMD_TEXT und CMD_NUMBER.
> Habe auch schon das Netz> durchforstet, aber eine andere Hilfe, als dieses Forum und solch einen> Spezialisten, wie Dich, habe ich nicht gefunden.
Ich bin dann mehr auf der technischen Seite unterwegs, was bringt die
Dinger zum Ticken, SPI, Register, Hardware und so.
Auf der Anwendungsseite habe ich dann nicht nur zu wenig konkrete
Projekte und mache mir vermutlich auch oft das Leben zu schwer durch die
Art und Weise wie ich meine GUIs gestalte, ein paar Sachen die EVE kann
sind dann auch weitgehend an mir vorbei gegangen, vor allem die ganzen
am Rande erwähnten Open_GL Features, Alpha-Blending, Scissors, die
Transformations-Matrix. Auch zum Beispiel wofür EDGE_STRIPs gut sein
sollen.
Oder wenn ich in die Bitmap-Formate rein schauen, da gibt es einige die
ich noch nie benuzt habe. Text8V8, Bargraph, Paletted.
I had some issues with my jumper wires on friday and today I crimped a
bunch of new ones.
I just reconnected the RVT101 to the Teensy 4.1 and took the attached
trace with the Logic 2.3.28 software von Saleae.
This inludes the complete initialisation, the reading of REG_CLOCK with
the one second delay, upload of the two images and the first four frame
updates.
I am using PlatformIO and it is updated, this is the output
from the build:
> Executing task: C:\Users\Ich\.platformio\penv\Scripts\platformio.exe run
--target upload --environment teensy41 <
Processing teensy41 (platform: teensy; board: teensy41; framework:
arduino)
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------------------------Verbose mode can be
enabled via `-v, --verbose` option
CONFIGURATION:
https://docs.platformio.org/page/boards/teensy/teensy41.html
PLATFORM: Teensy (4.12.0) > Teensy 4.1
HARDWARE: IMXRT1062 600MHz, 512KB RAM, 7.75MB Flash
DEBUG: Current (jlink) External (jlink)
PACKAGES:
- framework-arduinoteensy 1.153.0 (1.53)
- tool-teensy 1.152.200516 (1.52)
- toolchain-gccarmnoneeabi 1.50401.190816 (5.4.1)
Converting src.ino
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 89 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <SPI> 1.0
Building in release mode
Compiling .pio\build\teensy41\src\src.ino.cpp.o
Linking .pio\build\teensy41\firmware.elf
Building .pio\build\teensy41\firmware.hex
Checking size .pio\build\teensy41\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project
Inspect"
RAM: [= ] 10.3% (used 53940 bytes from 524288 bytes)
Flash: [ ] 0.4% (used 34176 bytes from 8126464 bytes)
Configuring upload protocol...
AVAILABLE: jlink, teensy-gui
CURRENT: upload_protocol = teensy-gui
Uploading .pio\build\teensy41\firmware.hex
========================================================================
======= [SUCCESS] Took 10.08 seconds
========================================================================
=======
Environment Status Duration
------------- -------- ------------
teensy41 SUCCESS 00:00:10.080
========================================================================
======== 1 succeeded in 00:00:10.080
========================================================================
========
And nice, there was an update for STM32 and it is building again:
Environment Status Duration
------------------------- -------- ------------
uno SUCCESS 00:00:04.405
avr_pro SUCCESS 00:00:03.133
nano328 SUCCESS 00:00:03.130
adafruit_metro_m4 SUCCESS 00:00:21.480
samd21_m0-mini SUCCESS 00:00:08.109
ESP32 SUCCESS 00:00:14.847
ESP8266_d1_mini SUCCESS 00:00:11.637
nucleo_f446re SUCCESS 00:00:08.395
teensy41 SUCCESS 00:00:03.414
adafruit_feather_nrf52840 SUCCESS 00:00:11.694
bbcmicrobit_v2 SUCCESS 00:00:04.634
teensy35 SUCCESS 00:00:05.731
Super...Danke..40 MSamples...Hm...sieht doch vernünftig aus...also sind
ja ne Menge Daten, SPI hat 8 Mhz...? oder habe ich da was übersehen?
Ich hatte jetzt schon überlegt die Bustreiber einzubauen..
ich werde zunächst mal so eine Messung mit meinem China Logic Analyser
machen...und mal schauen/vergleichen
Hat er nach 3 Frames abgebrochen?
Ja, der SPI hat 8MHz und nein, das lief durch, ich habe nur vorne und
hinten kräftig was von den 4 Sekunden abgeschnitten die ich
aufgezeichnet habe.
Was ich vergessen habe, ohne Logic-Analyzer läuft es immer noch nicht,
aber ich musste jetzt nur CS anschließen damit es läuft.
Warum verstehe ich jetzt aber nicht, CS ist schließlich praktisch
statisch und laut Datenblatt muss CS bei 3,3V nur 3ns vor der
Clock-Flanke runter gehen. Gemessen habe ich in dem Trace als kleinstes
110ns.
Das läuft bei 1MHz auch nicht besser, der Teensy ist soweit eine ganz
schöne Mimose. :-)
Und gerade noch mal ausprobiert, das läuft so auch bei 1MHz, 10MHz und
20MHz.
Auch schneller, mit dem Einstellen ist das nur so eine Sache, und mit
dem Messen.
Im Moment läuft es gerade mit 25MHz, eingestellt sind 24MHz.
Also inklusive Touch.
Wenn ich den Logic16 auf 2 Kanäle stelle kann ich 100MBit/s abtasten,
aber natürlich ist das auch erheblich zu wenig, das reicht ja nicht mal
um die 8MHz sauber zu messen.
Nun ja, die Daten sauber lesen zu können ist wichtiger als für jeden
Clock die Länge auf 1ns genau zu haben. :-)
Ich fände da mal eine Tabelle interessant was der Controller auf dem
Teensy für den SPI überhaupt einstellen kann.
Bei 4MHz braucht der komplette Refresh 723µs bei 320 Bytes.
Also könnte das 1370 Bytes lange werden bevor die 5ms um sind.
Angehängt sind 4s einfach mal so zwischendurch aufgenommen bei 4MHz.
Das lief vorher eine Weile, das läuft jetzt immer noch.
Ich habe den Teensy 4.1 heute noch mal an das Oszi gehängt.
Und die 2MHz waren ganz schön rund, so am Teensy gemessen.
Beim Chip-Select habe ich die Anstiegs- und Abfall-Zeiten gemessen,
die lagen bei etwa 50ns, dabei war die einzige "Last" auf der Leitung
der Tastkopf und ein 10k Pullup gegen 3,3V.
Sind bei dem Teensy 4.1 per Default die Drive-Level auf die kleinste
Stufe eingestellt?
Thread beobachten
Seitenaufteilung abschalten
