Seite 1 von 1

Pollin-Spiel

Verfasst: Fr 2. Sep 2011, 12:04
von Heinrichs
Kürzlich habe ich für knapp 8 Euro das Pollin-Spiel (s. Abb.) erworben. Die Frage war: Lässt es sich zu Lehrzwecken einsetzen? Wenn ja, dann müsste man nur noch nach einem preiswerten Programmierkabel schauen.

Das Platinchen ist fix zusammen gebaut. Leider funktioniert das Spiel bei mir nicht korrekt, vermutlich weil die Taster prellen. Zur Lehrzwecken ließe es sich bedingt einsetzen, weil PortD.0-PortD.5 mit Tastern als Eingänge bzw. LEDs und einem Beeper (als Ausgänge) verbunden sind. Außerdem stehen noch PortB.5-PortB.7 an einer Steckerleiste zur Verfügung (u. A. für ISP, dazu später mehr). Das Display ist zum Hitachi-Standard kompatibel; dazu mehr weiter unten.

Nun zum Programmierkabel: Das Pollin-Spiel lässt sich über einen ISP-Stecker programmieren. Statt eines ISP-Programmierkabels habe ich einen USB-UART-Wandler (UM2102, z. B. bei ELV erhältlich) angeschlossen. Dieser Baustein simuliert eine COM-Schnittstelle. Die benötigte Treibersoftware wurde sowohl unter Win XP als auch unter Win 7 automatisch beim Anschluss dieses Bausteins installiert. Dieser Baustein hat im Gegensatz zu USB-COM-Kabeln eine positive Logik; d. h. dass alle Kommunikationsprogramme, welche mit einem normalen COM- oder USB-COM-Kabel arbeiten, nur dann funktionieren können, wenn sich ihre Signale invertieren lassen.

Wie üblich muss zur SPI-Übertragung von Programmen oder zum Einstellen von Fusebits der Attiny resettet werden. Dazu habe ich den Reset-Anschluss von der Steckerleiste mit einem Kabel versehen, welches man mit Masse verbinden kann (vgl. roten Pfeil in der Abbildung). Vorgehensweise: Erst SPI-Programm auf PC starten, dann COM-Schnittstelle und Invertierung einstellen, dann Pollin-Platine an PC und Batterie anschließen und nun RESET-Kabel an Masse.

Mit einem selbst programmierten SPI-Programm gelang das auch; das Programm PonyProg2000 schaffte dies nicht, warum auch immer. Wie auch schon bei USB-COM-Kabeln ist die SPI-Übertragung sehr langsam; deswegen muss ich von diesem Weg abraten.

Jetzt zum Display: Es kann 8 Zeichen in 2 Zeilen anzeigen. Auf der Pollin-Platine werden sowohl die Betriebsspannung als auch die Kontrastspannung über den Attiny geliefert; auf diese Weise kann das Display bei Bedarf abgeschaltet werden. Bei der Programmierung mit BASCOM ist außerdem nach der Konfiguration des LCDs noch eine zusätzliche Initialisierung (mit initlcd) vorzunehmen. Mein Testprogramm sieht so aus:

Code: Alles auswählen

'******************* Deklarationen ************************
Dim Z As Byte

'****************** Initialisierung ***********************
Ddrb = &B11111111                                           'Port B als Ausgangsport
Ddrd = &B01110001                                           'D0, D4, D5, D6 als Ausgang; Rest als Eingang

Portb.4 = 1                                                 'für Kontrastspannung
Portd.6 = 1                                                 'für Versorgungsspannung

'LCD konfigurieren
Config Lcdpin = Pin , Rs = Porta.1 , E = Porta.0 , Db4 = Portb.0 , Db5 = Portb.1 , Db6 = Portb.2 , Db7 = Portb.3
Config Lcdbus = 4
Config Lcd = 16 * 2                                      '8*1 wird vom Compiler nicht akzeptiert
Initlcd                                                         'ohne das funktioniert es bei mir nicht
Cursor Off

'******************** Hauptprogramm ***********************
Z = 0
Cls
Waitms 10
Do
  Toggle Portd.0                                            'LED an PortD.0 ein- und ausschalten
  Lcd Z                                                     'Zählerstand auf LCD ausgeben
  Waitms 100
  Cls
  Z = Z + 1
Loop
End
Unverständlich ist für mich, dass eine zusätzliche Initialisierung erforderlich ist; denn meines Wissens nach erfolgt diese schon im Rahmen der Konfigurierung. Wer hat eine Lösung dieses Problems?

pollin_um2102.jpg
Pollin-Spiel mit UM2102
pollin_um2102.jpg (49.27 KiB) 15418 mal betrachtet

Re: Pollin-Spiel

Verfasst: Sa 3. Sep 2011, 12:49
von Heinrichs
Gerade haben mein Sohn und ich die Lösung dafür gefunden, warum ein zusätzlicher initlcd-Befehl erforderlich ist: config-Befehle werden von BASCOM - so zeigen Versuche - bei der Compilation an den Anfang des Programmes gesetzt. In unserem Fall bedeutet das, dass die mit dem config-Befehl durchgeführte Initialisierung bereits durchgeführt wird, bevor das LCD über PortD.6 = 1 eingeschaltet worden ist. Diese erste Initialisierung geht dann natürlich ins Leere. Der Befehl initlcd wird hingegen erst nach dem Einschalten ausgeführt und greift deswegen jetzt.