Hi, wie neulich schon angekündigt habe ich mich ma an Conway's Game of Life mit einem ATMega8 gesetzt! Die Anzeige ist ein 10x10 LED "Display" (matrix). Die Software ist in C geschrieben (.hex und .c auf anfrage) und funktioniert bis auf wenige makel problemlos. Zum Quarz auf der Schaltung: ich hatte zuerst ein 4mhz quarz drauf, damit flackert es aber doch sehr, minimal sollte ein 8MhZ oder noch besser ein 12 MhZ Quarz verwendet werden! Man kanns ja auf IC sockel setzten, dann kann mans austauschen. Zur Software: Initialisieren des Feldes durch zufallsgeneratoren Wenn sich nichtsmehr regt wird das feld neu initialisiert. Und nun habe ich noch eingebaut, dass er erkennt wenn er in einer schleife steckt (also sich etwas recht oft wiederholt). Das funktioniert aber nur bedingt, da das gedächtniss schließlich auch begrenzt ist des ATMega's ;). und das ding hat keine "Grenzen", es springt in dem fall immer auf die gegenüberliegende seite und zieht diese bei dem algorhitmus mit ein. Videos und oder Bilder werde ich machen sobald ich mein §$%&/$" Datenkabel vom Handy wiederfinde (sorry, hab keine Digicam!). Wers nachbauen will bitte, aber hier die "Lizenz": - Bauts nach, verändert es aber hinterlasst mir bitte ein Copyright ;). - Veröffentlicht die originalarbeit nirgends anders, außer mit meiner zustimmung - Verdient kein Geld damit (ist damit wohl denk ich eh nicht möglich) - Macht mich nicht für schäden verantwortlich ;) Schaltpläne sind im Anhang, die habe ich allerdings vorhin zusammengebastelt, ich garantiere keine fehlerfreiheit. Dazu muss man sagen: Ich habe die npn-Transitoren (sind btw BC 337er, hab ich nicht in den plan geschrieben, sorry) auf ne separate platine gemacht in den plänen, schien mir übersichtlicher. Ich selber beim bau habe das Procboard und das Transboard auf einer Platine und über gewinkelte steckverbinder hab ich das LED board separat gemacht. Wie ihrs macht müsst ihr selber wissen ;). Viel Spaß. MfG P.P.S: Das ist mein erstes komplett selbst erstelltes projekt, also bitte nicht an den pranger stellen für fehler oder unswissenheit oder sonstwas ;)
:
Verschoben durch Admin
Markus Foitschik schrieb: > wie neulich schon angekündigt habe ich mich ma an Conway's Game of Life > mit einem ATMega8 gesetzt! > > Die Anzeige ist ein 10x10 LED "Display" (matrix). Mhm. entweder bin ich gerad nur blind oder ich finde nirgends den Link zur Software ;-) Im Anhang sind nur die PNGs mit den Schaltplänen. Grüße, Peter
> Die Software ist in C geschrieben (.hex und .c auf anfrage) und > funktioniert bis auf wenige makel problemlos.<< Siehe text oben ;) Das ich die nicht mit ranhab hat nen ganz einfachen hintergrund: ich habe grade keine lust windows zu booten ;). Ich entwickle das unter windows, weil gentoo linux scheins nen bug in avr-gcc hat und es die ld scripts nicht findet. Und wenn ich mit dem NTFS treiber die platte jetzt mounten würde, zerballert es mir wieder die logfile so dermaßen (wie letztes ma auch), dass checkdisk von windows wieder ewig braucht :D. Also wenn interesse besteht werd ichs morgen hochladen und den code vorher noch bissle aufhübschen (kommentare etc). MfG
Markus Foitschik schrieb: >> Die Software ist in C geschrieben (.hex und .c auf anfrage) und >> funktioniert bis auf wenige makel problemlos.<< > > Siehe text oben ;) Mhm. entschuldige mich bitte 2 Minuten, ich muss mich mal selbst larten gehen. Hab es mehrmal geschafft den Satz zu überlegen... > scripts nicht findet. Und wenn ich mit dem NTFS treiber die platte jetzt > mounten würde, zerballert es mir wieder die logfile so dermaßen (wie > letztes ma auch), dass checkdisk von windows wieder ewig braucht :D. Huh? "mount -o ro" ist dein Freund, wenn du read only mountest wird da nix angepackt und kann kaputt gehen ;-) Lad mal nen Video hoch, wenn mir das gefällt kannst mir den code mal schicken, als kleine Bastelei zwischendurch zum verschenken hätt das ganze was. ;^_^ Grüße, Peter
Markus Foitschik schrieb: > weil gentoo linux scheins nen bug in avr-gcc hat und es die ld > scripts nicht findet. Das Problem ldscripts/avr4.x not found konnte ich unter Debian mit der Zusatzoption
1 | -L/usr/lib |
beim Linker lösen; vielleicht hilft es ja auch bei Dir?
Markus Foitschik schrieb: > Und nun habe ich noch eingebaut, dass er erkennt wenn er in einer > schleife steckt (also sich etwas recht oft wiederholt). Das funktioniert > aber nur bedingt, da das gedächtniss schließlich auch begrenzt ist des > ATMega's ;). Das sollte eigentlich kein Problem sein, es reicht ja, wenn du z.B. alle 50 Frames dir den Frame merkst (nur diesen) und wenn er wieder auftaucht, bist du in einer Schleife. Damit erkennst du alle Schleifen, die maximal 50 Frames lang sind, nur halt nicht unbedingt gleich bei der ersten Wiederholung.
Sieht schon mal ganz gut aus. AAAABER - Die Kollektoren der Transistoren sind an "OUT" angeschlossen. Das gibt's nirgendwo anders, ich vermute mal, dass das "VCC" heißen sollte. - Da das Timing relativ egal ist, könntest du eigentlich auch den internen RC-Oszillator verwenden, das würde ein paar Bauteile sparen. Ich bin auch kein Fan von Quarzoszillatoren (groß und teurer als ein einfacher Quarz), aber das ist Geschmackssache. - Am Resetpin fehlt ein Kreuzungspunkt :-D Ich bin grade dabei ein Layout zu machen. Mal schau'n wie kompakt ich das hinbekomme. Allerdings werde ich wahrscheinlich SMD-LEDs verwenden, ich hab keine sonderliche Lust 200 Löcher mehr zu bohren. ;-) mfg Michi
Nix für ungut, aber hier fehlt ja noch einiges: - Weder ein Hexfile (Minimum ;)) noch Quellen zum selber kompostieren, äh compilieren - Nur ein schnell dahin gemalter Schaltplan, allerdings kein Layout. Grad fürs LED Board wäre ein schickes Layout cool Wie warm wird den der 7805er? Die 100R Vorwiderstand bei 5V scheinen mir auch etwas niedrig gewählt. So Pi mal Daumen komm ich da auf knapp 35mA pro LED, macht in Summe 3.5A wenn alles an ist ;) Wie schnell wird den gemultiplext? So,genug gemosert ;) Bin wirklich auf das Video gespannt, könnte ein cooles Nachbauprojekt für die Weihnachtsfeiertage werden :)
Ulf Rolf schrieb: > Markus Foitschik schrieb: >> weil gentoo linux scheins nen bug in avr-gcc hat und es die ld >> scripts nicht findet. > > Das Problem ldscripts/avr4.x not found konnte ich unter Debian mit der > Zusatzoption >
1 | > -L/usr/lib |
2 | > |
> beim Linker lösen; vielleicht hilft es ja auch bei Dir?
Kannst du mir vielleicht genau sagen wo? in der makefile? Das problem
wird in zahlreichen bugreports gemeldet aber niemand scheint eine
passende lösung zu finden, ich würde das dann posten wenn du mir genau
sagst wo du das gemacht hast, würde vielen sicherlich helfen ;)
Ich versuche grade zwecks video den v4l webcam driver in meinen kernel
einzubauen (compiled grade ^^), also werd ich denk ich demnächt ein
video reinstellen. Code mach ich grade sauber und setz kommentare, dann
stell ich ihn auch rein
Also erstmal zum gemotze: Ich mache kein Layout WEEEIIILLLLL ich kein ätzgerät habe, nicht weiß wie ein gutes layout aussieht und ich es selbst eh noch nicht herstellen kann ;) Das mit dem kreuzungspunkt tut mir leid, mir sind noch mehr fehler aufgefallen auf dem LED-Board (beschriftungen ;)). Die quelle kommt jetzt, ich hab nun den code für normalsterbliche nicht-spaghetticode-leser frisch formattiert und noch ein paar fehler gekürtzt. Ich bin auch kein fan von Quarzoszis, hatte aber grade einen 4MhZ rumliegen, momentan betreibe ich es mit dem 8MhZ intern (funktioniert relativ gut) und morgen werd ich wohl einen externen 12mhz auflöten. Eventuell überlegung ist auchnoch, das mit einem ATMega16 zu bauen und ein kleines gimmick rein: Das Game soll angehalten werden, dann baut man sich ein steuerpult, mit dem man die LEDs ein und ausschalten kann (steuerkreuz, an aus taster). Aber erstmal mit dem Mega8 zu rande kommen. Hier nun Hexfile und source zum selber "kompostieren" ;) Korrigierte baupläne und Makefile das ich verwendet habe lege ich auch mal bei Der 7805 wird nicht sonderlich warm. Musst überlegen das die LEDs ja nicht im dauerbetrieb laufen, sondern per multiplexing ;) Würde ich die widerstände erhöhen, würden die LEDs zu dunkel werden. Also kalt bleibt der 7805 nicht, es läuft hier nun 2 stunden vor sich hin und es ist handwarm. also nicht heiß nicht kalt. Zur frage wie schnell gemultiplext wird: Keine ahnung, habe da noch nicht so die erfahrung, aber die LEDs laufen nicht auf maximum helligkeit. Rechne es aus: es sind 2 inneinanderliegene schleifen, also 100 durchläuft, mit je mehreren if abfragen. Und nix zum algorhitmus wie ich multiplexe ;) wenn ichs anders mache bekomm ich nen schicken helligkeitsverlauf, siehe main.c P.S: Bin ich grade zu blöd oder warum wird mein dateianhang hier ignoriert? Ich kann den noch so oft auswählen, erscheinen tut er nicht o_O Kann ich irgendwie meinen erstbeitrag editieren damit ich da den neuen anhang reinmaceh?
Ich glaube, beim Editieren kann man keinen Anhang ergänzen. Ist mir auch mal aufgefallen. Entweder bin ich zu doof, oder da ist ein echter Bug. Also nochmal posten. Deine alten Beiträge kannst du nur kurz danach noch ändern.
Abdul K. schrieb: > Ich glaube, beim Editieren kann man keinen Anhang ergänzen. Ist mir auch > mal aufgefallen. Entweder bin ich zu doof, oder da ist ein echter Bug. > Also nochmal posten. > Deine alten Beiträge kannst du nur kurz danach noch ändern. jo, aber selbst an einen neuen beitrag kann ich nichts anhängen :( na wer sagsts denn ;) hier ist nu alles dabei
So, hier versprochene Videos und Bilder. Bilder im anhang. Videos auf Du-Röhre: Bei Licht: http://www.youtube.com/watch?v=NI1krs0UqT8 und im dunkeln: http://www.youtube.com/watch?v=jbbLfqX_gqg :) Und source ist weiter oben und sorry für die miese quali der bilder, weiß aiuch net was da los ist...
Nice. Jetzt noch ein Gehäuse aus kratzfestem Mineralglas und gebürstetem Edelstahl ;-)
das kann ich leider nicht gg. aber ich hatte vor es etwas kompakter zu bauen und per holzrahmen an die wand zu hängen :P aber muss erstmal schaun wie lange ne 9V Batterie da hält, momentan ist es per netzteil betrieben
Markus Foitschik schrieb: > das kann ich leider nicht gg. aber ich hatte vor es etwas kompakter zu > bauen und per holzrahmen an die wand zu hängen :P aber muss erstmal > schaun wie lange ne 9V Batterie da hält, momentan ist es per netzteil > betrieben Hübsch, für das erste Projekt, ist gekauft! Zumindest die Software, die Hardware werd ich etwas ändern. ;-) Grüße, Peter
Kannst mir ja deine änderungen mitteilen ;) hilft mir vielleciht bei eigenen ideen ;) Danke das dir die software gefällt, dachte für meinen programmierstil gibbet erstmal paar aufn deckel sfg
Markus Foitschik schrieb: > Kannst mir ja deine änderungen mitteilen ;) hilft mir vielleciht bei > eigenen ideen ;) Ich bin gerad am Board layout, wenn (falls) ichs fertig hab meld ich mich. Eigentlich hab ich dazu gerad keine Zeit aber ich will schon seit jahren mal sowas basteln, mein erster Versuch einer Blinkenmatrix is in den Weiten der Gerümpelkiste untergegangen ;^^ > Danke das dir die software gefällt, dachte für meinen programmierstil > gibbet erstmal paar aufn deckel *sfg* Ach, meiner is mindestens genauso schlecht ;-) Ich schreib Wahnsinnig viele Kommentare und verpack alles in zuviele Funktionen... Grüße, Peter
für nen anfänger ist der Programmierstil doch nicht soo schlecht. ich würd 2 sachen ändern: 1. die klammern beim else beide vor und hinter das else setzen (eventuell generell bei kurzen if-blöcken die Klammern auf die selbe Zeile wie das if) Das macht den Code überschaubarer und man vermeidet ein haufen Quasi-leerzeilen. was es wiederum erleichtert den Code durch echte Leerzeilen richtig zu gruppieren, da diese nicht unter den ganzen Klammerzeilen untergehen. 2. die Kommentare zu Variablen immer direkt über die variable, dies gbetrifft und nicht über die erste Variable alle Kommentare. Die meisten IDEs zeigen nämlich bei der codevervollständigung die Kommentare mit an. Wenn man da grad dabei ist kann man solche Variablen und Funktionsdokumentationen auch mit /** beginnen. Das ist nicht viel Arbeit, aber man kann hinterher mit doxygen relativ einfach eine HTML-dokumentation erstellen. Das ist aber in erster linie natürlich für Bibliotheken sinnvoll. Edit: was ich sehr gut finde, ist, dass konsequent die Klammern beim if benutzt werden. Das schaltet die Fehlerquelle aus, dass man durch falsche formatierung glaubt, etwas gehört in die schleife, was aber gar nicht drin ist, weil man die Klammern vergessen hat.
zu deinem 1: das war mal so. Nur durch viel verschieben von codeteilen durch copy und paste war die formattierung am arsch (normal benutzt ich auch nur 2 einrückungen statt 4, find ich schöner) und ich wollt euch nicht zumuten das lesen zu müssen. Faul wie ich bin hab ich code::blocks (unterstützt sehr gut avr!) die C-Konforme Autoformattierung gemacht, das was du siehst kam dabei raus, ich halte es auch für zeilenverschwendung. dein 2. werd ich mir zu herzen nehmen ;). Und das man klammern beim if weglassen kann ist mir neu o_O, da meckert C bei mir immer, war nämlich anfangs eine scheiss umgewöhnung, da ich eigentlich Delphi gewohnt bin gg.
Markus Foitschik schrieb: > [...] > dein 2. werd ich mir zu herzen nehmen ;). Und das man klammern beim if > weglassen kann ist mir neu o_O, da meckert C bei mir immer, war nämlich > anfangs eine scheiss umgewöhnung, da ich eigentlich Delphi gewohnt bin > gg. Nur damit du das nicht falsch verstehst: Das betrifft die geschweiften Klammern, nicht die runden. Also
1 | if (x) { |
2 | PORTA = 0; |
3 | }
|
und
1 | if (x) |
2 | PORTA = 0; |
und
1 | if (x) PORTA = 0; |
sind gleichwertig. Ohne die Klammer wird aber nur genau die nächste Anweisung bedingt ausgeführt. Daher führt sowas häufig zu Fehlern:
1 | if (x) |
2 | PORTA = 0; |
3 | PORTB = 0; |
Die Einrückung suggeriert hier, dass PORTB nur auf Null gesetzt wird, wenn x ungleich Null ist. In Wahrheit wird die Anweisung aber immer ausgeführt, da sie nicht mehr zur if-Anweisung gehört. Daher bevorzuge auch ich die Variante mit den geklammerten Blöcken, ausser es passt alles in eine Zeile. Das nur so am Rande. Ist ein nettes Projekt und für den Anfang ganz ordentlich ausgeführt! Daumen hoch :)
ach so meinst du das. naja ich bin das eh von MSL (mIRC Scripting Language) gewohnt, da kann man die nicht weglassen, ist mir auch neu das man das bei C kann ^^ wieder was gelernt (auch wenn ichs sicherlich nie anwenden werd). Danke für das lob!
Markus Foitschik schrieb: > Kannst du mir vielleicht genau sagen wo? in der makefile? Das problem > wird in zahlreichen bugreports gemeldet aber niemand scheint eine > passende lösung zu finden, ich würde das dann posten wenn du mir genau > sagst wo du das gemacht hast, würde vielen sicherlich helfen ;) An irgendeiner Stelle ruft jedes Makefile avr-ld auf, und dort habe ich bei meinem einfach das Argument -L/usr/lib hinzugefügt.
ich habs schon hinbekommen, man muss die makefile nicht ändern, es ist ein fehlender symlink. habe ihn erstellt und alles funktioniert jetzt ;) Trotzdem danke!
Markus Foitschik schrieb: > ich habs schon hinbekommen, man muss die makefile nicht ändern, es ist > ein fehlender symlink. habe ihn erstellt und alles funktioniert jetzt ;) > Trotzdem danke! Für spätere Generationen, die über die Suchfunktion hierher kommen, wäre natürlich hilfreich, wenn Du kurz beschreiben würdest, welcher Symlink gefehlt hat.
Ich habe mich jetzt mal an einem möglichst kompakten Layout versucht (png/sch/brd im Anhang) und bin auf eine Platine von ca 79x62mm gekommen. Allerding habe ich die Widerstände für die LEDs als Widerstandnetzwerk eingebaut. Bei Bedarf kann man die natürlich noch durch normale Einzelwiderstände ersetzen. Was haltet ihr davon?
wie hast du denn das mit dem Zufall gemacht ? Ich mach den spaß gerade auf PIC aber hab das Problem, dass ich immer nach einem neuen PowerUp genau die gleichen Sequenzen bekomme...
Hallo, ich habe eine Frage zum GoL und wollte nicht extra einen Thread eröffnen, daher schreibe ich in diesen alten. Ich habe ein GoL in einem Atmega 1281 implementiert und verwende zur Anzeige ein 240 x 128 messendes s/w LCD. Per Zufall (Rauschgenerator am ADC) wird das Feld mit lebenden Zellen gefüllt. Wenn eine Population statisch wird, oder noch oszillierende Zellhaufen enthält, soll das Spiel abbrechen und eine neue Population geladen werden. Habt Ihr eine Idee wie ich diesen Zustand erkennen kann? Das einfachste ist mitzuzählen, wie viele Zellen in einer Generation sterben und wie viele zum Leben erweckt werden. Sind die Werte gleich ist die Population "fest". Das funktioniert aber leider nicht immer. Ich würde mich über eure Anregungen sehr freuen. Viele Grüße Paul
puh das ist gar nicht so einfach. Es gib in GOL ja einige Oszillatoren mit unterschiedlicher Periode, die sind ja auch mehr oder weniger "statisch". Die zu erkennen ist nicht so einfach aber die häufigsten davon haben nur eine Periode von 2, so dass man Versuchen könnte, den Zustand der Felder von dieser Generation und der vorletzten zu vergleichen, dass setzt allerdings vorraus, dass man dafür genügend RAM zu verfügung hat. Ist eine Glider-Gun die in den leeren Raum schießt für dich auch statisch?
Hallo, ich hatte nicht damit gerechnet so schnell Antwort zu bekommen. Vielen Dank. Das Problem ist leider wirklich nicht ganz einfach. Zellansammlungen die eine nicht zu große Periode haben, kann man mit der Zählmethode erkennen. Man muss allerdings eine paar dieser Perioden durchlaufen lassen um halbwegs sicher zu sein. Beliebig lange Perioden sind aber aus meiner Sicht nicht erkennbar. Das Spiel würde dann vorzeitig terminieren. Ich habe mir die Anzahl der sterbenden und wiederbelebten Zellen mal anzeigen lassen und die gewünschte Abbruchbedingung tritt auch im "normalen" Spielverlauf hin und wieder auf. RAM habe ich natürlich nicht genug. Das Spielfeld benötigt 3840 Byte + 720 Byte Puffer zum "entpacken" + 30 Byte Puffer für die erste Zeile wegen des Torus. Ich habe nur noch 3,2k übrig. Mein GoL soll ein Steampunk Dekoobjekt mit Batteriebetrieb und Münzeinwurf werden. Daher soll das Spiel nicht ewig laufen. Das Display hat für heutige Verhältnisse nämlich einen geradezu abartigen Stromverbrauch (CCFL Backlight). Über solche Objekte wie Glider Guns hab ich mir auch schon Gedanken gemacht. Das Programm müsste so intelligent sein, dass es bei solchen Konstellationen nach einer Weile terminiert, weil es ja nichts Neues gibt. Da müsste ich aber etliche Generationen speichern... Man könnte vielleicht die oben beschriebenen Zählvariablen in einem Array speichern und miteinander falten. Die Arraygröße richtet man nach der Spielfeldgröße aus. Da das Spielfeld sich wie ein Torus verhält kann es auch passieren, dass sich die Kanone selbst beschießt. Frei nach dem Motto: "Die Erde ist eine Kugel, wir greifen von hinten an" Ich habe Kanonen noch nicht getestet, aber Glider fliegen immer im Kreis. Ich werdes wohl zunächst mal ohne Auto-Terminierung machen müssen, da das Teil am 24.12. fertig sein muss. Viele Grüße Paul
Paul P. schrieb: > Mein GoL soll ein Steampunk Dekoobjekt mit Batteriebetrieb und > Münzeinwurf werden. Daher soll das Spiel nicht ewig laufen. Dann terminiere das Spiel nach einer festen Zeitspanne.
bilde eine oder mehrere Checksummen (CRC32, Anzahl lebender Zellen, Fluktuation), über das Feld und speichere die über mehrere Frames.
CRC32 kam mir auch schon in den Sinn, aber das ist bestimmt rechen- und zeitaufwändig. Momentan braucht der Controller bei 16MHz ca. 100ms für die Berechnung einer Generation. Und so "schnell" sollte das Spiel schon laufen können. (Die Periodendauer für eine Generation ist einstellbar) Das Spielfeld hat 2^30720 Möglichkeiten. Besteht da nicht auch die Gefahr, dass zwei aufeinanderfolgende Generationen die selbe Checksumme ergeben?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.