Technische Universit¨at Berlin Fakult¨at IV
Institut f¨ur Energie und Automatisierungstechnik
Fachgebiet Mikroelektronik-, Aufbau- und Verbindungstechniken Fachgebiet Elektronik und medizinische Signalverarbeitung Projektorientiertes Praktikum
Professor Dr.-Ing. Reinhold Orglmeister Professor Dr.-Ing. Klaus-Dieter Lang Wintersemester 2019/2020
Das 8-Bit-Waffeleisen
Eine sich refinanzierende LED-Retro-Spielekonsole mit Entertainment-Paket.
Projektgruppe: Dienstag 14
00–16
00Betreuung:
Julia G¨ unther-Sorge, Michael Klum
Marvin Ageling, Markos Bantouvakis, Max Genson, Nasser Rafraf
27. Januar 2020
Inhaltsverzeichnis
1 Einleitung 1
2 Projektbeschreibung 1
3 Teilnehmer, Gruppen und Organisations¨amter 3
3.1 Teilnehmer . . . 3
3.2 Gruppen und Untergruppen . . . 3
3.3 Organisations¨amter . . . 4
4 Ger¨atespezifikationen 5 4.1 Technische Daten . . . 5
4.1.1 LED DOT Matrix . . . 5
4.2 Energieversorgung . . . 5
4.2.1 Netzteil . . . 6
4.2.2 BMS . . . 6
4.3 Entertainment . . . 7
4.4 Schnittstellen . . . 7
4.4.1 Busbelegungsplan . . . 7
4.4.2 Energieversorgung . . . 8
4.4.3 Kommunikation CPU-Entertainment-Gruppe . . . 9
4.5 Geh¨ause . . . 10
4.5.1 Der Geh¨auseentwurf . . . 11
4.5.2 Material . . . 13
5 Gruppe 1: CPU 14 5.1 Aufgabenstellung. . . 14
5.2 Blockschaltbild. . . 15
5.3 CPU -Software und Abstraktion . . . 16
5.3.1 Dokumentation und Arbeitsentwicklung . . . 16
5.3.2 Zustandsdiagramm . . . 18
5.3.3 Schaltplan . . . 19
5.3.4 Layout . . . 20
5.3.5 Platine . . . 21
5.3.6 Zusammenfassung . . . 22
5.4 CPU - LED DOT Matrix . . . 23
5.4.1 Dokumentation und Arbeitsentwicklung . . . 23
5.4.2 Schaltplan . . . 28
5.4.3 Layout . . . 29
5.4.4 Platine . . . 30
5.4.5 Zusammenfassung . . . 31
5.5 CPU -Graphical LCD . . . 32
5.5.1 Dokumentation und Arbeitsentwicklung . . . 32
5.5.2 Schaltplan . . . 37
5.5.3 Layout . . . 38
5.5.4 Platine . . . 39
5.5.5 Zusammenfassung . . . 39
6 Gruppe 4: Interface 40 6.1 Aufgabenstellung. . . 40
6.2 Blockschaltbild. . . 40
6.3 Interface – Gamecontroller . . . 41
6.3.1 Dokumentation und Arbeitsentwicklung . . . 41
6.3.2 Schaltplan . . . 42
6.3.3 Layout . . . 46
6.3.4 Platine . . . 48
6.3.5 Zusammenfassung . . . 49
6.4 Interface – Pseudo-Random-Number-Generator (PRNG) . . . 50
6.4.1 Dokumentation und Arbeitsentwicklung . . . 50
6.4.2 Schaltplan . . . 53
6.4.3 Layout . . . 55
6.4.4 Platine . . . 55
6.4.5 Zusammenfassung . . . 57
6.5 Interface – 7-Segmentanzeige . . . 57
6.5.1 Dokumentation und Arbeitsentwicklung . . . 57
6.5.2 Blockschaltbild . . . 62
6.5.3 Schaltplan . . . 63
6.5.4 Layout . . . 65
6.5.5 Platine . . . 67
6.5.6 Zusammenfassung . . . 69
7 Gruppe 3: Entertainment 70 7.1 Aufgabenstellung. . . 70
7.2 Blockschaltbild. . . 70
7.3 Entertainment Licht . . . 71
7.3.1 Dokumentation und Arbeitsentwicklung . . . 71
7.3.2 Schaltplan . . . 74
7.3.3 Layout . . . 75
7.3.4 Platine . . . 76
7.3.5 Zusammenfassung . . . 76
7.4 Entertainment M¨unzeinwurf . . . 77
7.4.1 Dokumentation und Arbeitsentwicklung . . . 77
7.4.2 Schaltplan . . . 80
7.4.3 Layout . . . 84
7.4.4 Platine . . . 85
7.4.5 Zusammenfassung . . . 87
7.5 Entertainment Audio . . . 88
7.5.1 Dokumentation und Arbeitsentwicklung . . . 88
7.5.2 Schaltplan . . . 90
7.5.3 Layout . . . 97
7.5.4 Platine . . . 99
7.5.5 Zusammenfassung . . . 100
8 Gruppe 4: Energieversorgung 101 8.1 Aufgabenstellung. . . 101
8.2 Blockschaltbild. . . 102
8.3 Energieversorgung – Netzteil und Ladeger¨at . . . 104
8.3.1 Dokumentation und Arbeitsentwicklung . . . 104
8.3.2 Schaltpl¨ane. . . 108
8.3.3 Layout . . . 115
8.3.4 Platine . . . 117
8.3.5 Zusammenfassung . . . 120
8.4 Energieversorgung – Batterie und BMS . . . 120
8.4.1 Dokumentation und Arbeitsentwicklung . . . 120
8.4.2 Schaltpl¨ane. . . 127
8.4.3 Layout . . . 133
8.4.4 Platine . . . 135
8.4.5 Zusammenfassung . . . 136
9 Benutzerhandbuch 137 9.1 Bedienungsanleitung . . . 137
9.1.1 Inbetriebnahme . . . 137
9.1.2 Energieversorgung . . . 137
9.1.3 Men¨uf¨uhrung . . . 137
9.1.4 Men¨u Diagramm . . . 138
9.1.5 Spiele . . . 138
9.1.6 Spielsteuerung . . . 140
9.1.7 Fehlerbehebung. . . 140
9.2 Gefahrenhinweise und Vorschriften . . . 140
9.2.1 Batterie und BMS . . . 140
9.2.2 Netzteil und Versorgung . . . 141
9.2.3 Licht und Ton . . . 141
9.2.4 Spiele und Spielanzeige . . . 141
9.3 Bauteile und Messpunkte. . . 143
9.3.1 Gruppe 1 – CPU . . . 143
9.3.2 Gruppe 2 – Interface . . . 146
9.3.3 Gruppe 3 – Entertainment . . . 149
9.3.4 Gruppe 4 – Energieversorgung . . . 154
9.4 Layout . . . 159
9.4.1 CPU-CPU . . . 159
9.4.2 CPU-GPU . . . 160
9.4.3 CPU-GLCD . . . 161
9.4.4 Interface . . . 162
9.4.5 Gruppe 3 – Entertainment . . . 167
9.4.6 Gruppe 4 – Energieversorgung . . . 170
9.5 Zu Beachten . . . 175
9.5.1 Gruppe 1 – CPU . . . 175
9.5.2 Gruppe 2 – Interface . . . 176
9.5.3 Gruppe 3 – Entertainment . . . 177
9.5.4 Gruppe 4 – Energieversorgung . . . 178
9.6 Codeverzeichnis . . . 179
10 Anhang 222 10.1 Datenbl¨atter . . . 222
10.2 Weiterf¨uhrende Informationen . . . 222
Abbildungsverzeichnis
1 Logo des 8-Bit Waffeleisens erstellt mit [1] und bearbeitet mit [2] . . . 1
2 Busbelegungsplan . . . 8
3 Erste Handskizze des Geh¨auses. Eigenh¨andige Skizze . . . 12
4 Finaler Fusion360-Entwurf (CAD) des Geh¨auses. Eigene Abbildung, erzeugt mit dem Programm Fusion 360 von Autodesk . . . 12
5 Finale Zeichnung der Sidepanels mit Bemaßung. Eigene Abb. erstellt mit Fusion-360 Autodesk . . . 13
6 Blockschaltbild CPU Gruppe . . . 15
7 Zustandsdiagramm: Softwareabstraktion . . . 18
8 Schaltplan CPU . . . 19
9 CPU Layout . . . 20
10 CPU:Central processing unit Platine . . . 21
11 Pins der Schieberegister . . . 24
12 Pins der Mikrocontroller . . . 25
13 SPI leitungen . . . 26
14 CPOL und CPHA einstellungen . . . 27
15 DMA . . . 28
16 Schaltplan LED DOT Matrix . . . 28
17 LED DOT Matrix Layout. . . 29
18 GPU:Graphik Card platine . . . 30
19 GLCD Pins . . . 32
20 Schaltplan GLCD . . . 37
21 GLCD Layout . . . 38
22 GLCD Platine . . . 39
23 Blockschaltbild f¨ur die Gruppe Interface.(Eigene Abbildung erzeugt mit yEd) . . . 41
24 Blockschaltbild f¨ur den Gamecontroller (Abb. erzeugt mit yEd) . . . 42
25 Logik f¨ur das Steuerkreuz (Abb. selbst erstellt mit Notability) . . . 43
26 D-Flip-Flop mit Enable-Port (eigene Aufnahme aus Hades) [3] . . . 43
27 Delay-Schaltung (eigene Aufnahme aus LTSpice) . . . 44
28 Schematic f¨ur den Gamecontroller (eigene Aufnahme aus Eagle) . . . 44
29 Schnittstelle zwischen Gamecontroller input und Mikrocontrollergruppe (Aufnahme aus Eagle) . . . 46
30 Layout der Platine des Gamecontrollers (Aufnahme aus Eagle) . . . 47
31 Layout der Platine der Schnittstelle (Aufnahme aus Eagle) . . . 47
32 Best¨uckte Platine eines Gamecontrollers (Top) . . . 48
33 Best¨uckte Platine eines Gamecontrollers (Bottom) . . . 49
34 Prinzip eines linear r¨uckgekoppelten Schieberegisters . . . 50
35 Blockschaltbild f¨ur den PRNG [4] . . . 51
36 Versuchsaufbau 4-Bit PRNG . . . 52
37 Schaltplan f¨ur den PRNG . . . 53
38 Layout des PRNG . . . 55
39 Darstellung des Spielstandes von Spieler 1 . . . 58
40 Blockschaltbild der 7-Segmentanzeigen1 . . . 62
41 Schaltplan f¨ur die erste Platine 2 . . . 63
42 Schaltplan f¨ur die zweite Platine3 . . . 64
43 Eagle-Layout der ersten Platine4 . . . 65
44 Eagle-Layout der zweiten Platine5 . . . 66
45 Fertige Steuerungsplatine Vorderseite . . . 67
46 Fertige Steuerungsplatine R¨uckseite . . . 67
47 Fertige Anzeigenplatine Vorderseite . . . 68
48 Fertige Anzeigenplatine R¨uckseite . . . 69
49 Blockschaltbild der Gruppe Entertainment [5]. . . 70
50 Blockschaltbild der LED-Beleuchtung [5] . . . 71
51 Simulation f¨ur jeweils eine Farbe des RGB-Streifens [6] . . . 72
52 Simulation f¨ur jeweils eine Farbe des RGB-Streifens (D1 symbolisiert 30 in Reihe geschaltete Dioden) . . . 73
53 Simulation f¨ur jeweils eine Farbe des RGB-Streifens. . . 73
54 Schaltplan zur Ansteuerung einer LED-Farbe [7] . . . 74
55 Gesamtschaltplan zur Ansteuerung der LED-Lichterkette [7] . . . 75
56 Layout der LED-Steuerung [7] . . . 76
57 Blockschaltbild des M¨unzeinwurfs [5] . . . 77
58 Beispiel einer PWM [8]. . . 78
59 Foto des ersten Teils des M¨unzeinwurfs (Eigene Abbildung) . . . 79
60 Foto des zweiten Teils des M¨unzeinwurfs (Eigene Abbildung) . . . 80
61 Schaltplan einer Lichtschranke [7] . . . 81
62 Schaltplan einer Pulsweitenmodulaton PWM [7] . . . 82
63 Schaltplan des Servomotors [7] . . . 83
64 Layout der Lichtschranken [7] . . . 84
65 Layout der Servomotor-Steuerung [7] . . . 85
66 Platine der Lichtschranken [9] . . . 86
67 Korrektes Layout der Servomotor-Steuerung [9] . . . 87
68 Blockschaltbild der Untergruppe Ton [10]. . . 89
69 Anschl¨usse des AY-3-8910A Soundchips [7] . . . 91
70 Digitalpoti [7] . . . 92
71 Summierverst¨arker f¨ur die drei Audiokan¨ale [7] . . . 93
72 Invertierverst¨arker mit Verst¨arkung 1 [7] . . . 94
73 Gegentaktendstufe [7] . . . 95
74 EAGLE Layout der Audio Gruppe [7] . . . 98
75 Platine der Audio Gruppe (Vorderseite). . . 99
76 Platine der Audio Gruppe (R¨uckseite) . . . 99
77 Blockschaltbild der gesamten Energieversorgung . . . 102
78 Schaltung eines Tiefsetzsteller erstellt mit LTspice nach der theoretischen Abbildung ( [11] S. 10) (eigene Abbildung) . . . 104
79 LM2576-ADJ schaltung (eigene Abbildung). . . 105
80 Innerer Aufbau des LM2576 ( [12] S. 13) . . . 106
81 Innerer Aufbau des TL494 ( [13] S. 4) . . . 108
82 Schaltung des 5 V-Kanals in LTspice (Eigene Abbildung) . . . 109
83 Undervoltage-Lockout f¨ur den LM2576-Adj mit Tiefsetzsteller ( [12] S. 6) . . . 109
84 Wahl der richtigen Spule ( [12] S. 21) . . . 111
85 Schaltplan f¨ur das Netzteil in Eagle (eigene Abbildung) . . . 112
86 Teilschaltplan (Hochsetzsteller) f¨ur das Ladeger¨at in Eagle (eigene Abbildung) . . 113
87 Teilschaltplan (IU-Switch mit Tiefsetzsteller) f¨ur das Ladeger¨at in Eagle (eigene Abbildung). . . 114
88 Boardlayout des Netzteils in Eagle (eigene Abbildung) . . . 115
89 Boardlayout f¨ur das Ladeger¨at in Eagle (eigene Abbildung) . . . 117
90 Platine des Netzteils . . . 118
91 Effizienz des Netzteils ( [12] S. 9) . . . 119
92 Variante 1 . . . 123
93 Variante 2 . . . 123
94 Variante 1 des Balancers. Eigene Abbildung, erzeugt mit Eagle [14] [15]. . . 127
95 Variante 2 des Balancers mit Tiefentladeschutz. Eigene Abbildung, erzeugt mit LT- Spice. [14] [15]. . . 128
96 Entg¨ultige Balancerschaltung und der Tiefentladeschutz einer Zelle [14] [15] (Eigene Abbildung, erzeugt mit Eagle) . . . 129
97 Logik, Lade- und Entladerelais (Eigene Abbildung, erzeugt mit Eagle. Schaltung selbst entworfen) . . . 132
98 Vollst¨andiger Schaltplan f¨ur alle sechs Zellen. (Eigene Abbildung, erzeugt mit EAGLE)133 99 Boardlayout der BMS Platine. (Eigene Abbildung, erzeugt mit EAGLE) . . . 134
100 Fertige BMS-Platine. (Eigene Abbildung) . . . 135
101 Fertige R¨uckseite der BMS-Platine. (Eigene Abbildung). . . 136
102 schema des Men¨u (Abb selbst erstellt mit Microsoft Paint) . . . 138
103 Schema eines Gamecontrollers (Abb. selbst erstellt mit Photoshop) . . . 140
104 Bauteilliste Ladeger¨at . . . 158
105 CPU-CPU Top . . . 159
106 CPU-CPU Bottom . . . 159
107 CPU-GPU Top . . . 160
108 CPU-GPU Bottom . . . 160
109 CPU-GLCD Top . . . 161
110 CPU-CPU Bottom . . . 161
111 Gamecontroller Platine Top . . . 162
112 Gamecontroller Platine Bottom. . . 162
113 Eagle-Layoutvorlage f¨ur PRNG Anzeige: Top . . . 163
114 Eagle-Layoutvorlage f¨ur PRNG Anzeige: Bottom . . . 163
115 Eagle-Layoutvorlage f¨ur 7-Seg. Anzeige: Top Platine 1 . . . 164
116 Eagle-Layoutvorlage f¨ur 7-Seg. Anzeige: Bottom Platine 1 . . . 164
117 Eagle-Layoutvorlage f¨ur 7-Seg. Anzeige: Top Platine 2 . . . 165
118 Eagle-Layoutvorlage f¨ur 7-Seg. Anzeige: Bottom Platine 2 . . . 166
119 Eagle-Layout f¨ur das Licht und den M¨unzeinwurf (Vorderseite) . . . 167
120 Eagle-Layout f¨ur das Licht und den M¨unzeinwurf (R¨uckseite) . . . 168
121 Top-Seite des EAGLE Layouts f¨ur die Audio Leiterplatte . . . 169
122 Bot-Seite des EAGLE Layouts f¨ur die Audio Leiterplatte . . . 170
123 Layout Top BMS . . . 171
124 Layout Bottom BMS . . . 172
125 Layout Top Netzteil . . . 173
126 Layout Bottom Netzteil . . . 173
127 Layout Top Ladeger¨at . . . 174
128 Layout Bottom Ladeger¨at . . . 174
129 Unterseite der Gamecontrollerplatine . . . 176
130 7-Segment Platine 1 Busausschnitt . . . 177
Tabellenverzeichnis
1 Ausgabekan¨ale des Netzteils . . . 62 Ausgabekan¨ale des Netzteils . . . 9
3 Recieve Seite als Full Duplex Slave Mode . . . 26
4 Transmission Seite als Full Duplex Slave Mode . . . 26
5 Zustandstabelle f¨ur das Steuerkreuz(selbst erstellt) . . . 43
6 Dimensionierung der Bauteile . . . 110
7 Testmessungsergebnisse der Netzteil-Platine . . . 118
8 Recieve Seite als Full Duplex Slave Mode . . . 145
9 Transmission Seite als Full Duplex Slave Mode . . . 146
10 Platine Gamecontroller (Teil Gamecontroller) . . . 146
11 Platine GLCD/Gamecontroller . . . 147
12 Pinbelegung des Gamecontrollers bzw. der GLCD/Gamecontroller Platine . . . 147
13 Platine Pseudo-Random-Number-Generator. . . 148
14 Steuerungsplatine der 7-Segment Gruppe . . . 148
15 Anzeigenplatine der 7-Segment Gruppe . . . 148
16 Pinbelegung der 7-Segment Gruppe . . . 149
17 Ansteuerung Servo-Motor . . . 150
18 Ansteuerung Lichtschranken . . . 150
19 Ansteuerung LED-Lichtstreifen . . . 151
20 Ton-Platine Bauteile . . . 152
21 Ton-Platine Messpunkte . . . 153
22 Bauteilliste BMS . . . 155
23 Messpunkte-Liste . . . 155
24 LM2576-Adj Pins . . . 156
25 TL494 Pins . . . 157
Listings
WartungReparatur/Abb WartungReparatur/CPU utf8.c . . . 179WartungReparatur/Abb WartungReparatur/LED utf8.c . . . 204
1 Einleitung
Diese Arbeit beschreibt und dokumentiert das Projekt8-Bit-Waffeleisen, das im Rahmen des Pro- jketlabors WS19/20 an der TU-Berlin durchgef¨uhrt wurde. Gleichzeitig stellt dieser Bericht alle Informationen zur Benutzung Wartung des 8-Bit-Waffeleisens zur Verf¨ugung. Der Name 8-Bit- Waffeleisen ist als Hommage an die waffelliebenden ersteller des Projekts angelehnt.
2 Projektbeschreibung
Abbildung 1: Logo des 8-Bit Waffeleisens erstellt mit [1] und bearbeitet mit [2]
Im Projekt 8-bit Waffeleisen des Projektlabors im WS19/20 geht es um die Entwicklung einer Retro Spielekonsole im Stil eines alten Arcade Automaten. Im Gegensatz zu den Spieleautomaten der 80er kommen neben klassischen Analogschaltungen auch moderne Mikrocontroller und LED Technik zum Einsatz. Es sind die Spiele pong, Space War und Auto Racing entweder allein oder gegeneinander Spielbar. Weitere Spiele sind nachtr¨aglich ¨uber ein Softwareupdate nachr¨ustbar. Um
im Falle eines Stromausfalls weiterspielen zu k¨onnen ist zudem eine Batterie integriert. Das 8-Bit Waffeleisen ist mit passender Beleuchtung und kr¨aftigem Sound zudem f¨ur jede Party ger¨ustet.
3 Teilnehmer, Gruppen und Organisations¨ amter
Folgender Abschnitt dokumentiert die Teilnahme am Projketlabor im Wintersemester 2019/2020.
3.1 Teilnehmer
Betreuung – Wissenschaftliche Mitarbeiter Das Projektlabor wird von Julia G¨unther- Sorge vom Fachgebiet Mikroelektronik-, Aufbau- und Verbindungstechniken sowie Michael Klum vom FachgebietElektronik und medizinische Signalverarbeitung geleitet.
Betreuung – Tutoren Die Tutoren ¨ubernehmen jeweils die Betreuung einer Gruppe und eines Orga-Amtes. Das Projektlabor im Wintersemester 2019/2020 wird betreut von: Marvin Ageling, Markos Bantouvakis, Max Genson, Nasser Rafraf.
Teilnehmer Am Projektlabor im Wintersemester 2019/2020 nehmen teil: Mouhammad Tarek Al Dakkak, Fabio Buchwald, Yannik Moritz Butzlaff, Lucian Domingo Chigne Sander, Mehdi Djait, Mohamed Amine Elakel, Kim Sarah Eschenbach, Marc Friedland, Aziz Gharbi, Basel Hallak, Lukas Tim Karal, ¨Aantas Kilian Manfred Kesten, Raphael Philipp Klarwein, Llambro Kokedhima, Vivien Lisa-Marie Kosow, Carolin Lambeck, Khaled Mejri, Maximilian M¨onikes, Iheb Nagga, Thomas Michael Neumann, Kumi Njokweni, Florian Pages, Markus Pohl, Dimitri Ries, Youssef Rihane, William Stanley Selbherr, Donia Slama, Darien Kassim von Dalwigk, Etay Kalifa Yacov, Mohamed Dhia Zarrouki.
3.2 Gruppen und Untergruppen
Gruppe 1 – CPU Betreuer: Markos Bantouvakis
Teilnehmer: Mehdi Djait, Mohamed Amine Elakel, Aziz Gharbi, Khaled Mejri, Iheb Nagga, Etay Kalifa Yacov
Gruppe – Interface Betreuer: Marvin Ageling
Teilnehmer: Lucian Domingo Chigne Sander, Kim Sarah Eschenbach, Basel Hallak, Lukas Tim Karal, Raphael Philipp Klarwein, Markus Pohl, Dimitri Ries, Youssef Rihane
Gruppe – Entertainment Betreuer: Max Genson
Teilnehmer: ¨Aantas Kilian Manfred Kesten, Vivien Lisa-Marie Kosow, Maximilian M¨onikes, Thomas Michael Neumann, Kumi Njokweni, Donia Slama, Darien Kassim von Da lwigk
Gruppe – Energieversorgung Betreuer: Nasser Rafraf
Teilnehmer: Mouhammad Tarek Al Dakkak, Fabio Buchwald, Yannik Moritz Butzlaff, Marc Fried- land, Llambro Kokedhima, Carolin Lambeck, Florian Helge Pages, Mohamed Dhia Zarrouki.
3.3 Organisations¨ amter
Abschlusspr¨asentation und Bericht Betreuer: Markos Bantouvakis
Teilnehmer: Mehdi Djait, Marc Friedland, Lukas Tim Karal, Vivien Lisa-Marie Kosow, Maximilian M¨onikes, Florian Helge Pages, William Stanley Selbherr, Etay Kalifa Yacov
Abschlussparty und Website Betreuer: Marvin Ageling
Teilnehmer: Yannik Moritz Butzlaff, Lucian Domingo Chigne Sander, Markus Pohl, Darien Kassim von Dalwigk
Geh¨ause Betreuer: Max Genson
Teilnehmer: Kim Sarah Eschenbach, Aziz Gharbi, Raphael Philipp Klarwein, Carolin Lambeck Kha- led Mejri, Thomas Michael Neumann, Donia Slama, Mohamed Dhia Zarrouki
Schnittstelle und Bauteile Betreuer: Nasser Rafraf
Teilnehmer: Mouhammad Tarek Al Dakkak, Basel Hallak, ¨Aantas Kilian Manfred Kesten, Youssef Rihane
4 Ger¨ atespezifikationen
4.1 Technische Daten
4.1.1 LED DOT Matrix Hauptmerkmale
• Displaytyp: RGB-LED
• Aufl¨osung: 64x64 Pixel
• Anzahl: 4096 LEDs
• LED Gr¨osse: 3 mm Pitch
• Abmessungen: 192 x 192 x 14 mm Weitere Spezifikationen
• Versorgungsspannung: 5 V
• max. Leistungsaufnahme: 40 W
• Ansteuerung: 1/32 Scan
• Betriebstemperatur: -20-55 C
• Sichtwinkel: 192 x 192 x 14 mm
• Pixeldichte: 111111 Pixel/m2 Weitere Details
• Artikelnummer: LED-Matrix01
• EAN: 4250236818085
Aziz Gharbi
4.2 Energieversorgung
gekauftes Netzteil [16]:
• Modellbezeichnung: GST90A15-P1M
• UAC: 230 V
• UDC: 15 V
• IN: 6 A (0 A... 6 A m¨oglich)
• Pn: 90 W
• Rippelmax: 150 mV
• EMV: Entsprechend EN55022, Klassse B
• Temperaturbereich:θ=−30◦C...70◦C
Carolin Lambeck
4.2.1 Netzteil
Das Netzteil besitzt drei Kan¨ale mit unterschiedlichen, geregelten Ausgangsspannungen. Die ge- nauen Werte k¨onnen in Tabelle 1 eingesehen werden.
ben¨otigte Spannung 3.3 V 5 V 12 V ben¨otigter Strom 0.7 A 2.4 A 2.9 A max. verf¨ugbarer Strom 1 A 2.5 A 3.0 A gebrauchte Leistung 0.99 W 11 W 34.8 W
maximale Leistung 2.31 W 12.5 W 36 W Tabelle 1: Ausgabekan¨ale des Netzteils
M. Tarek Al Dakkak
.
4.2.2 BMS
• Verwendete Zellen: [17]
• Zellchemie: LiFePO4
• Nenn-Kapazit¨at: 3,3Ah
• maximaler Ladestrom: 3,3A
• Anzahl verwendeter Zellen: 6S1P
• Nennspannung Akku-Pack: 19,2 Volt
• Entladeschlussspannung Akku-Pack: 15V
• Ladeschlussspannung Akku-Pack: 21,6V
• Entladestrom (kontinuierlich): 9,9A
• maximaler Balancingstrom: 500mA
• Betriebsdauer bei Spitzenlast (50W): 26 min
Carolin Lambeck
4.3 Entertainment
• Verst¨arker: 2 W×5 W Sinusdauerleistung
• Lautsprecherimpedanz: 8Ω
• Mikrocontroller: STM32L476RG
• Stimmen Synthesizer: 3
• Wellenformen: Dreieck, Rechteck, S¨agezahn, Rauschen
4.4 Schnittstellen
4.4.1 Busbelegungsplan
Da durch die Bearbeitung des Projekts ein Paar Signale zwischen die Gruppen weitergeleitet werden sollte, hatten die Orga. ¨Amter mit einander der folgende Busbelegungsplan gestimmt.
Abbildung 2: Busbelegungsplan
M. Tarek Al Dakkak
4.4.2 Energieversorgung
Im Labor darf mit nicht mehr als 60 V gearbeitet werden, weshalb die Netzspannung von 230 V zu- erst mittels eines gekauften Netzteils (AC/DC Adapter) auf 15 V Gleichspannung heruntergestuft wird. Als Eingang f¨ur das selbstgebaute Netzteil, das Ladeger¨at und das BMS stehen demnach die Nennwerte 15 V Gleichspannung und 6 A Gleichstrom (90 W) zur Verf¨ugung.
Da die anschließenden Gruppen unterschiedliche Spannungen und Str¨ome ben¨otigen, wurde ent- schieden drei verschiedene Kan¨ale zur Verf¨ugung zu stellen. Jeder der drei Kan¨ale k¨onnte dabei maximal 3 A bereitstellen, bevor die vom LM2576 vorgegebene maximale Strombegrenzung in Kraft tritt. Da bei zwei der drei Kan¨ale kein so hoher Strom ben¨otigt wird, wird f¨ur diese die Schaltung so angepasst, dass die Strombegrenzung schon fr¨uher eintritt. In der nachfolgenden Tabelle 2 sind die drei Kan¨ale gegeben, die das Netzteil zur Verf¨ugung stellt.
ben¨otigte Spannung ben¨otigter Strom max. verf¨ugbarer Strom
3.3 V 0.7 A 1 A
5 V 2.4 A 2.5 A
12 V 2.9 A 3.0 A
Tabelle 2: Ausgabekan¨ale des Netzteils
Bemerkenswert ist die Informationssignale. Dazu ist zu nennen, dass die CPU-Gruppe von der Versorgunggruppe eine 1Bit Digitale Ausgangsignale benoetigt, die das Herkommen der Energie- versorgung (Netzteil-Batterie) erkl¨art.
M. Tarek Al Dakkak
4.4.3 Kommunikation CPU-Entertainment-Gruppe
Die Entertainment-Gruppe arbeitet mit einem STM-Chip, welcher sowohl die Entertainment-Gruppe, als auch die Interface-Gruppe mit digitalen Verarbeitungsm¨oglichkeiten versorgt. Da die CPU- Gruppe den Hauptrechner darstellt, ist eine Kommunikationsschnittstelle mit dieser Gruppe es- sentiell.
Dabei wurde sich f¨ur SPI entschieden, da dies schnell und sehr portabel ist. Da SPI in anderen gruppeninternen Teilen auch verwendung findet, muss nur ein Protokoll zur Kommunikation er- stellt werden.
Dabei wird mit einem 16-Bit SPI-Protokoll verfahren, da so CRC (Checksum) m¨oglich ist. Dadurch muss der Befehl nur einmalig gesendet werden und der Empf¨anger kann durch die Checksumme be- stimmen, ob die Kommunikation gelungen ist. Ist dies nicht der Fall, so sendet der Empf¨anger eine SEN DAGAIN Nachricht, welche den Sender auffordert den letzten Befehl erneut zu ¨ubermitteln.
Befehle werden dabei durch 8-Bit Zahlen kodiert, welche in Software (in eigens erstellten Librarys) zu leserlichen Befehlen umgewandelt werden. Dabei fallen trotzdem alle Befehle unter eine der drei
Hauptgruppen. Diese sind W RIT EDAT A, READDAT A und KOM M U N IKAT ION. Alle Befehle, die unterW RIT EDAT Afallen, fordern den SPI-Slave auf interne Daten zu ¨uberschreiben, um so zum Beispiel eine andere Melodie auf den Lautsprechern zu starten. Befehle der Gruppe READDAT Ageben dem SPI-Master die M¨oglickeit Einstellungen oder auch Daten vom Slave zu empfangen, so beispielsweise beim Auslesen von RNG-Zahlen. KOM M U N IKAT ION Befehle sind Hilfsbefehle, um die Kommunikation aufrecht zu halten, so zum Beispiel derSEN DAGAIN Befehl.
Wichtig ist noch, dass mit einem 16-Bit SPI-Protokoll gearbeitet wird. Die Befehle jedoch nur 8-Bit lang sind. Somit k¨onnen die restlichen 8-Bit als gesendete Daten bei W RIT EDAT A Befehlen, als empfangene Daten beiREADDAT ABefehlen und beiKOM M U N IKAT ION Befehlen mit F¨ullbits erweitert werden.
Zusammenfassend entsteht durch eine 3 Befehlsgruppen Kommunikation, in Verbindung mit einer 16-Bit SPI CRC Kommunikation ein solider Aufbau, um Daten im Projekt zu verteilen.
Aas Kesten¨
4.5 Geh¨ ause
Technische Daten:
• Grundfl¨ache: 50 cmx51 cm
• H¨ohe: 84 cm
• Gewicht: ca. 20,1 Kg ohne Einbauten
• Material: MDF (19 mm und 5 mm), Plexiglas 5 mm Einbauten:
• 4 x sieben-Segment Anzeige 11.6 cmx14.4 cm incl. Platine
• LED-Matrix 19 cmx19 cm
• GLCD Display 16 cmx10 cm incl. Platine
• 2x M¨unzeinwurf 3.3 cmx4.5 cm
• 2x Lautsprecher 10 W, 8 cmx8 cmx3.7 cm
• 2x LED
• 2x Controller (nur L¨ocher notwendig)
• 19-Zoll Rack mit 3 Unit
• M¨unzautomat 50 cmx45 cmx20 cm
• Netzteil 19 cmx6.7 cmx3.5 cm
• Akkupack ca. 15 cmx15 cmx10 cm
• Zwei-poliger Schalter 2.2 cmx3.02 cmx1.25 cm
• ein-poliger Schalter
Es wurde sich f¨ur ein Geh¨ause im Stil einer Arcade-Spielekonsole entschieden. Das Geh¨ause soll die Gr¨oße einer Tischkonsole haben. Der Ansatz eines frei stehenden Geh¨auses wurde im Verlauf des Projektes verworfen. In der oberen Blende befinden sich zwei sieben-Segment Anzeigen zum Anzeigen des Spielstandes. Im darunter liegenden Monitorfeld befindet sich, mittig, untereinander angeordnet, die quadratische LED-Matrix und das GLCD-Display f¨ur den Energiesparbetrieb bei Akkuversorgung. Seitlich der LED-Matrix befinden sich die beiden Schlitze f¨ur die M¨unzeinw¨urfe.
Neben den Einw¨urfen zeigt jeweils eine LED an, ob die M¨unze akzeptiert wurde oder nicht. Das Monitorfeld wird umrandet von einem LED-Band der Entertainment-Gruppe. F¨ur einen sch¨oneren Effekt der LEDs wird das Monitorfeld mit einem Plexi-Milchglas abgedeckt, in welches Ausschnitte f¨ur die Anzeigen und M¨unzschlitze ges¨agt sind. Die beiden Controller sind ¨uber Kabel mit der Konsole verbunden, welche aus dem Tastaturbrett durch zwei L¨ocher herausgef¨uhrt werden. Die Lautsprecher werden an den Seiten der Konsole angebracht. Im unteren Teil des Geh¨auses, dem Basement (50 cmx51 cmx39 cm) befindet sich ein 19-Zoll-Rack f¨ur die Europlatinen, die Mechanik f¨ur den M¨unzeinwurf, das Akkupack und das Netzteil. Das 19-Zoll-Rack wird waagerecht im oberen Teil des Basements und b¨undig zur Frontplatte montiert. Darunter befindet sich auf der Bodenplatte das Akkupack und das Netzteil. Im hinteren Teil des Basements steht auf der Bodenplatte der M¨unzeinwurf und dieser reicht in der H¨ohe bis zu den M¨unzeinw¨urfen. Um eine leichte Montage, Reparatur und Akkuwechsel zu erm¨oglichen ist die R¨uckwand in voller H¨ohe und Breite als T¨ur ausgelegt. Die T¨ur wird mittels Klavierband montiert. F¨ur einen bequemen Transport befinden sich in den Seiten des Geh¨auses L¨ocher zum rein greifen. Im Frontpanel des Basement befindet sich ein zwei-poliger und ein ein-poliger Wippschalter zum Abschalten der gesamten Konsole. Diese trennen sowohl das Netzteil, das Batteriepack und das Ladeger¨at von der Konsole und dienen somit als Hauptschalter.
Carolin Lambeck
4.5.1 Der Geh¨auseentwurf
F¨ur den ersten Entwurf wurde eine Handskizze angefertigt, diese wurde im Verlauf des Projektes, als zunehmend klar war, welche Komponenten eingebaut werden sollen, im CAD-Programm Fusion 360-Autodesk umgesetzt.
Abbildung 3: Erste Handskizze des Geh¨auses. Eigenh¨andige Skizze
Abbildung 4: Finaler Fusion360-Entwurf (CAD) des Geh¨auses. Eigene Abbildung, erzeugt mit dem Programm Fusion 360 von Autodesk
Kim Eschenbach
Nach mehrfachen Ver¨anderungen und neu-Entw¨urfen des Geh¨auses, da runde Formen in der Werk- statt nicht zugeschnitten werden k¨onnen, wurde aus dem finalen Entwurf, ebenfalls mit Fusion- 360, die Zeichnung f¨ur die Materialbeschaffung erstellt. Hierzu wird jedes einzelne Bauteil bemaßt (Draufsicht und Profilansicht) und im PDF-Format als Zeichnung gespeichert. Entsprechend dieser Zeichnungen wird das Material im Baumarkt besorgt und das Geh¨ause in der Werkstatt gebaut.
Dept. Technical reference Created by Approved by
Document type Document status
Title DWG No.
Rev. Date of issue Sheet
16.01.2020
1/1
Gehäuse Entwurf 2 Caro
Max Genson 419.97
200
65.32 320
75.42
820
550
390
Stärke 16 mm, MDF
105°
90°
90°
104.99°
119.99°
Abbildung 5: Finale Zeichnung der Sidepanels mit Bemaßung. Eigene Abb. erstellt mit Fusion-360 Autodesk
Carolin Lambeck
4.5.2 Material
Der Ansatz des 3D-Drucks wurde im Laufe des Projektes verworfen. Das Material ist sehr kosten- intensiv und f¨ur einen entsprechenden CAD-Entwurf muss sehr viel Zeit investiert werden. Sowohl die Mechanik f¨ur den M¨unzeinwurf als auch das Geh¨ause sind daher aus MDF bzw. Plexiglas gefertigt. Aus Gr¨unden der Stabilit¨at ist der Rahmen des Geh¨auses (Sidepanels und Bottom) aus 19 mm MDF-Platten gefertigt. F¨ur Blenden und Ablagefl¨ache wird d¨unneres MDF-Material verwen- det 5 mm. Die Frontplatte des Basements besteht aus klarem Plexiglas um die Einbauten sichtbar zu machen. Die Blende um die sieben-Segment-Anzeige besteht aus schwarzem Plexiglas, welches gruppenintern kostenlos besorgt wurde. Dieses Plexiglas wird auch f¨ur die bewegliche R¨uckwand verwendet. Als Lackierung wurde sich f¨ur roten Effektlack und schwarz entschieden. Beides ist in Form von Spr¨uhlack aufgetragen.
Carolin Lambeck
5 Gruppe 1: CPU
5.1 Aufgabenstellung
Die Aufgaben der CPU-Gruppe sind sowohl die Software-Implementation der Spiele, als auch die Steuerung einer GLCD und einer LED Dot Matrix, die f¨ur die graphische Ausgabe sorgen. Daf¨ur wird Software generiert die auf zwei verschiedenen stm32 Mikrocontrollern implementiert wird.
Diese besitzen folgende Funktionen:
• CPU - Implementation der Spiele
• GPU - Treiber f¨ur die LED Dot Matrix
Die CPU reagiert auf die Gamecontroller und wird als Plattform f¨ur die Spiele benutzt. Der Spiel- zustand wird dann in einer Matrix gespeichert, die an die GPU mittels SPI-Verbidung weitergeleitet wird. Der Versand dieser Daten passiert parallel zur Spiellogik mittels DMA(Direkter Speicher Zugriff). Außerdem werden zus¨atzlich Informationen zu Tonfolgen an die Entertainment Gruppe mittels einer zweiten SPI verbindung gesendet. Die CPU entscheidet durch einen geeigneten Bit, der von der Netzteil-Gruppe gesendet wird, ob das Ger¨at in Sparmodus oder Vollmodus betrieben werden soll.
Die CPU entscheidet am Ende des Spieles auch ¨uber die R¨uckgabe der M¨unzen. Je nachdem wel- cher Spieler gewonnen hat, bekommt er beide M¨unzen.
F¨ur das L¨osen der Aufgaben, ist die CPU-Gruppe in drei Untergruppen geteilt. Die Software-Gruppe, die GLCD-Gruppe und die LED Dot Matrix Gruppe. Bei jeder Gruppe gibt es einen Kommunikations- beauftragten, der sich um die Kommunikation (DMA+SPI1, SPI2) zwischen den Mikrocontrollern k¨ummert.
Etay Yacov
5.2 Blockschaltbild
Abbildung 6: Blockschaltbild CPU Gruppe [18]
Wie es in der Blockschaltbild zu sehen ist, die CPU Gruppe bekommt ein Bit von der Energiever- sogung Gruppe als Eingang auf dem STM32L4(1), dieses Bit sagt uns, ob die Versorgung ¨uber Akku oder Netzspannung erfolgen wird. Im Akkubterieb wird das Graphical LCD als Display f¨ur die Spiele verwendet und im Netzbetrieb wird das Men¨u f¨ur Spielauswhal, score usw. auf dem LCD angezeigt. Die 5 Bits der Interface Gruppe sind f¨ur die Spielcontroller, es wird insgesamt 2 bis 4 Controller geben und daf¨ur werden 2 Bits an der Interface Gruppe zur¨uckgesendet, je nachdem welchen Controller abgefragt wird. Die Kommunikation mit der Entertainment Gruppe f¨ur Tone und Lichte und dem zweiten Mikrocontroller erfolgt per SPI. 14 zus¨atzliche Bits werden f¨ur die Ansteuerung von dem GLCD gebraucht. Der zweite Mikrocontroller wird f¨ur die Ansteuerung von der LED DOT Matrix verwendet.
Mehdi Djait
5.3 CPU -Software und Abstraktion
5.3.1 Dokumentation und Arbeitsentwicklung
Die 8 bit Game Abstraction layer oder 8GAL, ist eine vereinfachte Programmiersprache die wir entwickelt haben um das Programmieren verschiedene Spiele zu erleichtern. Bestimmte abstrakte konzepte, wie ein Board oder Objekte die sich im Raum je nach Input bewegen. Leider wegen des großen Aufwands, der mit die Implementation von 8GAL verbunden ist, ist es uns nicht gelungen, die Sprache zul¨assig zu benutzen. Jedoch, weil 8GAL zu den anderen Teilen der Konsole komplement¨ar ist, in dem sie die h¨ochste Abstraktionsniveau zu dem gesamten Aufbau der Konsole anbietet, ist sie immer noch von Bedeutung zu diesem Projekt.
8GAL basiert sich auf dem Syntax von VHDL, weil dies compiler-freundlich ist, obwohl sie l¨angere Syntax ben¨otigt als andere hohen Programmiersprachen wie Python. Damit k¨onnten wir den Com- piler ohne großen Aufwand implementieren. 8GAL beschreibt ein Spiel in dem es die Objekte die auf dem Bildschirm vorkommen beschreibt, und angibt wie sie sich auf bestimmten Ereignissen reagieren sollte. Die ereignisse sind z. B. wenn ein Timer abgelaufen ist, wenn eine Taste gedr¨uckt wird, oder wenn ein Objekt ein Anderes st¨oßt. Die Reaktion k¨onnte dann eine Bewegung oder eine r¨aumliche ¨Anderung von dem betroffenen Objekt. Ein 8GAL Datei ist in 3 Teile unterteilt.
In dem ersten Teil, werden die Objekte benannt und ihre Attribute beschrieben. Diese Attribute sind primitive Typen (int, char usw.) Danach werden alle m¨ogliche Zust¨ande der Objekten r¨aumlich beschrieben, also wie ein Objekt im Raum aussehen kann. Danach beschreibt der Programmierer die Funktionalit¨at jeder Objekttyp, also wie das Objekt sich auf ereignisse reagiert. Nachdem wird die Initialisierung des Spiels beschrieben. Ein Instanz beschreibt einen Objekttyp, ein Instanzname, Timerl¨ange, und wo auf dem Board das Objekt sich zum Anfang befinden sollte. Somit kann ein Spiel dann realisiert werden. Diese 8GAL code wird dann mit einem Compiler, den wir mit Java geschrieben haben in C-Code ¨ubersetzt. Diese C-Code inkludiert allgemeine Funktionen in einem anderen Datei die in den meisten F¨allen f¨ur ein Spiel ben¨otigt wird (z. B eine Funktion die bestimmt wann ein Stoß zwischen zwei Objekte aufgetreten ist.) Diese C-Datei enth¨alt eine Funktion mit dem Namen von dem Spiel, und kann danach in der Men¨u-C-Datei inkludiert werden, damit das Spiel aus dem Men¨u aufgerufen werden kann.
Etay Yacov
Die 8GAL konnte noch nicht fertig gef¨uhrt werden. Da ein live-Debugging auf dem LED oder GLCD unbehebbare Fehlern gezeigt hat. Es wurden zus¨atzlich 3 Spiele unabh¨angig von der 8GAL entworfen, (Pong, Spacewar und car race ) die als Absicherung dienen, f¨ur den Fall, dass die 8GAL zur Abschlusspr¨asentation noch nicht fertig ist.
F¨ur die Spiele programmieren unabh¨angig von der 8GAL werden vielen hilfreichen Methoden Schritt-
weise implementiert. Dies hat uns erm¨oglicht die Spiele besser zu entwerfen und unseren Code daraufhin auf dem GLCD anzuzeigen, sodass die Spiele im sp¨ateren Ablauf mittels SPI auf dem LED Dot Matrix angezeigt werden kann.
Spieleentwicklungsprinzip:
Hierf¨ur wird das Objektorientiertes Programmierung zum Einsatz aufgerufen, da das Spielfeld als eine Matrix betrachtet werden muss und die Zust¨ande zeitlich ver¨anderlich sind.
Aller erstes wurde die Matrix [i][j] definiert und den Wert 0 zugewiesen f¨ur jede Elemente i, j zwischen 0 und 64, so wird das Spiel Feld leer initialisiert. Dies erfolgt ¨uber die Methode Screen Inizialing().
Der n¨achste Schritt besteht daran die Objekte des Spiels bzw. deren Farbe und Vertikal – horizontal Size zu definieren und die im Matrix zu speichern mithilfe der Methode Write obstacle/car(). Das Verfahren unterscheidet sich zwischen GLCD und LED DOT Matrix nur in einem einzige Einzelheit, und zwar die Farbe da die GLCD nur zwei Farben anzeigen kann. F¨ur Weiß 0 und f¨ur Schwarz 1. Im Vergleich dazu wird die LED DOT Matrix bis zur 8 Farben anzeigen k¨onnen je nach Wunsch der Benutzer. Jeder Farbe kann Name mittels ihr Name aufgerufene wird, diese ist ein Zustand einer sukzessiven bin¨are Reihenfolge von 000 bis 111 die bereits im LED implementiert sind.
Abschließend wird die wichtige Methode zur Bewegung der Objekte betrachtet. Diese ist basiert auf zwei entscheidenden Kriterien ; die Benutzer Eingabe und die Erf¨ullung Bedingungen. Um die Benutzer Eingabe von Analog in die Digital umzuwandeln, wird eine Test Pin () Funktion imple- mentiert, die, falls eine Bet¨atigung der Knopf eine boolean Wert true zur¨uckgibt. Die Bewegung Bedingungen l¨asst sich vom Benutzer zur anderer unterscheiden je nach Spiel und Ziel. Dies muss nun in einem UND Logik Beziehung mit dem entsprechenden Pin legen. Wenn beide Kriterien erf¨ullt sind, kann sich die Matrix mit Hilfe ihre Anfangsoffset in X und Y-Richtung bewegen.
Einen Letzten wichtigen Aspekt, der Spiel Programmierung ist, wenn das Spiel zur Ende kommen muss, die sogenannte GAME OVER Funktion. Die Spiel Ende Bedingungen unterscheiden sich hier auch vom Benutzer zur einander aber das Ziel ist das selber. Die Spiel wird unterbrochen, in dem man die gesamte Matrix den Wert 0 zuweist und die Spiel Ende Anzeige in einer unendliche While Schleife implementiert.
Khaled Mejri
5.3.2 Zustandsdiagramm
Abbildung 7: Zustandsdiagramm: Softwareabstraktion [19]
5.3.3 Schaltplan
Abbildung 8: Schaltplan CPU [20]
5.3.4 Layout
Abbildung 9: CPU Layout [20]
5.3.5 Platine
Abbildung 10: CPU:Central processing unit Platine
• L¨ange: 160mm
• Breite: 98mm
Khaled Mejri
5.3.6 Zusammenfassung
Die Software-Gruppe besch¨aftigt sich mit Abstraktion der Spielprogrammierung und die Implemen- tation der Spiele auf Software Ebene. Außerdem k¨ummert sich diese Untergruppe um den Versand der Daten ¨uber SPI an die n¨achste Ebene. Wegen des Zeitmangels ist es uns nicht gelungen einen funktionierenden Compilor f¨ur 8GAL fehlerfrei zu produzieren. Um uns vor diesem m¨oglichem Sze- nario zu sch¨utzen, hat unsere Untergruppe als Ersatzplan, unabh¨angig von der 8GAL-Logik in einer nicht abstrakte Art und Weise 3 Spiele implementiert. Diese haben wir angewendet, damit das Projekt weiterlaufen kann. Die andere Aufgaben von unseren Gruppe, n¨amlich die Komunikation zwischen Master und Slave, haben wir implementiert.
Etay Yacov
5.4 CPU - LED DOT Matrix
5.4.1 Dokumentation und Arbeitsentwicklung
Die LED Dot Matrix Gruppe besch¨aftigt sich mit der Ansteuerung eines 64x64 Light-Emitting Diode (LED) Dot Matrix Displays.
Es wurde durch die Mehrheit entschieden, einen STM32 Mikrocontroller zu verwenden, da er die ben¨otigte Geschwindigkeit f¨ur die LED Dot Matrix-Ansteuerung besitzt. F¨ur die Programmierung des SMT32-µCs werden die programme STM32CubeMX und STM32Cube IDE verwendet. Mithilfe von STM32CubeMX kann man die Pin-Funktionalit¨at des Mikrocontrollers einstellen und durch STM32CubeIDE die Ansteuerungsfunktionen programmieren. [21] [22] [23]
Hierf¨ur wurde mit hilfe der Untergruppe Software und Abstraktion ein Programm zur Ansteuerung der LED Matrix geschrieben, welches auf der Hardware Abstraktions Schicht basiert ist. Dieses hat jedoch Flackern erzeugt. Grund daf¨ur war, das versp¨atete Clocksignal und die verschwendung von Zeit beim Zugriff der Register ¨uber die HAL-funktionen. Im Vergleich dazu eignet sich der direkte Registerzugriff (¨uber das low Layer) ganz gut f¨ur eine schnellere bearbeitung der Befehle, was ein besseres FPS-verh¨altniss erzeugt(FPS : Frame per second).
Wie funktioniert eine LED Dot Matrix?
Eine LED Dot Matrix ist eine Zusammenfassung von mehreren LEDS, deren Kathoden und Anoden in Zeilen bzw Spalten verbunden sind. Die Funktionsweise kann mit blossen Auge nicht erkannt werden. Eigentlich funktioniert die LED Matrix so, dass immer nur eine Spalte oder Zeile wirk- lich leuchtet und die Multiplexingfrequenz sehr hoch ist . Die anderen sind aber ausgeschaltet.
Wird jede Spalte oder Zeile einmal in schneller Folge angeschaltet, entsteht wegen der Tr¨agheit des menschlichen Auges ein vollst¨andiges Bild,bei dem wird deutlich gesehen dass alle angesteu- erten LEDS gleichzeitig leuchten. Es wurde bei der Gruppe LED DOT Matrix ein Mikrocontroller STM32L476RG in Half Duplex Slave Mode und ein RGB LED DOT Matrix von der Firma JOYIT benutzt. Daf¨ur wurden die Pins des Mikroconrollers so belegt, dass sie den Inputs der LED DOT Matrix entsprechen. Eine LED Dot Matrix hat insgesamt 16 Pins: R1-G1-B1-N-R2-G2-B2-LA-LB- LC-LD-LE-CLK-LAT-GND
-R1-G1-B1: diese drei Pins sind f¨ur die Farben Rot,Gr¨un und Blau f¨ur die obere H¨alfte der Matrix verantwortlich.
-R2-G2-B2: diese drei Pins sind auch f¨ur die Farben Rot,Gr¨un und Blau f¨ur die untere H¨alfte der Matrix verantwortlich.
-LA-LB-LC-LD-LE: diese 5 Pins dienen der Ansteurung der Zeilen Multiplexer und damit k¨onnen 32 Zeilen angesteuert werden . Die f¨ur die Recherche verwendeten Quellen sind unter [21] [24] [22] [23]
aufgef¨uhrt
RGB
Pins der Mikrocontroller Inputs der LED Dot Matrix
PC0 R1
PC1 G1
PC2 B1
PC3 R2
PC4 G2
PC5 B2
Multiplexing
Pins der Mikrocontroller Inputs der LED Dot Matrix
PC6 LA
PC7 LB
PC8 LC
PC9 LD
PC10 LE
Mit diesen 5 Pins k¨onnen jeweils 25 = 32Zeilen angesteuert werden.
Beispiel:
Alle 5 Pins sind auf 0 gesetzt=⇒die erste Zeile leuchtet.
Wenn LA auf 1 gesetzt ist und alle anderen Pins auf 0 gesetzt sind, dann leuchtet die zweite Zeile Hier spielen Schieberegister eine grosse Rolle bei der Funktionsweise.
Was ist ein Schieberegister ?Ein Schieberegister ist ein logisches Schaltwerk,Das aus mehreren in Reihe geschalteten Flipflops besteht, die bei jedem Arbeitstakt ihren Speicherinhalt um ein FlipFlop weiter schieben. Die JOY IT LED Dot Matrix hat ICND2038S als Schieberegister und die Pins m¨ussen wie im folgenden Bild eingestellt werden, damit die LED Dot Matrix richtig funktioniert.
Abbildung 11: Pins der Schieberegister [25]
Wie funktioniert ein Schieberegister?
Wenn LE auf 1 gesetzt ist , k¨onnen die Data ¨ubertragen werden.Pro Zeile kommen 4 Schieberegister zum Einsatz und jede kann 16 Bits ¨ubertragen . Wenn die 16 Bits der ersten Schieberegister zu den n¨achsten geschickt werden und LE auf 1 gesetzt ist, werden die letzten 16 Bits gespeichert usw.
Pins der Mikrocontroller Inputs der LED Dot Matrix
PB3 Latch
PB4 Output Enable
PB5 Clock
Abbildung 12: Pins der Mikrocontroller [26]
Aziz Gharbi
Weiterhin besch¨aftigt sich diese Gruppe mit der Daten¨ubertragung zwischen den beiden STM32 Mikrocontrollern. Auf dem erstenµC werden die Spiele geschrieben und auf dem zweiten, sind die Ansteuerungen zur Ausgabe der LED-Matrix enthalten. F¨ur eine schnelle Kommunikation verf¨ugt STM32 ¨uber einen Direkt Memory Access, den sogenannte DMA. Zwischen den zwei jeweiligen Mikrocontroller-DMAs, bietet sich zum Austausch der Daten, eine Serial Peripherie Interface (SPI).
Dies wird demn¨achst das Thema der Untersuchungen sein um letztendlich die Spiele auf dem LED
ausgeben zu k¨onnen.
Abbildung 13: SPI leitungen [27]
MOSI: Master output / Slave input MISO: Master input / Slave output
SCLK: Serial clock , Schiebetakt ( die wird vom Master zur synchronisation ausgegeben) NSS/ CS: Slave Select oder Chip Select
Pins der Mikrocontroller Pins der SPI
PA7 MOSI
PA6 MISO
PA5 SCK
PA4 NSS
Tabelle 3: Recieve Seite als Full Duplex Slave Mode
Pins der Mikrocontroller Pins der SPI
PA15 MOSI
PC10 MISO
PC11 SCK
PC12 NSS
Tabelle 4: Transmission Seite als Full Duplex Slave Mode
Wie funktioniert das SPI-Komminikationsprotokoll?
Das Serial Peripheral Interface (SPI) ist ein Bus-System zur synchronen, seriellen Daten¨ubertragung
zwischen einem Master und einem oder mehreren Slaves. Sein Hauptfunktion ist die Erstellung einer kommunikation zwischen zwei Mikrocontroller. Bei SPI verlieren die Begriffe’senden’ und
’Empf¨angen¨ıhre Bedeutungen.
Grunds¨achlich funktioniert das ¨Ubertragungsprinzip so , dass gleichzeitig 1 bit von Master zum Slave , und 1 bit von Slave zur Master ¨ubertragen wird .
Jedoch die Daten¨ubertragung erfolgt erst nach den Einstellung von den Parameter : CPOL: Clock polarity
CPHA : Clock phase
Abbildung 14: CPOL und CPHA einstellungen [26]
Was ist Direct Memory Access DMA ?
DMA oder Direkt Speischerzugriff ist eine Schaltungs- und Steurungmassnahme zu verstehen, die ¨uber Spezielle Datenleitungen auf dem Motherboard eine Verbindungzwische. dem Ein- und Ausgabeeinheiten und dem Arbeit Speicher erstellt. dadurch k¨onnen die Daten ohne umweg ¨uber Den Prozessor direkt Zu den Speicher geschrieben werden.
Abbildung 15: DMA [28]
Iheb Nagga
5.4.2 Schaltplan
Abbildung 16: Schaltplan LED DOT Matrix [20]
5.4.3 Layout
Abbildung 17: LED DOT Matrix Layout [20]
5.4.4 Platine
Abbildung 18: GPU:Graphik Card platine
• L¨ange: 160mm
• Breite: 98mm
Iheb Nagga
5.4.5 Zusammenfassung
Die LED Dot Matrix Gruppe besch¨aftigt sich mit der Ansteuerung eines 64x64 LED Dot Matrix Displays. Weiterhin wird es von dieser Untergruppe um die Daten¨ubertragung zwischen den Beiden STM32 Mikrocontrollern k¨ummert. Damit die Kommunikation schneller wird , verf¨ugt STM32
¨uber einen Direkt Memory Access (DMA). Um die Daten zwischen den zwei Mikrcontroller-DMAs auszutauschen, steht eine Serial Peripherie Interfacen (SPI) zur Verf¨ugung.
Aziz Gharbi
5.5 CPU -Graphical LCD
5.5.1 Dokumentation und Arbeitsentwicklung Einleitung:
Die Aufgabe der CPU-GLCD Untergruppe ist die Ansteuerung eines LCD Bildschirm [29], der f¨ur die Ausgabe von Spiele oder Men¨u verwendet wird. Zur Verf¨ugung steht ein 128x64 LCD Grafikdisplays mit LED-Hintergrundbeleuchtung mit der Artikelnummer: DEM 128064A SBH-PW-N [30] [31]. Die zwei SBN6400G [32] integrierten Controller des LCD [31] werden mittels eines Mikrocontrollers von der STM32 Mikrocontroller-Familie mit einer 32-Bit ARM Cortex-M4F CPU [33]angesteuert. Die LCD Ansteuerung erfolgt ¨uber das Programm CubeIDE [34] von STMicroelectronics und wird in der Programmiersprache C implementiert. Es wurde als erster Schritt ein library programmiert, dieses Library besteht aus: ein main library Datei GLCD.c und ein Header Datei GLCD.h. Dieses Library wird genauer im Abschnitt ’GLCD Ansteuerung mit STM32’ erkl¨art. Das Graphical LCD verf¨ugt
¨
uber die folgenden Pins:
Abbildung 19: GLCD Pins [31]
Die Pins mit den Nummern 1, 2, 3, 19 und 20 des LCD Displays wurden nach ihrer Beschreibung im Datenblatt wie folgend verbunden: VSS Pin mit 0V, VDD Pin mit 5V, V0 mit einem Potentiometer um das Kontrast von dem Bildschirm zu kontrollieren, LED+(A) mit 3V und LED-(K) mit 0V.
Das Graphical LCD wird in 8-bit parallel Modus betrieben, bzw. die 8 Data bit von DB0 bis DB7
werden alle f¨ur die parallel f¨ur die Daten¨ubertragung verwendet. Wenn RS auf LOW gesetz ist, die angelegten 8 Data bits werden als Befehl interpretiert, und wenn auf HIGH, das byte ( die 8 bit Zahl von DB0 bis DB7) wird als Datenbyte interpretiert, bzw. wird auf dem LCD angezeigt. Da es in den Programme auf den Bildschirm geschrieben wird, wird das Pin R/W auf LOW gesetzt, mit R/W = 1 kann aus dem LCD gelesen werden, was bei der Verwendung von dem LCD bei diesem Projekt nicht gebraucht wird. Das Pin E signalisiert dem LCD, dass die gew¨unschten Daten von Datenleitungen oder Kommandos ¨ubernehmen werden k¨onnen. Das GLCD ist gleichm¨aßig in zwei H¨alften geteilt. Jede H¨alfte wird jeweils von einem SBN6400G Controller gesteuert.Pin CS1 muss auf high und CS2 auf LOW gesetzt werden, um die linke H¨alfte zu w¨ahlen und umgekeht f¨ur die rechte H¨alfte. RSTB wird f¨ur das Zur¨ucksetzen von dem GLCD verwendet. [35] [36]
Mehdi Djait
Men¨u:
Das Men¨u ist die Schnittstelle des ger¨at, wo man die spiele, die Farben, der Anzahl der Spiele w¨ahlen kann. Das Men¨u besteht sich selbe aus viele Funktionen und Methoden, die in folgende erkl¨art wurden.
void Updatemen¨u():
Die Update-Men¨u Methode ist die erste Methode, die direkt nach der Er¨offnung der Konsole ab- gerufen wird. Anhand dieser Methode kann das Hauptmen¨u angezeigt werden, wo der Wahl der Spiele, der Farbe, der FAQ m¨oglich ist:
• 1-Spiele
• 2-Farbe
• 3-FAQ
• 4-EXIT void Spiele():
wenn der User im Hauptmen¨u spiele w¨ahlt wird er direkt zurSpiele()Methode weitergeleitet. Die Funktionalit¨at dieser Methode ist die Anzeiger der Namen der Spielen und zwar:
• 1-Snake
• 2-Pingpong
• 3-Tetris
• 4-STWRS
• 5-Bricks
• 6-CarRace
• 7-Tron
• 8-Return void Farbe():
Um jede ihre Charaktere in der Spiele, wenn es in Multiplayer Modus ist, besser zu Verzeichnen, wurde es besser verschiedene Farben zu w¨ahlen und das was die Methode Farbe() erm¨oglicht.
void FAQ():
Die FAQ Methode informiert der User ¨uber die Name der Konsole und das Datum des Projekt void EXIT():
Exit Methode erm¨oglicht der Benutzer die Konsole auszumachen.
uint8 t Number():
Nach der Wahl der Spiele muss man der Anzahl der Spieler durch die Funktion Number definieren.
Diese Funktion zeigt zahlen von 1 bis zum 4. Wenn man ein zahl davon w¨ahlt, wird es als die Ausgabe der Funktion definiert. Diese Zahl wird als ein Eingabe f¨ur die gew¨ahlte Anzahl der Spieler benutzt.
Mohamed Amine Elakel
GLCD Ansteuerung mit STM32
In diesem Abschnitt wird Schritt f¨ur Schritt erkl¨art wie die Ansteuerung einer Graphical LCD mit dem STM32 Mikrokontroller erfolgt:
GLCD Delay(uint16 t timer)
Die integrierte HAL Delay Funktion von STM32CubeIDE wurde nicht verwendet und es wurde stattdessen eine einfache Delay Funktion programmiert, die uns erm¨oglicht sehr kleine Delays aus- zuf¨uhren. Die GLCD refresh Funktion dient hier als Trigger Funktion f¨ur das Senden von Daten, damit Befehele in das MPU geschrieben werden k¨onnen, muss Enable Pin einmal auf HIGH und dann auf LOW gesetzt werden mit einem Delay inzwischen, bzw. Enable signalisiert dem LCD, dass die gew¨unschten Daten von Datenleitungen oder Kommandos ¨ubernehmen werden k¨onnen .Die Konstante ’ref’ als Parameter f¨ur die GLCD Delay Funktion wurde hier durch Ausprobieren als 100 gew¨ahlt.
void GLCD RESET()
Das GLCD wird mittels der GLCD RESET() Funktion initialisiert. Diese Funktion l¨oscht alle an- gelegten Bits an den 20 Pins des Displays. RSTB wird einmal auf LOW gesetzt danach wird ein Delay aufgerufen und dann RSTB wieder auf HIGH.
GLCD CHIP SELECT(uint8 t CS)
Wie in der Einleitung schon erw¨ahnt wurde, der Bildschirm wird in zwei H¨alften geteilt. Es wurde hier ein Chip Select Funktion erstellt f¨ur die Ansteuerung von den 2 Controller, bzw. um w¨ahlen zu k¨onnen, auf welche H¨alfte geschrieben wird. Wenn die Funktion 0 als Argument bekommt, wird auf der linken H¨alfte geschrieben, wenn CS=1, es wird auf der rechten H¨alfte geschrieben.
GLCD Set Data(uint8 t car)
Um die 8 Data Bits DB0 bis DB7 von dem GLCD zu setzen wird die GLCD Set Data Routine implementiert. Diese Funktion bekommt car als Parameter, ein 8 bit unsigned integer. Jedes Data Bit (DB) wird mittels Logik Funktionen auf Eins oder Null gesetzt werden. Mit dieser Funktion Werden Daten- und Kontrollbefehle an dem GLCD gesetzt.
void GLCD DISPLAY ON()
Um die LCD Anzeige AN zu machen, es wurde zun¨achst die folgende Funktion implementiert.
Zuerst wird die linke Seite angemacht. Da es sich hier um ein Befehl handelt und auf dem Befehl- register zugegriffen wird zugegriffen wird, werden die RS und R/W Pins auf LOW gesetzt. Hier ist zu beachten, dass DB0 auf 1 gesetzt werden muss, um das Display AN zu machen. Nach einem Aufruf von den Refresh Funktion wird die rechte Seite angemacht.
GLCD SEND DATA(char car) & GLCD DISPLAY START X/Y
Damit die Controller von dem GLCD die angelegten Bits mit der Set Data Funktion auf dem Bildschirm anzeigen, es wurde die Send Data Funktion programmiert. C/D wird zuerst auf HIGH ge- macht und R/W auf LOW, weil es hier geschrieben wird. Danach werden die Bits mit GLCD Set Data gesetzt und anschließend wird die Trigger Funktion Refesh aufgerufen damit das Befehl ¨ubernehmen werden kann. Jede H¨alfte von dem LCD besteht aus 8 Seiten, wobei jede Seite aus 8 Zeilen und 64 Spalten besteht, Display Start X Funktion bezieht sich auf die Seiten von 0 bis 7, Display Start Y Funktion bezieht sich auf den Spalten von der jeweiligen Seite, wobei DB5 bis DB0 auf eine Zahl zwischen 0 und 63 gesetzt werden kann.
void GLCD ClearScreen()
Eine Funktion f¨ur die Initialisierung von dem Bildschirm wurde implementiert. Die Funktion besteht aus 3 For Schleifen, die erste geht durch die zwei H¨alften von dem LCD, die zweite Schleife geht durch die 8 Seiten der jeweiligen H¨alfte und die dritte Schleife setzt DB0 bis DB7 auf Null f¨ur die 64 Spalten von der jeder Seite. Mit dem logischen Zustand 0 werden die Segmente, die aus 8 Pixeln bestehen kein Licht durchlassen.
GLCD PRINT MATRIX(uint8 t matrix[64][64])
Als letzte Funktion von dem GLCD.c library wurde eine Print Matrix Funktion implementiert, die
eine 64x64 Matrix auf dem GLCD anzeigt, es wurde zuerst das Parameter von der SEND Data Funktion als Variable in der Funktion definiert. Die linke H¨alfte wird zuerst geschrieben, 3 Schleifen werden f¨ur jede H¨alfte verwendet. Die erste Schleife geht durch die 8 Seiten, die zweite geht durch die Spalten von der H¨alfte der Matrix, bzw. die ersten 32 Spalten, die dritte Schleife setzt mittels Logik Operationen die Bits von der Variable Data. Zwei if Anweisungen wurden f¨ur die rechte und linke Grenzen des Displays verwendet, hier wird die Matrix genau in der Mitte vom GLCD angezeigt, bzw. die ersten Spalte 0 bis 32 auf der linken H¨alfte und Spalte 33 bis 64 auf der rechten Seite.
Nach jeder Schreibung von Data werden die Display Start X und Y Funktionen inkrementiert.
Mehdi Djait
5.5.2 Schaltplan
Abbildung 20: Schaltplan GLCD [20]
5.5.3 Layout
Abbildung 21: GLCD Layout [20]
5.5.4 Platine
Abbildung 22: GLCD Platine
• L¨ange: 160mm
• Breite: 98mm
5.5.5 Zusammenfassung
Es wurde eine Bibliothek f¨ur die Ansteuerung von dem GLCD mit dem Mikrocontroller STM32 erstellt und deren Funktionen in dem Bericht erkl¨art, es wurde zus¨atzlich ein Men¨u f¨ur die Auswahl von Spiele entwickelt. Das GLCD wird je nach Betriebsart als Bildschirm f¨ur die Spiele oder nur f¨ur Men¨u verwendet.
Mehdi Djait
6 Gruppe 4: Interface
Ein Interface ist eine Schnittstelle, also der Teil eines technischen Systems, der zur Kommunikation zwischen Systemen und Individuen dient. In diesem Sinne ist die GruppeInterface f¨ur die Schnitt- stelle zwischen Anwender und Maschine zust¨andig. Eine detaillierte Erl¨auterung der Aufgaben der Gruppe Interface erfolgt im folgenden Abschnitt.
Lukas Karal
6.1 Aufgabenstellung
Die Gruppe Interface hat die Aufgabe die Schnittstelle zwischen dem Anwender und dem 8-Bit- Waffeleisen zu realisieren. Das umfasst die Konzeptionierung und den Bau von Eingabeger¨aten, hier als Game-Controller oder kurz Controller bezeichnet und eine 7-Segment-Anzeige, die dem Anwender den Spielstand zur Laufzeit anzeigt. Hierzu gibt es jeweils eine Untergruppe. (siehe hierzu Abschnitt 6.3 und 6.5 )
Des weiteren implementiert eine Untergruppe einen hardwarebasierten Pseudo-Zufallszahlen-Generator (PRNG). Dieser erzeugt zuf¨allige Bit-Muster im englischen als pseudo-random-binary-sequence be- zeichnet (PRBS) auf Grundlage eines 16-Bit linear-r¨uckgekoppelten Schieberegisters, die Bit-Folgen werden erfasst, zu Zahlen im Bereich[0. . .63]zusammengefasst und sollen den anderen Gruppen zur Verf¨ugung gestellt werden. Dazu wid ein Programm, welches auf dem STM32 der Entertainment- Gruppe l¨auft implementiert werden, welches das linear-r¨uckgekoppelte Schieberegister ansteuert.
Lukas Karal
6.2 Blockschaltbild
In Abbildung 23 ist das gemeinsame Blockschaltbild der Gruppe Interface dargestellt. Es umfasst die Teilprojekte Game-Controller, Pseudo-Random-Number-Generator (PRNG) und 7-Segement- Anzeige. Aus der Abbildung 23 wird die Vernetzung der Gruppe zu den anderen Gruppen ersichtlich.
So werden der PRNG und und die 7-Segement-Anzeigen ¨uber einen STM32-Mikocontroller gesteu- ert, der von der GruppeEntertainmentverwaltet wird. Dar¨uber hinaus werden die Controller direkt an die Platine der GruppeCPU geschlossen, um auftretende Latenzen m¨oglichst gering zu halten.
Lukas Karal
Abbildung 23: Blockschaltbild f¨ur die Gruppe Interface.(Eigene Abbildung erzeugt mit yEd)
6.3 Interface – Gamecontroller
Aufgabenstellung
6.3.1 Dokumentation und Arbeitsentwicklung
F¨ur die Spieleingabe sollen zwei Controller entworfen werden. Statt einen eigenen Mikrocontroller zu verwenden, wird das Problem mit analoger Elektronik gel¨ost.
Als genaue Aufgabe wurde festgelegt: die Eingangssignale von bis zu vier Controllern mit jeweils 6 Kn¨opfen (Rechts, Links, Oben, Unten, A und B) sollen ¨uber eine 5-Bit Leitung an die CPU Gruppe
¨ubermittelt werden. Damit sind die Anforderungen der urspr¨unglich geplanten Spiele Pong, Snake und Tetris sowie die Navigation in einem Men¨u abgedeckt.
Beschreibung Blockschaltbild: Der Ausgang der Controller geht an 5 4x1 Multiplexer, die von der CPU Gruppe mit einem 2-Bit Signal angesteuert werden. So k¨onnen die Zust¨ande der einzelnen Controller abwechselnd abgefragt werden. Alle Controller funktionieren auf die gleiche Weise.
Um zu verhindern, dass ein Knopfdruck mehrfach eingelesen wird, wird das Signal der einzelnen Taster zun¨achst mit einem Kondensator entprellt.
Jedem Zustand des Steuerkreuzes wird ¨uber eine Logikschaltung eine 3-Bit Zahl (siehe Tabelle 5) zugeordnet, die mit D-Flip-Flops zwischengespeichert wird. Die Flip-Flops sind so beschaltet, dass man den Eingang sperren und den aktuellen Ausgang halten kann, sie haben also praktisch einen
”Enable-Port” [37]. Nach kurzer Verz¨ogerung durch eine Delay-Schaltung nutzt man diese Funktion, damit eine weitere Eingabe nicht registriert wird w¨ahrend ein Knopf gedr¨uckt ist. Der Ausgang liefert das Signal des zuerst bet¨atigten Tasters. Das Signal des A- und B-Tasters wird je separat als 1- Bit Signal ¨ubermittelt. Die Delay-Schaltung wird mit einem Kondensator und einem OPV als Komparator realisiert.
William Selbherr
Stand der Dinge (Dezember 2019) – Bisherige Entwicklung der Komponenten der Gamecontroller Die Entprellung ist auf dem Steckbrett f¨ur Testkn¨opfe realisiert, muss aber noch an die neuen Arcadekn¨opfe die auch in den Gamecontrollern verbaut werden angepasst werden. Hier muss die Kapazit¨at der Entprellkondensatoren nochmal ermittelt werden. Die Logik- schaltung (Abb. 25) ist bestimmt und in Hades bin¨ar und mit idealen Komponenten simuliert.
Diese muss nun weiter mithilfe von LTSpice in 74er Logik umgesetzt werden und anschließend un- ter realen Bedingungen auf dem Steckbrett getestet werden. Der invertierte Delay (Abb. 27) ist in LTSpice simuliert und ohne Inverter auf dem Steckbrett aufgebaut und getestet. Der Inverter [38]
muss noch mithilfe von zur Verf¨ugung stehenden Transistoren dimensioniert, gebaut und getestet werden. Er soll zus¨atzlich zum Invertieren des Signals den Offset des OPVs entfernen. Die FlipFlops mit Enable-Port (Abb. 26) sind ideal in Hades bin¨ar simuliert und m¨ussen noch mithilfe von LT- Spice auf real existierende Bauteile ¨ubertragen und am Steckbrett getestet werden. Die Multiplexer Schaltung ist noch nicht entwickelt da diese auf einer externen Platine im Hauptgeh¨ause und in enger Zusammenarbeit mit der Mikrocontroller-Gruppe geplant werden muss.
Raphael Klarwein
6.3.2 Schaltplan
Abbildung 24: Blockschaltbild f¨ur den Gamecontroller (Abb. erzeugt mit yEd)
Bit 1 Bit 2 Bit 3
Links 0 0 1
Oben 1 1 0
Rechts 0 1 0
Unten 1 0 0
Tabelle 5: Zustandstabelle f¨ur das Steuerkreuz(selbst erstellt)
Abbildung 25: Logik f¨ur das Steuerkreuz (Abb. selbst erstellt mit Notability)
ClockGen
i9 clk
DFFR
i0 D
C
NR
Q
NQ Mux21
A1
A0 S
Y
i1 i2
i3
i4 i5 i6
INV
i7
A Y
INV
i8
A Y
Abbildung 26: D-Flip-Flop mit Enable-Port (eigene Aufnahme aus Hades) [3]
Abbildung 27: Delay-Schaltung (eigene Aufnahme aus LTSpice)
Abbildung 28: Schematic f¨ur den Gamecontroller (eigene Aufnahme aus Eagle)
Zuerst wurden die Taster ausgemessen und mithilfe von 1nF Kondensatoren entprellt, um St¨orverhalten durch Prellen zu verhindern. Anschließend wird dem Signal eines gedr¨uckten Knopfes des Steuer- kreuzes mithilfe der Logikschaltung zu eine 3-Bit-Zahl zugeordnet. Die Signale f¨ur die Aktionstasten werden direkt an den Controller-Ausgang weitergeleitet. Gleichzeitig wird das Knopfsignal zusam- mengef¨uhrt, wobei durch Dioden eine R¨uckkopplung verhindert wird, und an die Delayschaltung gebracht. Die Delayschaltung besteht aus einem Operationsverst¨arker als Komparator und einem vorgeschalteten RC-Glied. Am positiven Eingang des OPVs liegt eine Referenzspannung an, die
mit einem Spannungsteiler gesetzt ist. Der Ausgang des RC-Glieds liegt am negativen Eingang des OPVs an. Steigt dieser ¨uber die Referenzspannung, ¨andert sich der Ausgang des OPVs auf
”Low“.
Das ged¨ampfte Ausgangssignal des Operationsverst¨arkers wird mithilfe von zwei MOS-Transistoren invertiert und wieder auf 5V hochgezogen. Das verz¨ogerte Signal sowie das 3-Bit-Datensignal wird an 3 D-Flip-Flops mit selbst konstruiertem Enable-Port durch einen vorgeschalteten Multiplexer gegeben. Dabei hat man den Ausgang des Flip-Flops an einen Eingang des 2x1 Multiplexers r¨uckkoppelt und somit ¨uber dessen Selection-Eingang des ein Enable-Port entsteht. Dieser wird mit dem verz¨ogerten invertierten Signal verbunden, um die Eingabe anderer Signale zu sperren und gleichzeitige Eingaben zu verhindern. Die Ausg¨ange der FlipFlops sowie der Aktionskn¨opfe und ein Pr¨ufsignal, ob ein Controller angesteckt ist werden ¨uber M10-Stecker und Kabel an die Platine im Geh¨ause gegeben. Hier werden mithilfe von sechs 4x1 Multiplexer alle Signale der vier Control- ler mithilfe eines 2-Bit-Selectionsignals der Microcontrollergruppe an einen weiteren M10-Stecker
¨ubermittelt, der jeweils den Status des angefragten Controllers an die Platine der Microcontroller- gruppe ¨ubertr¨agt.
Raphael Klarwein
Abbildung 29: Schnittstelle zwischen Gamecontroller input und Mikrocontrollergruppe (Auf- nahme aus Eagle)
6.3.3 Layout
Das Layout wurde mithilfe von Eagle erstellt und ist den Voraussetzungen zur Fertigung des Pro- jektLabors angepasst. Die Platine des Gamecontrollers ist ausserdem so dimensioniert, dass vier St¨uck auf eine Europlatine passen.
Raphael Klarwein
Abbildung 30: Layout der Platine des Gamecontrollers (Aufnahme aus Eagle)
Abbildung 31: Layout der Platine der Schnittstelle (Aufnahme aus Eagle)
6.3.4 Platine
Auf der Platine sind oben aufgereiht die Steckverbindungen f¨ur die Taster zu erkennen. Die ICs sind ¨uber Sockel auf der Platine montiert, damit sie ohne zu L¨oten ausgetauscht werden k¨onnen.
Alle anderen Komponenten sind Throughhole-Bauteile.
Raphael Klarwein
Abbildung 32: Best¨uckte Platine eines Gamecontrollers (Top)
Abbildung 33: Best¨uckte Platine eines Gamecontrollers (Bottom)
6.3.5 Zusammenfassung
Die Gruppe Gamecontroller hat die Aufgabe, dass Eingabe von Spieler zu Spielautomat zu ent- wickeln. Dabei spielt vor allem die Entprellung der Taster und die Umwandlung des Signals zur Weitergabe an den STM32 der CPU-Gruppe eine Rolle. Die Game-Controller werden aus Gr¨unden der Latenz direkt an die Platine der CPU-Gruppe angeschlossen. Es wurden zuerst Testschaltun- gen recherchiert und aufgebaut. Anschließend wurde das Platinen-Layout entworfen, die Platine gefertigt, best¨uckt und getestet.
6.4 Interface – Pseudo-Random-Number-Generator (PRNG)
6.4.1 Dokumentation und Arbeitsentwicklung Theorie
Linear r¨uckgekoppeltes Schieberegister Zur Erzeugung einer pseudozuf¨alligen Bitfolge eignen sich linear r¨uckgekoppelte Schieberegister . Das folgende Bild zeigt ein linear r¨uckgekoppeltes Schieberegister mit n = 4 Stellen; diese seien mitr1, r2, r3, r4 Element 0, 1 vorbesetzt. Diese Werte werden mit dem Seed a1, a2, a3, a4 Element 0, 1 multipliziert (logisches Und) und anschließend modulo 2 addiert (logisches Exklusiv-Oder). Das Ergebnis wird im n¨achsten Takt an die Stelle von r1 ¨ubernommen; die vorherigen Werte werden alle um eine Stelle nach links weitergeschoben, r4 wird ausgegeben [39].
Abbildung 34: Prinzip eines linear r¨uckgekoppelten Schieberegisters
Rihane Youssef
Rihane Youssef
Funktion der Gruppe Die Aufgabe der Untergruppe PRNG besteht darin, ein linear r¨uckgekoppeltes Schieberegister aufzubauen, das st¨andig Pseudo-Random Numbers (216-1 Kombinationen) gene- riert. Daf¨ur werden Zwei Seriellen 8-Bits-Schieberegister, Die ¨uber eine Logikschaltung r¨uckgekoppelt sind.
Abbildung 35: Blockschaltbild f¨ur den PRNG [4]
Die Schieberregistern bekommen ein regelm¨aßiges Clocksignal, wobei bei jedem Clockimpuls ein zuf¨alliges Bit zu dem STM32 r¨uckgesendet wird.
Der Seed (16 Bits) wird durch init. seriell in den dazu geh¨origen Schieberegistern gespeichert.
Der Reset Signal dient dazu alle Speicherelemente von den Schieberegistern auf 0 zu Setzen.
Rihane Youssef
Steckbrett Realisierung des PRNG als 4-Bit Version Die Untergruppe PRNG hat zun¨achst einen Prototypen der Schaltung f¨ur den PRNG auf einem Steckbrett mit 74xx-Logikgattern als 4- Bit Version aufgebaut. Dieser Versuch dient der ¨Uberpr¨ufung der Machbarkeit, bevor das Layout der Platine erstellt wird.
(a) Prototyp PRNG in 4-Bit Version. (b) Verdrahtetes Schieberegister 74xx-Logik.
(c) Versorgung, Clck-Signal und Oszilloskop zur Si- gnaldarstellung.
(d) Signalverlauf des erzeugten zuf¨alligen Bit- Musters.
Abbildung 36: Versuchsaufbau eines Prototypen des PRNG in einer 4-Bit Version auf Grund- lage von 74xx-Logik.
In der Abbildung 6.4.1 ist der gebaute Prototyp dargestellt. In Teilabbildung 36(a) ist der verdrah- tete Steckbrettaufbau des Prottyp dargestellt. Die Schaltung ist in 74xx-Logik realisiert. Von Links nach rechts sind ein Schieberegister ein 4x2er AND-Gatter und ein 4x2er XOR-Gatter verbaut. Die Versorgungsspannung liegt bei 5 V, die Logik-Pegel liegen bei 3.3 V. In der Teilabbildung 36(b) ist das verdrahtete Schieberegister dargestellt. Die R¨uckkopplung erfolgt ¨uber den grauen Draht.
Zur Versorgung und um die Logik-Pegel zu realisieren wird eine Laborspannungsquelle, in Teilab- bildung 36(c) dargestellt verwendet. Die Clock des Schieberegisters wird ¨uber ein Signalgenerator (Rechteck + Offset) simuliert. Das erzeugte Signal wird ¨uber einen Oszilloskop dargestellt. In Teilabbildung 36(d) ist das erzeugte Bitmuster dargestellt. Der Prototyp funktioniert wie erwartet, sodass er im folgenden verwendet wird, um die auf dem STM32 zu realisieren Funktion zu testen.
