Hallo,
Also der Tim und Ich wir haben ein Problem, und zwar haben wir ein
Technisches Projekt in der Schule, wir müssen Vier gewinnt auf einem
Atmel At89S8252 programmieren, ganz ohne KI, an dem Controller sind 4
Ports. 3 ports werden zum anschluss der mehrfarbien 6x8 Led matrix
verwendet und 1 port für taster, jetz soll man auf diesem taster
abwechselnd spieler eins und spieler zwei spielen lassen, es scheint so
als wäre es nicht sehr kompliziert so ein programm zu schreiben, leider
haben wir jedoch nicht sehr viel ahnung was Assembler anbelangt. Nun
würden wir euch bitten uns wenigstens eine Starthilfe zu geben, vll ein
groben pap aus dem man weiteres schließen kann oder sonst irgendwie
einen plan wie wir das anstellen sollen. Wir können uns leider nicht
vorstellen wie das funktionieren soll
Vielen Dank im voraus,
der Tim und der Robert
Edit: C hilft uns leider nicht weiter weil wir dieses noch weniger
verstehen.
> ...ganz ohne KI...
Was verstehst du unter "ohne KI"? Der Controller IST eine KI, gefüttert
mit eurer Software, in der ja die Intelligenz steckt!
Wenn ihr das ohne KI machen müsstet... früher nannte man das
TTL-Grab...
> Nun würden wir euch bitten uns wenigstens eine Starthilfe zu geben, vll ein> groben pap aus dem man weiteres schließen kann oder sonst irgendwie> einen plan wie wir das anstellen sollen.
Den PAP könnt ihr selber machen, ist einfach:
Stellt euch einfach das reale Spiel mal auf n Tisch und dann notiert ihr
die einzelnen Schritte, die ihr macht, auf Papier. Dann münzt ihr das
auf eure Hardware um.
- Chip in den Slot = Taste des entsprechenden Slots wird gedrückt
- Chip fällt nach unten = die unterste, ausgeschaltete LED wird
aktiviert
- Prüfen, ob vier gleichfarbige Chips horizontal, vertikal oder diagonal
in einer Reihe liegen
Damit habt ihr die Grundlage. Und das wird Schritt für Schritt
ausgebaut.
Ralf
PS: Und wenn ihr einen brauchbaren PAP habt, könnt ihr ans Coden
gehen, egal ob ASM oder C.
Vorher wischi-waschi nebenher zu coden, wird euch nicht helfen.
Ralf
R. W. schrieb:> einen plan wie wir das anstellen sollen. Wir können uns leider nicht> vorstellen wie das funktionieren soll
Denk als allererstes nicht
"Huch, ich soll 4 gewinnt programmieren, wie mach ich das nur"
Zerlege das Projekt in Einzelteile, die bearbeitet werden müssen. Fang
mit den Basisdingen an. Basisdinge sind oft die einfachen Sachen aber
noch viel öfter sind das: sich eine optische Ausgabemöglichkeitschaffen
(bei euch die Matrix). Die ist insbesondere deswegen hilfreich, weil sie
es euch ermöglicht, dass sich das Programm bemerkbar machen kann. zb in
dem es eine LED links/oben im Eck einschaltet und ihr dann wisst "Aha,
das Programm hat einen Tastendruck erkannt". Die LED daneben mag während
der Entwicklung bedeuten: "Noch keine 4 nebeneinander liegenden Steine
gefunden" oder "4 Steine gleicher Farbe übereinander" oder was ihr dann
auch immer für Informationen benötigt.
Da sind zunächst
* wie wird die Matrix angesteuert?
wie kannst du eine einzelne LED in der Matrix gezielt ein/aus schalten
* wie werden Taster angefragt?
wenn ihr die beiden Einzelkonzepte habt:
Die beiden Konzepte zunächst ganz einfach miteinander kombinieren.
Bei einem Tastendruck soll eine ganz bestimmte LED aufleuchten. Nicht
mehr.
Wenn ihr das Gefühl habt, das ihr diese Teile im Griff habt, dann könnt
ihr schön langsam in Richtung Spiel gehen.
Jetzt soll nicht mehr eine beliebige Led aufleuchten, sondern ihr wollt
mit 2 Tastern eine leuchtende LED in der obersten LED-Reihe von links
nach rechts bewegen und wieder zurück. Bei jedem Tastendruck wechselt
die leuchtende LED 1 Spalte nach links bzw. bei der anderen Taste nach
rechts.
Rate mal was das wird:
Genau. Irgendwie muss der Spieler ja auswählen, in welche Spalte er eine
Spielmarke einwerfen will. Dieses links/rechts Tasten Auswerten ist die
Vorstufe dazu.
Wenn das klappt, kann man eine 3te Taste dazu nehmen.
Mit den links / rechts Tasten wählt man die Spalte aus, mit der 3.ten
Taste soll die 'Spielmarke' dann 'nach unten fallen'. Einfach nur nach
unten fallen.
Ist man soweit, dann wird es Zeit darüber nachzudenken, wie man die
fallende Spielmarke liegen lassen kann, bzw. die nächste Marke sich dann
darauf stapelt.
Dazu wird man sich den Zustand des Spielfelds in irgendeiner Form im
Speicher halten müssen.
Hat man sich dann für eine Form entschieden, baut man das bisherige so
um, dass es auf diese Speicherform aufsetzt. Die Anzeigeroutinen holen
sich den Leuchtstatus aus diesem Speicher. Eine Led wird dann
eingeschaltet in dem man nicht mehr direkt die Matrix ansteuert, sondern
in dem man in diesem Speicher die entsprechenden Einträge macht. Die
Tastenbehandlungen manipulieren diesen Speicher etc.
etc.
Man kann aber auch alles über den Haufen werfen und festlegen, dass es
für jede Spalte eine eigene Taste gibt. Der Möglichkeiten sind da Tür
und Tor geöffnet und es gibt viele davon. Wenn ihr soweit seid, die
Matrix anzusteuern und die Tasten auszuwerten, werdet ihr euch für eine
Möglichkeit entscheiden. (Hinweis: Für jede Spalte eine eigene Taste ist
einfacher, da dann das ganze links/rechts wegfällt, auch wenn es als
Übung nichts schadet, das hinzukriegen)
Der Trick liegt nicht darin, bei der Vorstellung des kompletten Spiels
in Panik zu verfallen, sondern sich selbst Zwischenziele zu setzen, die
einen in die richtige Richtung bringen. Das kann auch sein, dass man
eines dieser Zwischenziele später auch wieder aufgibt und es im fertigen
Spiel nicht mehr auftaucht. Trotzdem ist dieses Zwischenziel hilfreich,
weil es einen Anlaufpunkt bietet auf den man einfach hinarbeiten kann
und der einem Wissen und Verständnis für spätere Projektstadien gibt.
Wenn ihr das Gefühl habt, die niedrigen Hardwareebenen soweit im Griff
zu haben, wie man also mit den Tasten umgeht, wie man die Matrix
ansteuert, wie das Zusammenspiel von Tasten und Matrix gestaltet werden
kann, dann
setzt man sich hin und spielt erst mal ein paar Runden mit dem realen
Spiel. Das Augenmerk liegt dabei nicht darauf zu gewinnen, sondern auf:
was habe ich (bzw. mein Gegner) eigentlich gemacht. Welche
Handlungsabläufe liegen da zu Grunde? Wie verhalten sich die Spielmarken
in der Realität? Wie kann ich das mit Variablen und Schleifen und was
weiß ich noch was abbilden?
Versucht doch erstmal das Display anzusteuern, also eine funktion zu
schreiben, die ein 6*8 int-array nimmt und die bildpunkte in den
Passenden Farben setzt.
Dann braucht ihr einen Zustandsautomaten (siehe Wikipedia), Zustände
wären z.B. spieler 1 ist dran, spieler 2 ist dran, spieler 1 hat
gewonnen, Spieler 2 hat gewonnen.
Und falls ihr es noch nicht kennt, dann lest euch hier mal ein:
http://www.mikrocontroller.net/articles/AVR-Tutorial
Dannach solltet ihr zumindest wissen, wie man in Assembler die Ports
ansteuert und abfragt. Vielleicht hilft das ja die Ratlosigkeit zu
beseitigen :)
R. W. schrieb:> Nun> würden wir euch bitten uns wenigstens eine Starthilfe zu geben,
Wie geht man an so etwas ran? Mit Überlegung.
Welche Problemstellungen sollt ihr lösen?
Ihr braucht ein Programm, das vier gewinnt spielen kann. Da hilft Tante
google weiter, Lösungsstrategien und Programme mit Sourcecode gibt es
dafür garantiert im Netz.
Dann müsst ihr eine grafische Darstellung auf den LED's programmieren.
Dabei hilft das AVR-Tutorial hier aus dem Forum.
Und schliesslich noch eine Bedienung über Tasten. Auch da hilft das
Tutorial.
Das war es auch schon.
Oliver
Oliver schrieb:> Ihr braucht ein Programm, das vier gewinnt spielen kann. Da hilft Tante> google weiter, Lösungsstrategien und Programme mit Sourcecode gibt es> dafür garantiert im Netz.
Na klar, heutzutage braucht sich ja kein Schüler mehr Gedanken machen,
lieber nach fertigem Code suchen...
mit ohne KI meinen wir das man ja nur 2 Menschliche spieler hat und kein
Computergegner,
Ja aber wo speichern wir das ganze?
sollen wir die Leds mit x und y machen also z.b. x1 bit p1.0
y1 bit p2.0
und vor allem wie genau soll die gewinnabfrage ablaufen ?
wir verstehen einfach gar nichts
wir bekommen grad noch ne zeitschleife und villeicht die led matrix zu
leuchen mehr können wir leider nicht.
R. W. schrieb:> Ja aber wo speichern wir das ganze?
Denk dir was aus.
Dein µC hat ja Speicher mit.
> sollen wir die Leds mit x und y machen also z.b. x1 bit p1.0> y1 bit p2.0> und vor allem wie genau soll die gewinnabfrage ablaufen ?
Du denkst jetzt schon viel zu kompliziert und vor allen Dingen über
Dinge nach, die jetzt noch völlig irrelevant sind.
> wir bekommen grad noch ne zeitschleife und villeicht die led matrix zu> leuchen mehr können wir leider nicht.
Dann habt ihr
a) schlechte Karten
b) noch einen weiten Weg vor euch.
Aber jeder Schritt bringt euch dem Ziel näher
Beitrag "Re: Vier Gewinnt auf Mikrocontroller ohne KI?"
R. W. schrieb:> wir haben shcon das ganze internet durchstöbert und kein code oder> ähnliches gefunden leider
Den wirst du auch nicht finden.
Wenn ihr bei so einer Aufgabe, die noch dazu eng an die Hardware
gekoppelt ist, damit anfängt Stunden nach einer fertigen Lösung im
Internet zu suchen, so habt ihr eure Zeit verplempert.
Oliver schrieb:> Ihr braucht ein Programm, das vier gewinnt spielen kann.
Falsch. Aufgabe richtig lesen:
>>> jetz soll man auf diesem taster>>> abwechselnd spieler eins und spieler zwei spielen lassen,
Das stimmt also gar nicht:
>>> wir müssen Vier gewinnt auf einem Atmel At89S8252 programmieren
Es muß "nur" die Vier-Gewinnt-Mechanik nachgebaut werden.
R. W. schrieb:> und vor allem wie genau soll die gewinnabfrage ablaufen ?
Ich stell mir das Ganze als Array vor.
etwa so :
roter chip eingeworfen
ist ein roter chip daneben ? alle richtungen ausser oben durchgehen.
nachbar gefunden ? suche in gleicher richtung weiter
3 nachbarn in selber richtung gefunden ? roter spieler gewinnt
Mit geschickt geschachtelten schleifen sollte das machbar sein.
R. W. schrieb:> sicher mit schleifen, aber wir programieren doch hier in assembler
Auch in Assembler gibt es Schleifen. Oder was glaubst du wie ein
Compiler eine Schleife realisiert.
In Assembler ist es dann eben ein Jump oder ein Branch, der den
Programmfluss in eine Schleife (also eine Wiederholung) zwingt.
Aber nochmal: Die Abfrage ob, und welcher Spieler gewonnen hat, ist in
eurer jetzigen Situation und in eurem jetzigen Stadium so wichtig, wie
die exakte rosa Farbenuance des Kloteppichs bei Beginn eines Hausbaus.
Jetzt ist wichtig, dass ihr euren 'Keller' grabt und nicht ob das Rosa
zur Farbe der Fliesenfugen passt.
Ihr solltet erst einmal die Bereiche Hardwareansteuerung und
Spielstrategie trennen.
Was meint ihr mit "KI"? Mein Ansatz wäre eine rekursive Programmierung
(In C leichter zu programmieren als in ASM). Eine Funktion liefert einen
positiven Wert zurück, wenn man gewonnen hat, negativ, wenn man verloren
hat, 0, wenn (das Feld voll ist und) keiner gewonnen hat oder den
Mittelwert aller Funktionsaufrufe für die weiteren Züge. Die Rechentiefe
könnte man zusätzlich begrenzen.
Der beste Zug ist derjenige mit der höchsten Bewertung.
Klar, was ich meine?
Detlev T. schrieb:> Ihr solltet erst einmal die Bereiche Hardwareansteuerung und> Spielstrategie trennen.
Ganz genau
> Was meint ihr mit "KI"?
Das das Programm nur die reine '4-Gewinnt Hardware' simuliert.
Gestell in das 2 Spieler abwechselnd Spielmarken einwerfen.
Nicht mehr.
Es geht nicht darum, dass das Programm selber spielt.
(Und wahrscheinlich wissen die beiden gar nicht, was 'KI' bedeutet
sondern kennen das nur als Buzzword von den Spielkonsolen-Testberichten)
> Klar, was ich meine?
Schon klar.
Aber bitte, bitte ... drängt die beiden nicht in die falsche Richtung
oder in Details die erst in 5 Wochen relevant werden.
Die haben schon genug damit zu tun, bis Frühjahr 2011 die LED-Matrix
samt Tasten anzusteuern und mit 4 Tasten einen Leuchtpunkt durch die
Matrix zu navigieren.
Im Moment stehen die beiden da wie das Kaninchen vor der Schlange und
wissen nicht was sie tun sollen.
> sicher mit schleifen, aber wir programieren doch hier in assembler
siehst du da einen Widerspruch?
Zum Beispiel eine verschachtelte Schleife, welche ein Array "kreuz und
quer" durchläuft, und irgendwas macht mit dem Element am Kreuzungspunkt
(oder dessen linke oder rechte Nachbarn), ist erstmal die
"Ausgangsbasis", sprich es ist "ein Algorithmus" (eine
Vorgehensbeschreibung)
soetwas kann man in "Pseudosprache", in existierenden "Hoch" Sprachen
(Programmiersprachen), in Assembler eines bestimmten Prozessortyps, oder
sogar in klingonisch formulieren.
Der zugrunde liegende Algorithmus ist aber immer gleich. In
Pseudosprache wäre sowas z.B. eine Beschreibung dafür:
für alle Zeilen von Zeilen-Anfangswert bis Zeilen-Endwert mache
folgendes:
für alle Spalten von Spalten-Anfangswert bis Spalten-Endwert
mache folgendes:
nimm das Element an der Position "Zeilenwert, Spaltenwert"
und mach damit irgend was ganz tolles
nächste Spalte
nächste Zeile
Das "später" in Assembler zu übersetzen, nimmt dir "zur Not" ein
Compiler ab, wenn du dich in Hochsprachen besser ausdrücken kannst oder
willst
Zuerst mußt du aber drüber nachdenken, WAS da genau passiern soll. Dazu
brauchst du keinen Assembler oder irgendeine Programmiersprache.
1. Die Anregungen (speziell von Karl heinz Buchegger) sind sehr gut und
sollten von euch auch beherzigt werden.
Aber: Wollt ihr wirklich in ASM schreiben?! Das Spiel in C umzusetzen
ist um Faktor 50 einfacher als in ASM. Und wenn ihr was für die Zukunft
lernen wollt und nicht nur eure Zeit verschwenden, dann seit ihr bei C
auch besser aufgehoben.
Ich selber habe meine Diplom-Arbeit komplett in ASM entwickelt (welche
wirklich umfangreich war) würde sowas aber heute nie wieder machen.
Es ist durchaus gut ASM zu beherschen. In der Praxis wird es aber durch
Hochsprachen und leistungsfähige Hardware überflüssig.
Die Möglichkeit mit Pointern "und" Arrays in C zu arbeiten sind grade
für eure Problemlösung sehr hilfrei.
Auf dieser Seite gibt es ein sehr gutes C Einsteiger-Tutorial. D.h. ihr
bekommt aus dieser einen Seite alle Informationen die ihr für euer
Projekt braucht.
Ich schätze den Aufwand (ordentlich strukturiert mit Tastenentprellung
etc.) in C auf < 100 Zeilen.
R. W. schrieb:> leider> haben wir jedoch nicht sehr viel ahnung was Assembler anbelangt.R. W. schrieb:> C hilft uns leider nicht weiter weil wir dieses noch weniger> verstehen.
Na da habt ihr doch schonmal nen Ansatzpunkt, womit ihr beginnen könnt
(müsst!!!). Die Sprache, welche ihr verwenden wollt zu lernen.
> leider haben wir jedoch nicht sehr viel ahnung was Assembler anbelangt.> C hilft uns leider nicht weiter weil wir dieses noch weniger verstehen.
hm, um bei meinem vorgestellten verschachtelten-Schleifen-Beispiel zu
bleiben:
für mich liest sich ein in C geschriebenes Programm mit sprechenden
Variablen-Namen deutlich einfacher als ein Assembler-Programm, welches
nur mit djnz, adc und ähnlichen Befehls-Crypo-Codes formuuliert werden
kann. Das ganze Jongliere mit irgendwelchen Schleifenvariablen welche in
irgendwelcehn Registern gelagert werden, ist mit "ordentlichen"
Hochsprachen-Variablen meines erachtens auch wesentlich leichter zu
formulieren und nachzuvollziehen. Mag doch der Compiler drüber
nachdenken, ob er den Schleifenzähler in Register X, Y oder Z
reinstopft.
hey leute wir sind schon sehr viel weiter, aber jetz stellt sich nur die
frage, wie bitaddressiere ich ein register, ich mein setb r0.0 geht ja
nich
hex adresse.00 oder 01 oder so auch nicht?
Allerdings heißt es beim AT glaube ich sbi und cbi bzw sbr und cbr
jenachdem welches Register beschrieben wird. Aber dafür hat der liebe
Gott das Datenblatt erfunden!
Also jetz haben wir noch ein problem,
wir wollen jetz zwei zeilen im multiplex ausgeben, um aber wieder
rauszukommen haben wir jetz eine taster abfrage in die endlosschleife
eingebaut
ausgabe0:
mov zeilen,#0....
mov spalten,#0......
call zeit 1
mov zeilen,#0000.....
mov spalten,#000.....
call zeit 1
jb p0.0, erste
jmp ausgabe0
nun funktioniert es aber nicht
der multiplexbetrieb klappt nicht mehr, ohne das jb p0.0 klappt es aber
mit funktioniert die schleife nicht mehr
?????
Genau hier liegt eines der Probleme in den Grundlagen.
Derartige Multiplexansteuerungen macht man nicht indem man eine
Endlosschleife benutzt, sondern indem man einen Timer benutzt um mit ihm
einen regelmässigen Interrupt auszulösen. In dieser INterruptbehandlung
wird dann auf die jeweils nächste zu muliplexende Zeile
weitergeschaltet.
Die LED-Matrix wird dadurch unabhängig vom eigentlichen Programm ständig
im Hintergrund durch den Interrupt Handler angesteuert.
naja, das wird wohl nix mehr mit dem programm, wir müssen es morgen
eigentlich abgeben
jedoch sind wir nicht fertig,
kannst du das mit dem interrupt vll an einem beispiel mit quelltext
schreiben das wir das vll noch verstehn.
R. W. schrieb:> naja, das wird wohl nix mehr mit dem programm, wir müssen es morgen> eigentlich abgeben> jedoch sind wir nicht fertig,
Ähm.
Wie habt ihr euch das vorgestellt?
Gut. In C kann ich dieses Spiel auch in ein paar Stunden runtercoden.
Aber in Assembler würde ich dazu mit Sicherheit ein paar Tage benötigen.
Und ich bin Profiprogrammierer (seit 30 Jahren). Die meisten der
'üblichen Verdächtigen' in diesem Forum, die exzellent Assembler können,
würden das wahrscheinlich nicht unter 1 bis 2 Tage hinkriegen.
Ihr habt euch da masslos überschätzt, bzw. die Anforderungen an einen
Softwareentwickler masslos unterschätzt.
> kannst du das mit dem interrupt vll an einem beispiel mit quelltext> schreiben das wir das vll noch verstehn.
Ich kenn leider deinen Prozessor und damit seinen Assembler nicht. Mit
einem AVR, zb einem Mega16 wärs kein allzugroßes Problem, vorausgesetzt
ihr veröffentlicht den Schaltplan, damit man sieht was wo angeschlossen
ist.
Aber wie gesagt: Ich halt mich da sowieso raus, weil ich den Prozessor
und seine Möglichkeiten zu wenig kenne
R. W. schrieb:> naja wir können eben kein c, das is ja das problem -.-
Na ja. Ihr könnt aber auch kein Assembler, wenn ich eure Fragen da oben
ein wenig beurteilen darf.
Und wenn ich die Wahl zwischen Schnupfen und Lungenentzündung habe, dann
nehme ich Schnupfen.
villeicht dürftig, also für die die schule hat es mehr als ausgereicht
bisher, timer und interupt sind wir gerade erst am lernen das ist das
thema unserer nächsten arbeit
"wir müssen es morgen
eigentlich abgeben"
das war der punkt an dem ich vom stuhl gefallen bin
vergessat es lieber und überlegt euch eine sehr sehr SEHR gute Ausrede
in einer so geringen zeit wird selbst ein Profi Probleme bekommen einen
Prototypen zu entwickeln+löten+etc
so ein Projekt braucht einfach viel Zeit und ist nicht mal eben in 10h
durch, vorallem nicht wenn man a) keine Ahnung vom Thema bisher hat und
sich einarbeiten muss
und b) kostet Assembler meist noch mehr Zeit als C, Gründe s.o.
überlegt euch ne vernünftige Ausrede, sowas wie nen Board stecken mit
Leds+Taster und nen verkohlten Chip drauf und dann zum Lehrer "wir
wollten gestern die Final auf flashen- aber da war ein böser
Kurzschluss, reste können sie hier sehen- und wir haben nach geguckt- es
gibt enorme Lieferschwierigkeiten, der beste Rat scheint der Vorrat zu
sein"
wenn der dann nach Source fragt ist das kritisch- aber für ne Ausrede
ist noch genug Zeit ;-)- für das Projekt eig nicht
ja funktionieren tu ja alles
led leutet
led lässt sich ansteuern
taster sind ok
controller funktioniert
wir haben ja alles gegebn müssen nix selber löten
und n groben plan hatten wir eigentlich auch bis uns der multiplexfehler
unterlaufen is
R. W. schrieb:> ja funktionieren tu ja alles> led leutet> led lässt sich ansteuern> taster sind ok> controller funktioniert> wir haben ja alles gegebn müssen nix selber löten> und n groben plan hatten wir eigentlich auch bis uns der multiplexfehler> unterlaufen is
Wenn ihr Timer bisher noch nicht hattet, dann müsst ihr mit der
Endlosschleifenlösung leben.
Das wird zwar ab und an ein wenig flackern, weil die Schleife mal etwas
mehr und mal etwas weniger beschäftigt ist, aber funktionieren wird es
prinzipiell.
R. W. schrieb:> ja gut aber so funzt es ja nich, des jb stört die schleife irgendwie
Das gehört da auch nicht rein.
Am einfachsten macht ihr euch ein Unterprogramm, welches an der Matrix
nur auf die nächste Zeile weiterschaltet und die anzeigt.
Dieses Unterprogramm wird dann regelmässig an strategischen Stellen vom
Hauptprogramm aufgerufen. Beim Multiplex ist es wichtig, dass die
Routine, die das Multiplexing macht, regelmässig immer wieder aufgerufen
wird! Die Routine kümmert sich nur darum die aktive Zeile dunkel zu
schalten und die jeweils nächste Zeile nach Bedarf hell zu schalten.
Mehr nicht. Hat sie dieses umschalten erledigt, kehrt sie mit einem ret
wieder zum Aufrufer zurück. Das Multiplexing der kompletten Matrix
ergibt sich dann dadurch, dass besagte Routine wieder und immer wieder
aufgerufen wird.
R. W. schrieb:> wir brauchen ja kein über programm das man verkaufen könnte> uns würde allein vier gewinnt ohne gewinnabfrage reichen inzwischen
auch dieses Ziel ist in weiter Ferne. Macht euch nichts vor.
naja wir hören jetz auf und dokumentieren unsere versuche, machen dem
lehrer klar das das projekt viel zu schwer war, die anderen hatten
solche sachen wie ne ampel kreuzung auf ner matrix sogar ner einfarbigen
schalten oder die signale einer tastatur auslesen und auf nem grafischen
lcd display anzeigen lassen, vll kassieren wir noch ne einigermaßen gute
note
> Datum: 30.06.2010 11:57> Also der Tim und Ich wir haben ein Problem,> wir müssen Vier gewinnt auf einem Atmel At89S8252 programmieren,> Datum: 01.07.2010 20:02> mit dem programm, wir müssen es morgen eigentlich abgeben
Na, das ist doch mal ein sportliches Timing für die gegebene
Aufgabenstellung:
Am Mittwoch gegen Mittag bekommen Tim und Robert eine
Programmieraufgabe, und die sollen sie am darauf folgende Freitag morgen
eigentlich abgeben. Dazwischen ist noch der Donnerstag, wo dei beiden
vermutlich auch noch zur Schule gehen.
Respekt, so ein Zeitmanagement sieht man selten...
nö, wies soll Mittwoch ein Donnerstag sein? Das erste Posting ist von
Autor: R. W. (dertimunderrobert)
Datum: 30.06.2010 11:57
In meinem Kalender ist der 30.06.2010 der Mittwoch (vielleicht leb ich
ja in einem Zeitloch?)
R. W. schrieb:> die abgabe wurde jetz doch auf montag verschoben, glaubst ihr wir> schaffen das villeicht noch ?
Du meinst, Montag, den 2. August 201x?
Vorher jedenfalls nicht.
naja andere kurze frage,
in c:
wie gibt man ein array nehmen wir mal an mit 6 ellementen
da eine zeile der matrix 6 leds hat aus,
also ich möchte nicht jeden bit ansprechen und ausgeben
sondern das array direkt auf die zeile schicken, geht das?
binär gesehen
0 0 0 0 0 0 0 0 b
nichts [5] [4] [3] [2] [1] [0]
warscheinlich mit einer schleife in der man i für die elemente nimmt
hochzählt und ausgibt auf den einzelnen pins wie spreche ich jedoch
einen einzelnen pin an, wie man ihn abfragt weiß ich aber wie man ihn
anspricht, mit P0_i und für i dann 0 bis 5 ?
geht das ?
R. W. schrieb:> also ich möchte nicht jeden bit ansprechen und ausgeben> sondern das array direkt auf die zeile schicken, geht das?
Ja, das ist sogar noch viel einfacher als jedes Bit einzeln. Du kannst
den Port, an dem die LEDs der Zeile angeschlossen sind, einfach wie eine
Variable ansprechen. Vermutlich (die exakte Syntax hängt von eurem
Compiler und den Definitionen für euren Controller ab) sowas wie
1
// schaltet LED 0 und 2 an
2
P0=5;
> warscheinlich mit einer schleife in der man i für die> elemente nimmt hochzählt
Genau, nur gibt man die Bits nicht gleich aus, sondern baut sich erst
das Byte zusammen, was man dann mit einem Schlag auf den Port ausgibt.
Etwa so:
warum funktioniert dieses programm den nicht, wir wollten das die bits
der taster im array gespeichert werden und dann auf den 6 leds einer
zeile ausgegeben werden. warum funktioniert es nicht.
resultat dieses queltextes ist das die ganze untere zeile leuchtet und
keine reaktion auf die taster zeigt.
Du läuft Deine While-Schleife einmal von oben bin unten durch und machst
dann ein return 0 und beendest die Schleife sofort wieder. Ich weiß
nicht, was Dein Compiler daraus macht. Ich schätze, ein Endlosloop.
P0 ist, wenn keine Taste gedrückt wird, 0xFF (ich nehme es jedenfalls so
an).
"!" ist ein logisches NOT. !P0 wird immer 0x00 liefern, wenn P0 ungleich
0x00 ist. Ich weiß jetzt auch nicht, was !P0 ergibt, wenn P0 gleich 0x00
ist (ich schätze 0x01). Das willst Du sicherlich nicht.
Du meinst wohl ~P0. Das invertiert P0 bitweise. Wenn P0 = 0xff (keine
Taste) ist ~P0 = 0x00. Ist die Taste 0 (= bit 0) gedrück, ist P0 = 0xfe
und somit ~P0 = 0x01.
Abgesehen davon, solltest Du die Tasten entprellen.
Noch was:
Du prüfst nicht auf ~P0 && 0x20.
Was soll das? P3 = 0x7F.
Was soll hier jeweils das erste Semikolon?
R. W. schrieb:> resultat dieses queltextes ist das die ganze untere zeile leuchtet
Wie sind die LEDs angeschlossen? Gegen Vcc oder GND? Ich schätze
ersteres. Dann leuchten die LEDs bei einem LOW-Ausgang.
Dann leuchten alle LEDs natürlich auf, da P1 = 0.
Thread beobachten
Seitenaufteilung abschalten