LEDschaltung im PingPong

[oberallgeier]

Hi Jens, willkommen im Forum. Danke für Deine Hinweise.

... für erste Versuch erstmal fertige Quellen ... laufschrift ... habe ... keine delay-Schleifen mehr drinn ...

Hmmmm - ich will ja kein Lauflicht machen sondern das PingPong in C möglichst genau nachbauen. Mir war im Eingangspost nicht klar, ob ich die Ansteuerung richtig verstanden hatte - weil es je nach Anzahl der leuchtenden LEDs in einer Zeile Helligkeitsunterschiede gibt. Und delays hab ich eigentlich nicht in die engere Wahl gezogen, der Controller läuft sowieso müde 8 MHz.

Im gegenwärtigen Stand - Rackets bewegen - läuft die chose gut - siehe oberes Posting; demnächst kommt der Ball ins Spiel.

[funk3r]

Hier gibt es eine Version in C
http://blogs.zobniow.net/micro/2010/...onradde-board/

@Laufschrift:
Wie erweitert man das auf mehrere Module?
Gibt es dazu fertigen Code?

[oberallgeier]

Hier gibt es eine Version in C ...

Diese Version von Piotr Platek hatte ich Anfang des Jahres getestet. Seltsamerweise lief ein eigenes Kompilat nicht sehr stabil und eine geringfügig veränderte Quelle (Starttext) lief mit wirren Zeichen und nicht reproduzierbar (irgendein Variablenüberlauf?). Die Kommentare fand ich auch etwas spärlich, jedenfalls kann ich mit meinen bescheidenen C-Kenntnissen den Ablauf nicht nachvollziehen.

Es ist wie so oft: selbst geschrieben ist der Code meist verständlicher als abgekupfert (Ausnahmen von guten Codern gibts aber!). Daher auch meine eigenen Bemühungen - mit etwas mehr Kommentar und weniger Spaghetti.

[funk3r]

Da ist natürlich was dran.
Beim selber programmieren weiß man wenigstens was man hat  

[oberallgeier]

Das PingPong ist ja etwas aus den Schlagzeilen. Aber ich bin mittlerweile weiter gekommen.

Startsequenz und Racketsteuerung über Potentiometer läuft. Der Tongenerator im Test wird durch die Potentiometer gesteuert, die Racketstellung liefert in dieser Testversion die Information für die aktuelle Generatoreinstellung. Die Grundfrequenz ist 2 kHz => in der 4kHz-ISR für den LED-Refresh wird der Soundausgang getoggelt. Dazu die Teiler 1, 2, 3, 4, 5, 6, 7, 8 und 9 für div. Töne. Der 1-kHz-Ton hat bei meinem Beeper die größte Lautstärke. Ein 4,7 µF Elko macht den Ton des magnetischen Beepers etwas weicher.

Eine höhere Tonfrequenz ist aktuell nicht ratsam/möglich, da der Beeperanschluss wegen der Kompatibilität mit dem Originalprogramm auf PD1 bleiben muss und die üblichen timersteuerbaren Ausgänge durch andere Belegungen nicht nutzbar sind.



Wenn es RICHTIG weitergegangen ist und die ersten Spielversuche laufen, gibts auf Wunsch auch Code.

[oberallgeier]

Die gute PingPong-Platine dient mir als schickes LED-Display. Numerische Anzeige, auch ein paar Buchstaben und Sonderzeichen, mit mega168 oder größer (ich arbeite daran) ginge auch das komplette Alphabet.

[Crazy Harry]

Bei dem Teil (hab auch noch so eine Platine rumliegen) fällt mir was anderes ein, das ich mal mit einer Propellerclock gemacht hab: ich habe ein grafisches LCD definiert und die Hardware-Ausgabe selber programmiert (das geht mit meinem Compiler). Der im RAM des Controllers liegende Videospeicher wurde aber über die Schieberegister der PC ausgegeben. Funktioniert hervorragend. Sinn und Zweck dieser Aktion: die PC verhält sich wie ein GLCD und ich kann alle Grafikfunktionen des Compilers nutzen.
Auch bei der PingPong-Platine könnte man ein GLCD mit 16x16 (muß ein Vielfaches von 8 sein) Pixel definieren, HW-Ausgabe Proggen und auch dann die Grafikbefehle des Compilers nutzen.

[oberallgeier]

... mit einer Propellerclock ... Der im RAM des Controllers liegende Videospeicher ...

Der mega8 hat sowieso zu wenig RAM - da ist daran wohl kaum zu denken - aber, gute Idee, danke.

Zum Titel:
Der weiter oben beschriebene Umbau läuft - zwei kalte Lötstellen und eine durchtrennte Leitung (wieso das? - aber egal) wurden gelötet - und nun läufts.
Der Aufbau - komplett als Displayduo vorn und hinten beim Archie: zwei gleiche Platinen - aber einmal mega8 und einmal ein (alter) mega168 - laufen parallel an EINER UART-Leitung vom Master, 56kBd sichert trotzdem eine ausreichend, nein eine wirklich gute, praktisch fehlerfreie Funktion: beide Displays zeigen die gleichen Signale. Es sind meist drei Ziffern, aber auch ein paar Symbole wie "Pfeil-auf", "Pfeil-ab", "0/1" etc.

RAM war das Thema beim Mega8 - daher war der Umbau auf den (schon viele Monate rumliegenden) mega168. Ich hätte vorher das Datenblatt lesen sollen: der hat auch nicht mehr RAM als der mega8. Also nen 328p besorgt. Auf einer heilen originalen Platine mit nem mega8 den Controller mit hauchdünnem Alu abdecken, Fenster in Controllergröße, Heißluft dran und Controller abheben. FAST problemlos! Der neue 328p war schnell draufgelötet und lief auf Anhieb. Aber er funktionierte nicht im oben genannten Verbund. Also doch ´n Fehler. Lupe. Löten. Testen. Mist. Lupe, löten, testen - Mist. Mehrmal. Dann mal einen Aufbau mit der umgebauten PingPong mit dem 328p alleine. Und es läuft sowas von gut. Stromaufnahme wie beim 8er - bei 5,01V rund 15-17 mA -- und das mit 120 LEDs !! Alle Befehle sind möglich, aber sie kommen eben vom Terminal über den Pro gra mmer. Platine wieder in den erwähnten Verbund eingebaut - und sie spinnt wie davor, zeigt ohne Aufforderung wilde Daten, selten etwas Sinnvolles, viele einzelne LEDs, das Programm macht nicht mal annähernd das was ich möchte. Bei all dem Chaos läuft die zweite Platine, egal ob m8 oder m168, problemlos.

Frage1: Wieso läuft das mit mega8+mega8, auch mit mega8+mega168, aber eben nicht mit mega8(oder 168er)+mega328 ? ?

Frage2: Was kann ich tun, damit das Signal so getrennt wird, dass die beiden Controller sich nicht mehr gegenseitig stören?

Danke für die Hilfe.

[Sternthaler]

Hossa oberallgeier,

ich weiss, du wirst es geprüft haben.
Aber wäre es möglich, dass der neue 328 mit der Verbindung über den Pro gra mmer eventuell mit einer anderen Baud-Rate betrieben wurde?
Die Idee zur Frage ist, ob du evl. die Konfigurations-Bits vom neuen 328 nicht richtig gesetzt hast.
Als da wären: Quarzbetrieb/Interner Takt und/oder dieses Clock/8-Konfig-Bit

Ansonsten bin ich auch erst einmal überrascht wie du.

cu Sternthaler

[Besserwessi]

Die Widerstände sind so, das eigentlich immer nur eine LED pro Zeile gleichzeitig Leuchten sollte. Das passt auch zum langsamen Schieden des Schieberegisters. Der Bildaufbau erfolgt also Spalte für Spalte. Wegen der relativ schwachen Treiber der 4094 (wohl 74HC4094) wird es aber mit mehr als 1 LED Gleichzeitig schon schwer.

Besser wäre es aber gewesen die Widerständen an die 4094 zu machen (halt 2 mehr) und dann Zeilenweise das Bild aufzubauen - die Treiber des AVRs sind meist etwas kräftiger als beim 4094. Dann wäre auch eine Ansteuerung per SPI Hardware besser.

Der C Code wird ggf. noch etwas schneller wenn man wenn möglich lokale Variablen in der ISR nutzt.
Es sollten auch etwa 120 Hz Widerhohlfrequenz ausreichen - die nötige Rechenzeit für die Darstellung reduziert sich damit auf etwa 1/3.