Vier Gewinnt auf Mikrocontroller ohne KI?

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?

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.

wir haben shcon das ganze internet durchstöbert und kein code oder 
ähnliches gefunden leider

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.

sicher mit schleifen, aber wir programieren doch hier in assembler

R. W. schrieb:
> sicher mit schleifen, aber wir programieren doch hier in assembler

Na und ?

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.

> 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?

irgedwie gibt es den befehl nicht, gibt leider alles error

> Programmiert ihr jetzt in C oder Assembler?!?

>> setb r0.0

setb sieht mir nicht wie ein typischer C-Befehl aus ....

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

naja wir können eben kein c, das is ja das problem -.-
aber da lässt sich wohl jetz nichts mehr machen

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.

ja gut aber so funzt es ja nich, des jb stört die schleife irgendwie

wir brauchen ja kein über programm das man verkaufen könnte
uns würde allein vier gewinnt ohne gewinnabfrage reichen inzwischen

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?)

die abgabe wurde jetz doch auf montag verschoben, glaubst ihr wir 
schaffen das villeicht noch ?

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 ?

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.

1

uint8_t ;i;

2

uint8_t ;temp;

3

uint8_t ;zeile [6];

4

int main(void){

5

P1 = 0x00;

6

while(1){

7

if(!P0 && 0x01){

8

zeile[0]=1;}

9

else if(!P0 && 0x02){

10

zeile[1]=1;}

11

else if(!P0 && 0x04){

12

zeile[2]=1;}

13

else if(!P0 && 0x08){

14

zeile[3]=1;}

15

else if(!P0 && 0x10){

16

zeile[4]=1;}

17

else if(!P0 && 0x40){

18

zeile[5]=1;}

19

20

P3=0x7F;

21

22

23

temp = 0;

24

for( i=0; i<6; i++)

25

{

26

    if( zeile[i] )

27

    {

28

        temp |= (1 << i);

29

    }

30

31

}

32

P1 = temp; 

33

return 0;

34

}

35

}

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?

1

uint8_t ;i;

2

uint8_t ;temp;

3

uint8_t ;zeile [6];

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.

problem von vorher hat sich geklärt, jetz hab ich n neues^^
und zwar

P3 hat den wert 0b01111111
wie verschiebe ich jetz das bit das es 0b10111111 wird

oder besser gesagt ich würde gerne das array ausgeben
hier mein versuch

1

temp = 0;

2

    P3=0x7F;  

3

      for (j=0; j<7; j++){

4

        temp = 0;

5

        for( i=0; i<6; i++){

6

            if( zeile[i][j] ){

7

                temp |= (1 << i);

8

              }

9

        }

10

11

        P1 = temp;

12

        temp2 =(temp2 >> 1) ;

13

        P3 = temp2;

14

      }

Du willst die 0 verschieben?

0b01111111 = ~0b10000000

0b10111111 = ~0b01000000 = ~(0b1000000 >> 1)

Also:

1

temp2 = 0x80;

2

for (j...) {

3

  temp = 0;

4

  for (i...) {

5

    ...

6

  }

7

  temp2 = temp2 >> 1;

8

  P3 = ~temp2;

9

  P1 = temp;

10

}

ja ich will die 0 verschieben

also 0b01111111 =0b10111111 = 0b11011111

hald so das ich dieses 2 dimensionale array im multiplex an der matrix 
ausgebe