Im Web tauchen immer wieder mal schöne (alte) Spiele auf, die auf einem Mikrocontroller laufen. Leider haben viele dieser Projekte das Manko, dass für die Hardware oft ein teures Discovery-Board mit bspw. STM32F4 oder gar STM32F7 benötigt wird (und das Discovery-Board das Display mitbringt). Für die AVR Controller gibt es etwas, das sich "Gamebuino" nennt und benutzt ein bekanntes s/w Display. Weil ich ein "verspieltes Kind" bin (und auch oft Anregungen für andere benötige) habe immer wieder mal ein Spiel als Projekt für den STM32 auf dem Tisch, welches mit absolut billigen Teilen funktionieren soll. Die preiswerteste Kombination ist das allseits bekannte BluePill-Board mit STM32F103 und einem 1,8" TFT-Farbdisplay mit einer Auflösung von 128x160 Pixeln. Mit diesem Display kann man schon einiges Anfangen. Mein spezielles Developmentboard besitzt leider nur 4 Tasten und so muß ein Kniff herhalten, um mittels 4 Tasten ein Spiel spielen zu können. Die Taste "buttonup" funkiert zum einen als Taster nach oben (wie man vermuten kann) und, bei schnellem Doppeldrücken (ähnlich einem Doppelklick bei der Mouse) ist das praktisch die "Enter-Taste". Das Projekt hier nun spiel Reversi auf dem Bluepillboard, an dem lediglich 4 Taster und ein preiswertes Display wie das hier: https://www.ebay.de/itm/1-44-1-8-5-7-Inch-Serial-SPI-TFT-LCD-Display-Shield-ST7735S-SSD1963-Module/292592540785?hash=item441fdfdc71:m:mpngspXM4niRJkdKaEqL8SA angeschlossen ist. Prinzipiell jedoch sind alle mir bekannten China-Displays betreibbar, dann jedoch muss in der Datei "tftdisplay.h" im Ordner ./reversi_stm32/inc angepasst werden. Hier kann der vom Display benutzte Controller ausgewählt werden. Funktionieren sollte das ganze mit folgenden Controllern: ILI9163, ST7735, S6D02A1, ILI9340 Sollten Farbfehler auftreten, so ist innerhalb von tftdisplay.h der Definewert "rgbseq" von 1 nach 0 zu ändern. ------------------------------------------------------- Das ganze Projekt ist ein libopencm3-Projekt. Die im Ordner angehängte Library ist in der Hinsicht abgespeckt, dass sie nur den STM32F103 unterstützt. Das macht das ganze in einer Hinsicht einfach zu handhaben, weil der komplette Ordner in ein Verzeichnis ausgepackt werden kann und alle Pfade schon stimmen. ------------------------------------------------------- Das ganze ist unter Linux entstanden und ein Compilergang wird mittels make all in Gang gesetzt. Ein im System installierter arm-none-eabi-gcc wird vorrausgesetzt. -------------------------------------------------------- Die KI des Spiels an sich ist für die Linuxkonsole geschrieben worden und ich habe diese nach einem STM32F103 portiert. Wer das Teil ausprobieren will: Viel Spaß damit JJ PS: auf Schwierigkeitsstufe "schwer" habe ich das Programm bis jetzt noch nicht geschlagen
Schön dass du dir soviel Arbeit gemacht hast. Aber lass dir sagen dass es eine grosse Unsitte ist Datensätze in eine *.h-Datei zu schreiben. Nein das tutet man nicht! Auch wenn es bei dir vielleicht zufällig funktioniert hat.
Da sind sie wieder, die Bedenkenträger.
Ich bin gerne "unsittig", und von mir aus auch gerne groß.
Wir bewegen uns hier nicht auf einem PC, Server, Großrechner oder
dergleichen, sondern auf einem Bare-Metall Controller ohne
Betriebssystem.
Es ist mir vollkommen egal, ob die Pixeldaten des Startbildschirms in
einer *.c Datei landet (die dann per Linker) hinzugebunden werden muß,
oder eben in einer *.h Datei.
Diese Diskussion wurde hier schon sehr oft geführt und es gibt
sicherlich gute Gründe, Datensätze NICHT in eine *.h Datei zu führen.
Es gibt aber eben manchmal auch Gründe das dennoch zu tun (auch wenn es
den Puristen 1000 mal nicht gefällt).
Die Daten des Startlogos werden nirgendwo anderst als in diesem einen
Projekt eingebunden werden und sie werden auch in keiner anderen Datei
verwendet werden.
Man hätte die Datei auch reversi_logo.scr (anstelle von reversi_logo.h)
nennen können und diese dann mittels "#include reversi_logo.src"
einbinden können. Wo ist der Unterschied? Einzig im Namen (und vllt.
noch im Ordner wo diese Datei gespeichert wird).
Mir ist, ganz ehrlich, das vollkommen Schnuppe. Wenn du das Spiel
spielen magst, benenne das von mir aus um.
Aber: Du hast Recht, "normalerweise" gehören Code in eine *.c Datei, die
hinzugelinkt wird, konstante Daten, die die C-Datei benötigt sollten, da
sie Code erzeugen, ebenfalls in einer *.c Datei landen, damit diese dann
im Compilat im Code-Segment sich wiederfinden.
Das tut eine Datei, bestehend aus Screenpixel auch: im Code-Segment
landen.
Im Übrigen ist es auch eine große Unsitte, gleich mit einer allerersten
Antwort die Stellen zu suchen, an denen man mäkeln kann und es ist eine
noch größere Unsitte, dieses anonym (als Gast) zu tun.
> Auch wenn es bei dir vielleicht zufällig funktioniert hat.
Und nein, das funktioniert nicht "zufällig", das funktioniert ganz
bewußt so. Die Auswertung meiner Daten geschieht mit Funktionen von mir.
Ich weiß ganz genau was ich da mache.
Zufällig funktioniert beim Programmieren meistens gar nichts.
Ralph S. (jjflash) >Leider haben viele dieser Projekte das Manko, >dass für die Hardware oft ein teures Discovery-Board mit bspw. STM32F4 >oder gar STM32F7 benötigt wird (und das Discovery-Board das Display >mitbringt). Dein Projekt hat allerdings den Nachteil, dass es nicht Arduino-kompatibel ist. Wäre es das, gäbe es 1000 Anleitungen im Netz, wie das Programm zu flashen und installieren ist. Desweiteren wäre es dann auch einfach möglich, die Games auf andere Controller wie z.B. den ESP zu portieren. Es ist sogar locker möglich, die Software als Arduino-kompatible Emulation auf Linux zu entwickeln, dafür gibt es einige Beispiele im Netz.
Hallo JJ, ich finde es ein tolles Projekt. Mir gefällt es! Vg Thomas
Fred schrieb: > Dein Projekt hat allerdings den Nachteil, dass es nicht > Arduino-kompatibel ist. Meckerst Du bei einer Designerküche auch, daß sie nicht von Ikea ist? Die meisten MC-Anwendungen sind nicht Arduino-basierend und es ist schön, daß auch in der Hobbywelt noch jemand richtig programmiert.
Fred schrieb: > Dein Projekt hat allerdings den Nachteil, dass es nicht > Arduino-kompatibel ist. Ich habe zwar Arduino-Hardware, auch AVR, ESP und diverse "Shields" und mein Standarddevelopmentboard für STM32F103 ist ein eigenentwickeltes PCB mit Arduino r3 Formfaktor, aber ich mag die Arduino Software und Entwicklungsumgebung nicht. Da das ganze ein Makefileprojekt ist, reicht hier zum Erzeugen des Binärfiles ein einfacher Aufruf von Make. Ein ganz einfacher Texteditor wie Geany oder sogar auch MCEDIT(mein bevorzugter ist ein selbstgeschriebener auf Konsolenebene) reicht aus, um den Code zu erstellen / bearbeiten. Fred schrieb: > Wäre es das, gäbe es 1000 Anleitungen im Netz, wie das Programm zu > flashen und installieren ist. Im Netz gibt es 1000 Anleitungen dafür, wie eine Bluepill zu flashen ist und wer die Bluepill in Verbindung mit Arduino nutzt, der hat entweder den USB-Bootloader installiert, benutzt einen ST-Link oder macht das über den internen seriellen Bootloader des STM32. In allen Fällen hat er also schon einmal mindestens ein Programm auf der Bluepill ausserhalb von Arduino darauf geflasht. Das im Projekt vorhandene Makefile ist eingestellt für eine Benutzung mit ST-Link v2, das heißt: - ST-Link an Bluepill anschließen - Aufruf "make" (für Erzeugen des Binärcodes) - Aufruf "make flash" (für das Flashen des Chips) Wer lieber einen seriellen Upload machen mag, ändert im Makefile den Benutzten Programmer, und gibt dort bspw. für Programmer 1 statt 0 an und die gewählte Uploadmethode ist dann seriell (und erfordert ein installiertes stm32flash im System). Fred schrieb: > die Games auf andere Controller wie z.B. den ESP zu portieren. Viele ESP-Boards haben gar nicht die benötigten 5 I/O Pins zum Anschluss des Displays und der Tasten. Für Spiele wie Reversi, Vier Gewinnt oder Schach reicht bei einem AVR der RAM nicht. Ein Intel Edison (habe ich auch) dürften die wenigsten haben, alleine ARM basierende dürften hierfür genügen. Im Übrigen war das Reversi ein Konsolenprogramm für Linux. Es hatte mich 2 Stunden gekostet, das auf die Bluepill zu portieren, damit das mit Ausgabe über einen UART darauf funktioniert. Die Grafik und Steuerung dauerte dann etwas länger. Ein Portieren zu einem STM32F4, STM32F7 oder eines NXP-Controllers ist hier kein Problem. Wenn ich es richtig weiß, gibt es für NXP-Controller gar keinen Core für Arduino. Vielleicht ist so ein Projekt einmal der Anlaß darüber nachzudenken, ob etwas "Arduino-kompatibel" sein muß oder nicht (und ist damit deutlich resourcenschonender als mit der Arduino-IDE). Wenn ich andere Projekte mit kleinen bis sehr kleinen Controllern mache (wie bspw. ATtiny oder STM8), dann ist der Resourcenhunger von Arduino suboptiomal. Abgesehen davon gibt es für Arduino genügend Spielzeug und Spiele im Netz zu finden.
Ralph S. schrieb: > Wer das Teil ausprobieren will: Viel Spaß damit Ja, danke. Ist ne nette Idee. Aber bei dir geht's mMn ein bissel zu sehr drunter und drüber in den Quellen. Die Bemerkungen über die Fonts und Grafiken in .h hattest du ja schon gelesen. Daß auch main, das eigentliche Spiel und diverse Tasten- und Display-Routinen in einer Datei zusammengepfercht sind und es damit schwer fällt, plattformabhängige Teile von plattformunabhängigen Teilen zu unterscheiden, muß ich hier mal loswerden. Ebenso, daß du mit reversi_stm32\include\font12x16.h und reversi_stm32\src\font12x16.fnt zweimal den gleichen Font im Projekt drin hast. Gilt auch für die 5x7 und 8x8 Fonts. Das kommt von der Unordnung, gelle? Ansonsten wäre da noch sowas wie Sozobon zu nennen - könnte dir auch gefallen. Siegfried hatte das vor Jahren schon mal auf nen ARM7TDMI umgesetzt. Ralph S. schrieb: > Vielleicht ist so ein Projekt einmal der Anlaß darüber nachzudenken, ob > etwas "Arduino-kompatibel" sein muß oder nicht (und ist damit deutlich > resourcenschonender als mit der Arduino-IDE). Ich teile deine Bedenken bzgl Arduino. Was ich mir weitaus eher vorstellen kann, ist eine Art Grund-Firmware für diverse µC, bei der zur Anpassung an verschiedene Plattformen lediglich einige wenige Lowlevel-Treiber ausgetauscht werden müssen. Oberhalb dieser Treiber geht's dann hardwareunabhängig weiter, so daß solch ein Ansatz sowohl effektiv als auch ziemlich universell ist. W.S.
W.S. schrieb: > Die Bemerkungen über die Fonts und Grafiken in .h hattest du ja schon > gelesen. Danke sehr. W.S. schrieb: > Daß auch main, das eigentliche Spiel und diverse Tasten- und > Display-Routinen in einer Datei zusammengepfercht sind und es damit > schwer fällt, plattformabhängige Teile von plattformunabhängigen Teilen > zu unterscheiden, muß ich hier mal loswerden. Ja, offensichtlich kann man nicht nur in Basic Spaghetti-Code erzeugen. Der Begriff "Hierarchie" ist in vielen Source- Konvoluten nicht zu erkennen.
>> die Games auf andere Controller wie z.B. den ESP zu portieren. >Viele ESP-Boards haben gar nicht die benötigten 5 I/O Pins zum Anschluss >des Displays und der Tasten. TFT-Display an ESP32 https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/1-8-toll-tft-am-esp-32-dev-kit-c-betreiben Oder wenn man keine Lust zum Basteln hat, gleich als fertige Konsole: https://www.hardkernel.com/shop/odroid-go/ > Für Spiele wie Reversi, Vier Gewinnt oder >Schach reicht bei einem AVR der RAM nicht. Vielleicht reicht der Arduino-Mega: https://store.arduino.cc/arduino-mega-2560-rev3 >Ein Intel Edison (habe ich >auch) dürften die wenigsten haben, alleine ARM basierende dürften >hierfür genügen. Mit großer Wahrscheinlichkeit aber der Arduino-Due https://www.arduino.cc/en/Guide/ArduinoDue >Ein Portieren zu einem STM32F4, STM32F7 oder eines NXP-Controllers ist >hier kein Problem. Ja, man kann sich das Board aussuchen: https://github.com/stm32duino/Arduino_Core_STM32 >Wenn ich es richtig weiß, gibt es für NXP-Controller >gar keinen Core für Arduino. Möglicherweise arbeiten sie daran: https://www.nxp.com/products/security-and-authentication/authentication/se050-arduino-compatible-development-kit:OM-SE050ARD >Vielleicht ist so ein Projekt einmal der Anlaß darüber nachzudenken, ob >etwas "Arduino-kompatibel" sein muß oder nicht (und ist damit deutlich >resourcenschonender als mit der Arduino-IDE). Das ist so ähnlich wie die Frage, ob alles LINUX kompatibel sein muss. Muss nicht, macht aber meistens Sinn. Die Arduino-API ist das Linux der Mikrocontroller. Sie wird ständig erweitert und unterstützt zunehmend mehr Peripherie wie I2S, DACs usw. Bisweilen werden auch Mutlitasting Betriebssystem unterlagert, wie beim ESP. >Wenn ich andere Projekte mit kleinen bis sehr kleinen Controllern mache >(wie bspw. ATtiny oder STM8), dann ist der Resourcenhunger von Arduino >suboptiomal. Was verstehst Du unter suboptimal? Die 3,50€, die ein ESP32 kostet?
Ralph S. schrieb: > Wenn ich es richtig weiß, gibt es für NXP-Controller > gar keinen Core für Arduino. Jein. Es gibt mittlerweile einen Arduino nano BLE, ganz offiziel von Arduino.cc. Und was installiert der Boardverwalter? Mbed + Wrapper um die Arduino API bereitzustellen :) Ist natürlich durch die Brust ins Auge, aber den Wrapper kann man natürlich für alle Mbed Targets verwenden. Wenn man mag, ich schmeisse lieber das Arduino spezifische raus um reine Mbed Libs zu bekommen. Aber ein OS bringt Overhead und Komplexität was nicht jeder will. Insofern ist so eine minimal Vorlage doch schön um es auf sein Lieblingssystem umzubauen. Besser finde ich nur soetwas heute auf github zu hosten, dann sind Forks oder Fixes nachvollziehbarer zu verwalten. Mit libopencm3 ist hier aber auch schon ein standardisiertes API vorhanden und die Portierung auf andere STM32 einfach möglich.
Puuuh, einiges an Kritik und (für mich) fast noch "schlimmer" einiges berechtigt: W.S. schrieb: > Aber bei dir geht's mMn ein bissel zu sehr schwer fällt, plattformabhängige Teile von plattformunabhängigen Teilen zu unterscheiden, muß ich hier mal loswerden.drunter und drüber in den > Quellen. Stimmt (leider), da habe ich nicht wirklich aufgeräumt und war erfreut, wie das dann endlich, optisch halbwegs ansprechend lief. W.S. schrieb: > Ebenso, daß du mit > reversi_stm32\include\font12x16.h und > reversi_stm32\src\font12x16.fnt > zweimal den gleichen Font im Projekt drin hast. Gilt auch für die 5x7 > und 8x8 Fonts. Das kommt von der Unordnung, gelle? Na ja, da ist mir ein Kopierfehler unterlaufen. In einem anderen Thread hatten wir darüber diskutiert, ob Daten in einer Headerdatei Platz finden sollten oder nicht. Nach einiger Überlegung hatte ich die Fonts aus den Headerdateien verband und in eine *.fnt Datei geschickt. Damit jetzt alte Projekte dennoch kompilierbar bleiben, sind in meinen Ordnern beide vorhanden. Dieses Projekt hier braucht die fontdatei.h nicht (und wird auch nirgendwo aufgerufen), eben ein Kopierfehler zum Projekt. W.S. schrieb: > schwer fällt, plattformabhängige Teile von plattformunabhängigen Teilen > zu unterscheiden, muß ich hier mal loswerden. Hrmpf... wie gesagt, manchmal ist Kritik berechtigt. Ich habe das aufgeräumt und Projekt in Teildateien für die KI, Tastensteuerung und den Spirographen für das Hintergrundmuster aufgeteilt. In der Datei die die Main enthält gibts jetzt nur noch Bildaufbau und Spielablauf. By the way: einen Fehler bei der Anzeige der Steine wurde beseitigt. W.S. schrieb: > Ich teile deine Bedenken bzgl Arduino. Was ich mir weitaus eher > vorstellen kann, ist eine Art Grund-Firmware für diverse µC, bei der zur > Anpassung an verschiedene Plattformen lediglich einige wenige > Lowlevel-Treiber ausgetauscht werden müssen. Oberhalb dieser Treiber > geht's dann hardwareunabhängig weiter, so daß solch ein Ansatz sowohl > effektiv als auch ziemlich universell ist. Darüber mache ich mir schon sehr sehr lange Gedanken. Daraus ist eine Grundfirmware für meine Graphikausgaben, das Ansprechen von GPIO Pins geworden und UART-Ausgaben geworden. Bei solchen Dingen wie bspw. dem SPI oder auch I2C Bus kann das schon mal schwierig werden (selbst innerhalb einer MCU-Familie) weil die Möglichkeiten unterschiedlich sind. Bspw. will ein STM32F030 immer wissen, wievele Bytes auf dem I2C Bus geschickt werden, ein F103 will das nicht wissen. Schwierig ist, hier den kleinsten gemeinsamen Nenner zu finden und, wie du schon einmal sagtest: Gut gemeint ist nicht immer gut gemacht ! Das, was man selbst gemacht hat und versteht ist auch leicht abzuändern. Von anderen zu übernehmen wird schwierig. Außerdem: ist denn das Arduino-Framework nicht fast schon so etwas wie eine "Grundfirmware" (auch wenn sie erst noch compiliert und gelinkt werden muss) ? Sowas ist immer satt resourcenfressend. ----------------------------------------- Fred schrieb: > ob alles LINUX kompatibel sein muss Was ist das? "LINUX - kompatibel" ? Entweder man hat ein Linux oder nicht... hm. Fred schrieb: > Die Arduino-API ist das Linux der Mikrocontroller. Aha ! Jetzt habe ich wieder was gelernt, denn das wußte ich nicht! Aber es ist mir dennoch egal, das Projekt hier ist für eine BluePill gedacht. In reinem Bare-Metall. Mit meinem eigenen Funktionen und der libopencm3 Bibliothek. Derjenige, der das unbedingt portieren mag, kann das gerne tun (und nachdem ich den Code aufgeräumt habe, dürfte das leichter sein als man sich es vorstellt). ------------------------------------------ Johannes S. schrieb: > > Aber ein OS bringt Overhead und Komplexität was nicht jeder will. ganz deiner Meinung. Johannes S. schrieb: > Besser finde ich nur soetwas heute auf github > zu hosten, dann sind Forks oder Fixes nachvollziehbarer zu verwalten. Asche auf mein Haupt, irgendwo hatte ich ein Projekt auf github eingestellt gehabt.... und mich dann nicht mehr wirklich dort darum gekümmert. Aber du hast Recht. Johannes S. schrieb: > Mit libopencm3 ist hier aber auch schon ein standardisiertes API > vorhanden und die Portierung auf andere STM32 einfach möglich. Stimmt sehr genau, heute Mittag lief das in der STM32 Familie auf einem F105, F303, F411 und F429.
Ralph S. schrieb: > Darüber mache ich mir schon sehr sehr lange Gedanken... > Bei solchen Dingen wie bspw. dem > SPI oder auch I2C Bus kann das schon mal schwierig werden... > Schwierig ist, hier den kleinsten gemeinsamen Nenner zu finden und, wie > du schon einmal sagtest: Gut gemeint ist nicht immer gut gemacht ! > Sowas ist immer satt resourcenfressend. Ähem.. Wenn man es richtig anpackt, ist es nicht wirklich ressourcenfressend. Ich hatte hier schon mal so ein Minimalsystem gepostet mit folgendem Inhalt: - Pinkonfiguration und Takt aufsetzen - UART Treiber - USB-VCP-Treiber - System-Uhr - Event-System - Konvertierungsroutinen (um sowas wie printf zu vermeiden) - Kommandoprozessor und das kostet 11508 Bytes an Flash, µC = STM32F103C8T6. Das Obige und zusätzlich noch: - LowLevel-Treiber für Pollin Grafik-LCD VG120751WRNNA - GDI - Font 5x7 - Fonts Helvetica 12, 12bold, 14, 14bold - LowLevel-Treiber IR-Fernbedienung - Treiber für Ruwido-Merlin-Tastatur (Living Room Keyboard, Pollin) - Lowlevel-Schrittmotortreiber - Tasten- und Drehgeber-Treiber und das kostet alles zusammen 13428 Bytes an Flash, µC = Kinetis MK02FN. Allerdings mit dem Keil übersetzt, der macht einen recht kompakten Code. Manche Dinge sind tatsächlich eklig, wozu auch der I2C gehört. Der einzige Peripherie-Core, der mit jemals wirklich gut gefallen hatte, war der in den damaligen NEC 78K4 Controllern. Ist aber längst vorbei... Ralph S. schrieb: > Bspw. will ein STM32F030 immer wissen, wievele Bytes auf dem I2C Bus > geschickt werden, ein F103 will das nicht wissen. Genau so meine ich das mit dem 'eklig'. Plattformunabhängig würde heißen OpenSlave(Adresse,obRdWr) und ReadSlave() und WriteSlave(was) und CloseSlave(). Da paßt es einfach nicht, wenn die HW zuvor wissen will, wieviele Bytes zu transportieren sein werden. Ich hatte das bei diesen Mistcores auch mal erfolglos mit 0 bytes versucht --> Fehlanzeige. Bei solchen sperrigen Cores ist es dann besser, den I2C rein per Software zu machen und von der ganzen Hardware nur die OpenDrain-Eigenschaft der Pins zu benutzen. Da heißt es in solchen Fällen eben nicht, den kleinsten gemeinsamen Nenner zu finden, sondern vorrangig ein plattformunabhängiges Interface zu definieren. Und wenn so ein Peripherie-Core da partout nicht hinein paßt, dann sollte die kopfinterne Alarmlampe angehen - damit man sich nicht auf etwas einläßt, was sich später als Ring-Durch-Die-Nase erweist. W.S.
W.S. schrieb: > - Pinkonfiguration und Takt aufsetzen > - UART Treiber > - USB-VCP-Treiber > - System-Uhr > - Event-System > - Konvertierungsroutinen (um sowas wie printf zu vermeiden) > - Kommandoprozessor > und das kostet 11508 Bytes an Flash, µC = STM32F103C8T6. Stimme ich dir zu (bis auf das printf, aber da haben wir eh unterschiedliche Ansichten). W.S. schrieb: > - LowLevel-Treiber für Pollin Grafik-LCD VG120751WRNNA > - GDI > - Font 5x7 > - Fonts Helvetica 12, 12bold, 14, 14bold > - LowLevel-Treiber IR-Fernbedienung > - Treiber für Ruwido-Merlin-Tastatur (Living Room Keyboard, Pollin) > - Lowlevel-Schrittmotortreiber > - Tasten- und Drehgeber-Treiber Das ist schon wieder sehr speziell und zielt auf bestimmte Einsatzzwecke hin. Alleine das Display (das ich, wenn ich die Nummer bei Pollin eingebe) nicht finde begrenzt das ganze auf eben dieses Display. Ich glaube, es haben sich schon viele an einer universellen Firmware oder auch Betriebssystem für Controller versucht und: W.S. schrieb: > Da heißt es in solchen Fällen eben nicht, den kleinsten gemeinsamen > Nenner zu finden, sondern vorrangig ein plattformunabhängiges Interface > zu definieren. ... genau das ist das Problem.
... aber irgendwie driftet der Thread jetzt vom Reversi-Spiel ab : - ) jj
Also W.S. hat echt garnichts zu melden was Codequalität angeht. Wer Magic Numbers einsetzt und die noch verteidigt, der hat nicht begriffen wie programmiert wird. Aber er kanns echt nicht lassen andere Leute zu belehren, einfach ignorieren diese Type ;)
Ralph S. schrieb: > Das ist schon wieder sehr speziell und zielt auf bestimmte Einsatzzwecke > hin. Ganz richtig. Das ist eine spezielle Anwendung, aber der Löwenanteil des ganzen Zeugs ist universell. Und es ist ziemlich platzsparend. Es sind eben wirklich nur die Treiber, die beim Chip- oder Display-Wechsel ausgetauscht werden müssen. Und man erspart sich all die #ifdef-Konstrukte in den Quellen. Das ist das Charmante an so einer Herangehensweise. W.S.
Ralph S. schrieb: > Alleine das Display (das ich, wenn ich die Nummer bei Pollin > eingebe) nicht finde nur für dein Interesse: Beitrag "Display von Pollin - Datenblatt - Ansteuerung" W.S.
W.S. schrieb: > nur für dein Interesse: > Beitrag "Display von Pollin - Datenblatt - Ansteuerung" > > W.S. ... ich meinte nicht das Datenblatt zu diesem Display, sondern ich finde schlicht den Artikel nicht. Scheinbar ist das Display bei Pollin schlicht ausverkauft !
Ja - das war doch klar. Der Thread ist von 2014. Da ist es zu erwarten, daß dieses Display inzwischen ausverkauft ist. Siehe: https://www.pollin.de/p/lcd-grafikmodul-vg-g120751-1wrnna-120938 Dinge dieser Art sind tatsächlich ein Problem: Was Pollin anbietet, ist zum großen Teil eben Sonderangebot solange Vorrat reicht. Natürlich kann man mit dem Zeug eine Menge machen. Aber daraus ein Bastelvorhaben zu machen, was vieleicht nach ein paar Jahren jemand nachbauen möchte, funktioniert nicht, da Display ausverkauft. Man muß sowas wissen und berücksichtigen und ggf. sich was davon auf Lager legen. Dafür ist es nicht teuer - im krassen Gegensatz zu Displays anderer Anbieter wie Powertip, Displaytech, NewHaven u.a. Ein Projekt mit sowas teurem läßt sich zwar auch nach Jahren nachbauen, aber für viele Bastler ist das dann preislich daneben und damit auch wieder uninteressant. Momentan scheint mal wieder eine Ausverkaufs-Welle bei Pollin zu sein: 121581 = 1 Zeile Alpha 121713 = 240x64 121466 = VFD, 1 Zeile 121467 = 128x64 120817 = 320x240xFarbe+RTouch, braucht aber Ansteuerung 121498 = 480x272xFarbe+RTouch, braucht auch Ansteuerung (z.B. LPC4088) Du siehst, wie es da bei Pollin eben immer rauf und runter geht. Entweder man kauft sich sowas auf "Verdacht" oder es ist eben aus. W.S.
Pollin ist ein Surplus-Händler. Der verkauft Restposten, die irgendwo bei der Produktion übergeblieben sind. Langfristige Verfügbarkeit erwartet man da eher weniger.
W.S. schrieb: > Ja - das war doch klar. > Der Thread ist von 2014. Da ist es zu erwarten, daß dieses Display > inzwischen ausverkauft ist. > Siehe: > https://www.pollin.de/p/lcd-grafikmodul-vg-g120751-1wrnna-120938 Ähem... du hast mir den Link gegeben, weil: W.S. schrieb: > Das Obige und zusätzlich noch: > - LowLevel-Treiber für Pollin Grafik-LCD VG120751WRNNA > - GDI > - Font 5x7 > - Fonts Helvetica 12, 12bold, 14, 14bold das von dir vorgeschlagen war. Also hab ich nach dem Display nachgeschaut (wobei ich da nicht von mir aus auf die Idee komme, einen solchen Aufwand zu treiben, um ein einfaches veraltetes und zudem noch für die freie Wildbahn exotisch Display in Betrieb zu nehmen). Dass Pollin sehr viel Restposten verkauft ist allgemein bekannt. Eine, wie du vorgeschlagen hast, universelle Firmware auf dieses Display abzustimmen ist mit Sicherheit noch krasser, als (das was ich schon gemacht habe) ein graphikfähiges Display an einen ATtiny anzuschließen. Hrmpf... irgendwie .... gleitet der Thread so ganz arg ab, schade drum !
Bitte 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.