Die Bibliothek organisiert ihre Framebuffer exakt so, wie die Displays angesprochen werden, und das sind eben 16 (4 Adress-Bits) lange Pixel-Zeilen pro RGB-Ausgang. (32 mit zusätzlichem E-Pin, daher kommen deine 64)
Wenn du die Panels anders anordnest, wirst du einiges am Code ändern müssen (updateMatrixDMABuffer(x,y,...) als Startpunkt), oder selber eine Koordinaten-Umrechnung in deinem Application-Code machen müssen.
danke für die Erklärung und den Einstiegspunkt. Ich nutze das Beispiel mittlerweile übrigens mit 4 bit Farbtiefe statt 8 damit ich 12 Panel betreiben kann.
Ich habe in der von dir erwähnten Funktion mal y_coord und x_coord direkt bei der Übergabe getauscht:
Oben links auf meinem Großdisplay Testaufbau lesbar stehen. Zwei Pixel von links, einen von oben Abstand, wie erwartet. Also quer zur ursprünglichen Ausrichtung.
Natürlich komme ich nun in beide Richtungen (x und y) nicht über die 64 Pixel hinaus. Im Hintergrund ist nach wie vor eine 768x64 (Breite x Höhe) Pixel Matrix. Ich würde ja nun entsprechend reagieren wollen, wenn also für y ein Wert größer 64 kommt, würde ich 64 abziehen und x so verändern dass ich auf dem Panel oben rechts lande, das geht aber nicht. Ich gehe davon aus, dass die Koordinate Höhe>64 schon vorher irgendwo abgefangen wird...
Es ist zum greifen nah...
Am Rande noch:
Der gefüllte violette Kreis und die beiden "Boxen", Rechtecke bleiben wo sie sind, werden nicht beeinfluss, der blaue Kreis sowie die das "X" also die gekreuzten Linien wandern mit dem Text mit nach oben.
Ich habe die Probleme mit den Koordinaten nun gelöst. Ich habe dazu weitere defines für Koordinaten eingefügt, sodass das physikalische Display von dem logischen getrennt wird.
Zudem habe ich die Koordinatenumrechnung in der von Ernst benannten Funktion so aufgebohrt dass die Pixêl zum einen um 90° gedreht aufs Display geschrieben und auf die eine Hälfte rückwärts und auf beiden gespiegelt geschrieben werden.
Nun habe ich das gewünschte hochkante Display von 6x2 Modulen mit einer Auflösung von 128x384 RGB Pixeln mit einer Farbtiefe von sogar 12 Bit RGB, mehr als erwartet.
Es lässt sich Text in verschiedenen Größen sowie freie Linien und Kreise zeichnen, alles was ich für mein Projekt brauche.
Das einzige was nicht koordinaten-richtig ist, sind diese Funktionen:
dma_display->fillCircle()
dma_display->drawRect()
Warum auch immer, mein C++ ist über zwei Jahrzehnte her, ich kann den beim besten Willen nicht komplett lesen, manche Notationen sind mir wirklich entfallen :-) oder nicht bekannt.
Danke Ernst, du hast mir mit deinem kleinen Kommentar sehr geholfen!
Ps.: Die zweite entscheidende Stelle, neben der von Ernst erwähnten, ist im Headerfile:
Dort werden aus den festen Eigenschaften der verwendeten Module und der Anzahl der Module diese Beiden "Konstanten" erzeugt, die die Hardwarenahen Routinen nutzen um den Datenstrom für die Panel zu erzeugen.
Ich kämpfe gerade doch noch mit den Adafruit Anteilen, denn anscheinend durchlaufen nicht alle Routinen den von Ernst genannten Punkt auch nicht die drawLine Funktionen.
Ich bin bei Adafruit_GFX::writePixel(), die wiederum drawPixel aufruft, drawPixel scheint eine überladene (ich meine so nennt sich das doch) Funktion zu sein.
Wenn ich an der Übergabestelle zu drawPixel x und y tausche, dann betrifft es wieder den Text, aber nicht die dma_display->drawLine() Funktionen, was mich wirklich wundert als Cpp Laien.
Eine mit dma_display->drawLine() gemachte Linie, bleibt bis jetzt immer an Ihrer Stelle, wie landet die im Speicher? Jedenfalls nicht über die
Adafruit_GFX::writePixel()
Funktion, die die drawPixel() aufruft
Hat das was mit den Fast-Geschichten und dem NO_FAST_FUNCTIONS zu tun? Alles sehr verworren für mich, ich verliere dort die "Spur" bei virtual und inline Funktionen ... die Stelle zu finden wo ::drawPixel zum Speicher kommt.
hinzufügen, benötige dafür aber den GPIO21 und auch die 22.
GPIO22 wird jedoch bereits für das Panel verwendet, kann mir jemand sagen wie und ob überhaupt ich dass auf einen anderen Pin ändern kann für die Pixel Schnittstelle damit ich die I2C Schnittstelle für die rtc frei bekomme? Oder müsste dann in die Untiefen der DMA etc... eingegriffen werden?
Ist es sinnvoller eine I2C Software Lösung für die rtc zu nutzen? Wenn ja, welche?
hinzufügen, benötige dafür aber den GPIO21 und auch die 22.
der ESP32 kann den I²C-Bus auch auf (fast beliebige) andere Pins legen. 21 und 22 sind nur Defaults, wenn man nichts angibt.
Einfach Wire.begin mit zwei freien Pin-Nummern aufrufen, und darauf achten dass in der RTC-Library das nicht wieder zurückgeändert wird.
Auf dem ESP selbst gibt es ja keine Uhr in dem Sinn, oder? Sicher tausende über WLAN, NTP usw... aber eine interne die brauchbar genau (in meinem Fall ist es nur Taggenau über ein Jahr, genauer wäre schön) frei läuft...?
Hallo Ernst, kannst du mir ein brauchbares Datenblatt des ESP empfehlen, wo ich das sehen kann? Ich hatte derzeit echt Probleme etwas brauchbares zu finden. Beim PIC und auch beim Atmega gibts ja sehr schöne Blockschaltbilder im DB....
Sicher frei habe ich TX0,RX0,18,19,34,35 und die zwei.
Mir scheint, daß Arduino User häufig das Lesen von Datenblättern bewusst
vermeiden.
Da kommt der Arduino Bahsher wieder aus den Büschen gesprungen!
Schon mal dran gedacht, dass der übliche Arduino Anfänger total fachfremd ist?
Ihm/Ihr weiß nicht wo was steht, ob es das überhaupt gibt, wie man da ran kommt.
Ihm/Ihr ist wohl meist zwischen 14 und 74.
Hat evtl. massive Probleme englische Texte zu lesen/verstehen
Um deine Diskriminierabsicht zu unterlaufen, möchte ich dir mitteilen, dass erfahrene Arduino User durchaus in der Lage sind Dokus zu finden und zu lesen.
Es ist also ein Prozess, kein angenagelter Zustand.
(auch wenn dir das lieber wäre)
Und jetzt: Ab in die Ecke mit dir, und 2 Stunden schämen!
