Opensmart Display 2.4z Befehlssatz

Hi,
Tja so wie es ausschaut wird wohl kein Weg dran vorbei gehen das mal auf 
Steckbrett auf zu bauen und gucken was raus kommt. Erstmal Arduino Weil 
einfacher mit diesem Monitor Fenster und dann portieren auf stm32.

die resistiven Touchfolien liefern bei Druck einen Widerstand in X- und 
Y-Richtung. Ein Controller wie der XPT2046 der gerne auf diesen 
Displayboards verbaut wird, hat einen AD Wandler und liefert einen IRQ 
bei Druck und die XY Werte per SPI. Der AVR auf dem Board wird 
vermutlich selber die Koordinaten senden bei Touch Ereignis.

Johannes S. schrieb:
> Der AVR auf dem Board wird
> vermutlich selber die Koordinaten senden bei Touch Ereignis.

Denkbar... auch wenn das blöde ist, sowas ohne INT Leitung zu machen, da 
man ja so nicht unterscheiden kann. Den AVR kann man sogar neu 
bespielen, die Firmware wird sicherlich irgendwo rumfliegen, wenn die 
opensmart heissen:

https://drive.google.com/drive/folders/1ReWai0mdEofMkcXbM3ROxDt2Ya159-DG

Ich nagel den dann mal auf ein Testbrett. Die Dinger sind ja nicht 
billig, teurer als die normalen SPI Teile, dafür muss man sich nicht mit 
dem Treiber herum schlagen und hat keine Rechenleistung für das Display.

Ok,

so läuft es: Diese Displays müssen gepollt werden. Drückt man auf einen 
Punkt liefert eine funktion mytft.touch() 1 zurück. Danach kann man mit 
.getTouchX, getTouchY den Wert auslesen, dann geht .touch() auf 0 
zurück. Kalibration gibt es nicht. bzw muss man die wohl selbst 
schreiben.

Ansonsten spielt es wie es soll, Treiber ist sehr einfach... also 
benutzen wir es auch.

Christian J. schrieb:
> so läuft es: Diese Displays müssen gepollt werden.

soweit hatte ich mir das auch noch angesehen. touch() ruft allerdings 
nur checkFeedback() auf ohne vorher ein Abfragekommando zu senden. Wenn 
innerhalb von 5 ms nichts empfangen wurde, dann kommt checkFeedback mit 
0 und damit mit untouched zurück.
Das ist natürlich nicht sonderlich elegant wenn dein Ferrari 401 da mit 
100 MHz nur im Kreis rennt.
Wobei ich sowieso nicht verstehe warum du so ein Display mit 8 Bit 
Nadelöhr verwendest, wo du doch schon andere direkt am F103 laufen 
hattest. Da kann ein ILIirgendwas per SPI am F401 doch auch kein Problem 
sein.

Johannes S. schrieb:
> Wobei ich sowieso nicht verstehe warum du so ein Display mit 8 Bit
> Nadelöhr verwendest, wo du doch schon andere direkt am F103 laufen
> hattest. Da kann ein ILIirgendwas per SPI am F401 doch auch kein Problem
> sein.

Naja, ich habe auch eines mit DMA per SPI am Laufen und das spielt 
prima. Der Code kann auch 1:1 portiert werden, das ILI9341 ist ja an 
jeder Ecke zu haben.

Bloss für mein Bastelprojekt, ein 4 Gewinnt Spiel braucht es eh nur 
statische Grafiken. Maximal rutscht da ein Coin von oben durch und 
selbst der blinkt nur kurz auf, damit ich da Gitter nicht immer wieder 
neu zeichnen muss. Man kann wohl auch sog. Sprites hinterlegen wie beim 
C64.

Ein PacMan Spiel mit Computer Gegnern wäre schon aufwendiger aber das 
hat ein gewisser Uwe B schonmal gemacht, mit dem Disco Kit für den F429.

Wird auch nicht der F401 werden, ich habe mit jemand gesprochen, der das 
mal gemacht hat. Der Seeeduino Xiao, ein SAMD Cortex M0 mit 36kb reicht 
komplett aus die rekursiven Bäume zu bauen. Je tiefer die Bäume werden, 
desto mehr RAM. Bei einer Suchtiefe von 7 Zügen wären die 20kb erreicht. 
Das geht nicht-linear dann weiter.

Irre ist, dass ich im Code so Sachen wie int *** var gesehen habe, also 
Zeiger uf Zeiger auf Zeiger... da blickt dann keiner mehr durch.