mikrocontroller.net

Forum: Projekte & Code Die "BluePill" spielt Reversi / Ohtello, Code für STM32F103


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
6 lesenswert
nicht lesenswert
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:

Ebay-Artikel Nr. 292592540785

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

Autor: Beo Bachta (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Fred (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (thomas100)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Hallo JJ,

ich finde es ein tolles Projekt.
Mir gefällt es!

Vg Thomas

Autor: Horst (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: OMG (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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?

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
... aber irgendwie driftet der Thread jetzt vom Reversi-Spiel ab

: - )

jj

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pollin ist ein Surplus-Händler. Der verkauft Restposten, die irgendwo 
bei der Produktion übergeblieben sind. Langfristige Verfügbarkeit 
erwartet man da eher weniger.

Autor: JJFlash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.