Code redundance found

[mickpf]

Hello Rudolph,

I'm writing my own library for STM32H7 and the NHD-4.3-800480FT-CSXP-CTP display. I use the examples from Bridgetek as well as your FT800-FT813 library as a template. I noticed (among other things) that your code is redundant: the functions "EVE_start_command" and "EVE_begin_cmd" contain exactly the same code. Does it have a special reason?

Kind Regards, Michael

BTW: Do you speak German?

[RudolphRrr]

Mahlzeit! So um die andere Frage gleich zu beantworten. :-)

Die Funktionen EVE_start_command() und EVE_begin_cmd() waren etwas unterschiedlich, die Funktion EVE_start_cmd() hat in der V4 noch unterschieden ob sie jetzt im command-burst oder einfach so aufgerufen wurde. Die EVE_begin_cmd() war eigentlich nur für die ganzen Kommandos gedacht die nicht für Display-Listen sind.

Als ich die Display-Listen Funktionen in EVE_cmd_xxx() und EVE_cmd_xxx_burst() aufgeteilt habe wurde für die _burst-Funktionen nicht nur die if-Abfrage überflüssig, sondern auch gleich der ganze Funktions-Aufruf.

Inzwischen hat sich die V5 soweit als stabil erwiesen, dann werde ich die EVE_start_command() mal entfernen. Danke für den Hinweis!

[RudolphRiedel]

Ok, ist "gefixt". Interessanterweise wird das Programm dadurch nicht ein Byte kürzer.

[mickpf]

Es kommt auf das Zielsystem, den Compiler und die Compiler-Flags an. Nicht gleich verzagen... Im Grunde gibt es noch ein weiteres, größeres Code-Snippet, das aus meiner Sicht redundant ist: Die Übertragung von Blöcken und Strings. Da es aber immer etwas am Code zu verbessern gibt (Nobody is perfect), insbesondere, wenn der Code von anderen Entwicklern gebaut wurde, würde ich es nicht so eng sehen... Was mich persönlich etwas (negativ) überrascht: Sowohl die Beispiele von Bridgetek als auch deine Library implementieren keine Standardfunktionen wie das Zeichnen von Linien, Polygonen, Kreisen etc. Das macht mir höheren Aufwand für meine Library, an der ich sitze.

[RudolphRiedel]

Okay, ausprobiert habe ich das mit einem ATSAME51 im Microchip Studio, GCC 6.3 und -O2. Das liegt hier halt gerade mit Display dran. :)

Im Grunde gibt es noch ein weiteres, größeres Code-Snippet, das aus meiner Sicht redundant ist: Die Übertragung von Blöcken und Strings.

Da ist eine gewisse Redundanz, aber die Blöcke können praktisch beliebig groß werden, werden in Happen zu 3840 Byte aufgeteilt um den CMD-FIFO nicht zum Überlauf zu bringen und die Daten kommen aus dem Programm-Speicher des Controllers, wenn man etwa Bilder beim Programmstart an EVE schicken will. Ach ja, und es kommt da nicht so richtig auf die Geschwindigkeit an. Texte kommen dagegen eher aus dem RAM, sind in der Länge begrenzt und werden im Rahmen der Display-Listen Erzeugung verschickt.

Was mich persönlich etwas (negativ) überrascht: Sowohl die Beispiele von Bridgetek als auch deine Library implementieren keine Standardfunktionen wie das Zeichnen von Linien, Polygonen, Kreisen etc.

Sowas kann EVE ja auch im Grunde genommen nicht, also Linien schon und ausgefüllte Kreise und Rechtecke, das war es dann aber auch praktisch schon.

Mein Beispiel zieht ja auch eine Linie: EVE_cmd_dl(DL_COLOR_RGB | BLACK); EVE_cmd_dl(DL_BEGIN | EVE_LINES); EVE_cmd_dl(VERTEX2F(0,LAYOUT_Y1-2)); EVE_cmd_dl(VERTEX2F(EVE_HSIZE,LAYOUT_Y1-2)); EVE_cmd_dl(DL_END);

Es gibt Bitmaps, Points, Lines, Line_strip, mehrere Edge_strip und Rects. Kreise mache ich indem ich zwei Points übereinander lege, Rahmen mit zwei Rects. Die Rects, also Rechtecke, werden an den Ecken rund wenn man die Linien-Breite größer macht, damit bekommt man mit wenig Aufwand ganz nette Rahmen hin. Also man kommt da schon sehr weit ohne mit Pixeln um sich werfen zu müssen.

Ja, klar, man könnte eine Bitmap im Speicher definieren und da "von Hand" drin herum pixeln, für sowas ist EVE aber im Grunde genommen nicht gedacht und das ist im Vergleich sehr ineffizient. Solange man sich im Toolkit der Objekte bewegt die EVE kennt ist das alles sehr schlank und schnell. EVE zeigt ja auch nicht einfach nur ein Bild an an dem man herum manipulieren würde wie bei einem doofen LCD, das Bild wird Zeile für Zeile aus der Display-Liste aufgebaut.

Da haben mich die BT817 ein wenig enttäuscht, ich hatte schon auf weitere Funktionen gehofft, etwa Kreise und Polygone. Aber ich muss auch zugeben das ich z.B. Dreiecke dann eher nicht vermisse.

Die STM32H7 gibt es mit eingebauter Grafik-Engine, das ist einfach mal eine ganz andere Kategorie und für eine ganz andere Verwendung gedacht.

[mickpf]

Hallo Rudolph,

Wo ich Probleme habe: Warum gibt es sowohl DL- als auch CMD-Befehle, die jedenfalls auf den ersten Blick das gleiche tun? Z. B. DL_CLEAR, DL_CLEAR_COLOR_RGB, DL_COLOR_RGB und CMD_BGCOLOR, CMD_FGCOLOR. Ich finde, dass Bridgetek (oder FTDI) insgesamt mit dem Angebot an GL-Befehlen weit übers Ziel geschossen ist. Hier hätte man sich konzeptionell an irgend ein bereits vorhandenes Standard (OpenGL, OpenCL usw.) halten können. Jedefalls erscheint es mir sehr umständlich.

Wäre es möglich, dich direkt per E-Mail anzuschreiben/-sprechen, falls ich noch Fragen habe bzw. falls mein bescheidener IQ nicht "ausreicht", um den Inhalt von Datasheets, Manuals und Beispielen zu verstehen? Ausschliesslich im Zusammenhang mit dem FT81x.

Meine E-Mail lautet: mickpf.mw@gmail.com

Gruß Michael

[RudolphRrr]

Ich melde mich nachher mal von zu Hause.

[RudolphRiedel]

Alles mit DL ist direkt für die Display-Liste und CMD sind co-processor Kommandos.

Z. B. DL_CLEAR, DL_CLEAR_COLOR_RGB, DL_COLOR_RGB und CMD_BGCOLOR, CMD_FGCOLOR.

Die mache alle jeweils was eigenes.