Moin! Als neues Bastelprojekt habe ich mir mal ein 4 Gewinnt Spiel vorgenommen, welches auf einer MinMax AI basieren soll. In die Theorie muss ich mich noch einbarbeiten, hoffe mal ich kriege es auf einem Back Pill Board zum Laufen mit 96kb RAM. Arduino etc wird kein Thema sein, daher nutze ich auch nicht deren Libs. Als Display liegt hier vor mir ein sog. Opensmart, gesteuert über die UART. Drauf ist ein AVR, der die Befehle umsetzt in Gepixel. SD Karte inklusive. Ob das das Richtige ist muss ich noch sehen, ein ILI93xxx mit SPI habe ich auch noch und dafür habe ich schon Code geschrieben. Meine Frage ist, ob sich schon mal jemand damit befasst hat, denn das Chinesisch der Beschreibung ist teils unverständlich. Touchscreen: Was passiert da genau? Dass das Teil einen Touch hat vermute ich mal aber wie wird der angesteuert? Tippt man auf den Bildschirm schickt mir der die Koordinaten? Der einzige Satz der das Wort Touch überhaupt enthält ist der umkringelte.
Angehängte Dateien:
-
display.JPG
100 KB
Ich würde das ja so interpretieren, dass du als Response die Koordinaten des letzten Touch Events erhältst. x und y als uint16 in msb order. Oben steht ja Feedback, also wird das wohl das Display senden.
Da steht, du sollst ihm die Koordinate hinschicken und darüber richten, ob der Punkt berührt wurde. "Tell the touch value x and y, so you can judge witch pont is touched" Oder nich? Ich glaub das auch nicht. Man müsste ja in dauerschleife alle koordinaten senden und dann ein True oder False zurückbekommen. Die meinen sicher was anderes...
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.