NES Controller (wer findet den Fehler in meinem Programm)

[e-noob (Gast)]

Hallo, ich bin hier neu und hätte eine Frage zu einem von mir 
geschriebenen Programm.

Es hadelt sich um Folgendes:
Ich wollte meinen Nintendo (NES) Gamepad als Steuerung für allerlei 
Dinge verwenden unter anderem auch für den PC. Nun habe ich mir mir 
einen Atmega8 gekauft und folgendes Programm dafür geschrieben:

;-----INCLUDE-----
.include "../inc/m8def.inc"
.include "../inc/stack.inc"
.include "../inc/delay.inc"

;-----DEF-----
.DEF btnNR = r18
.DEF outreg = r17

;-----INIT-----
  ;1 = OUT
  ;0 = IN
  ;PD0 = Serial Data = Red
  ;PD1 = Latch = Orange
   ;PD2 = Clock = Yellow
   ldi r16, 0b00000110
  out DDRD, r16
  ;PB6 = Schick los Btn
  ldi r16, 255
  ;LED-Ausgabe
  out DDRB, r16
  clr r16
  clr r20
  rjmp main

main:
  ;neuer Zyklus
  clr outreg
  ;setze Latch und Clock auf 1
  ;setze latch auf 1
  ori r20, 0b00000110
  out PORTD, r20

  ;warte 12us
  rcall delay6us
  rcall delay6us

  ;setze latch low
  ldi r20, 0b00000100
  out PORTD, r20
  
  ;ab hier vielleicht noch ein paar Takte weg
  ;8 x SerialData lesen
  ldi btnNR,8
again:
  dec btnNR
  ;warte 6us
  rcall delay6us
  
  ;setze clock und latch low
  clr r20
  out PORTD, r20

  ;warte 6us
  rcall delay6us

  ;lese port ein
  ;Schiebe Bit nach links
  lsl outreg
  in r23, PIND
  or outreg, r23
  
  ;setze clock auf 1
  ori r20, 0b00000100
  out PORTD, r20
  
  ;Wenn alle SerialData 
  ;durchgeschoben ...
  cpi btnNR, 0
  ;springe zum Output
  breq output
  rjmp again
output:
  ;Complementiert outreg
  com outreg
  out PORTB, outreg

  ;warte 17 ms
  delay 75, 1

  rjmp main

;-----PRODZEDUREN-----
delay6us:
  nop nop nop nop nop nop nop nop
  nop nop nop nop nop nop nop nop
  nop
ret

.EXIT

An PORT B hängen Dioden und sollten beim drücken der Taste aufleuchten 
(später werden die Dioden natürlich durch ein Interface zum PC 
getauscht).
Das Programm an sich funktioniert es gibt nur einen Bug den ich einfach 
nicht entfernen kann. Ich schaffe es nur die ersten vier Bit (also die 
Befehle des Steuerkreuzes) an den Pins auszugeben. (delay 75, 1 ist nur 
ein Makro, was nicht weiter beachtet werden soll)

Das Protokoll für die SNES-Controller ist das gleiche wir für die 
NES-Controller mit dem Unterschied, dass beim SNES die Anzahl der zu 
übertragenden Knöpfe 16 und beim NES 8 sind, außerdem ist die 
reihenfolge der Knopfzustände beim Nes etwas anders. (NES Reihenfolge: 
A, B, SELECT, START, UP, DOWN, LEFT, RIGHT). Das Protokoll für die 
Kommunikation der SNES finde man hier 
http://www.gamesx.com/controldata/snesdat.htm


Die Quelle http://www.raphnet.net/electronique/snes_nes_usb/index_en.php 
habe ich schon durchsucht und mir den Programmcode in C (nes.c, ein 
USB-Version möchte ich erstmal nicht erstellen) auch schon angesehen 
jedoch sehe ich keinen unterschied zu meinem Programm.

Hat jemand eine Idee woran es liegt? Ich bin für alle Vorschläge offen.

[Stefan B. (stefan)]

Arbeitest du mit dem STK500 oder einer externen Taktquelle? An sind je 
manche Pins mit Sonderfunktionen belegt... 
Beitrag "ATmega8 PORTB als Ausgang schalten"

[e-noob (Gast)]

Die einzigen FUSES die ich gesetzt habe sind: SPIEN (ISP, soweit ich 
weis), BOOTSZ1, BOOTSZ0, SUTO, und CKSEL3, CKSEL2 um die internen 4MHz 
Taktquelle zu nutzen. Ich benutze den gleichen Programmer wie 
http://s-huehn.de/elektronik/ (RSR232-variante).

Ich habe noch etwas ausprobiert und zwar invertiere ich ja kurz vor dem 
Ende des Programmcodes die erhaltenen Zustände der Tasten (com outreg) 
umd das richtige Ergebnis zu bekomme, lasse ich dies jedoch weg, dann 
leuchten ja alle Dioden (wenn ich nichts drücke) und beim drücken auf 
die Tasten gehen sie dann jeweils aus.

Das Interessante ist jedoch, dass die Dioden die auf Tastendruck mit der 
Invertierung nicht geläuchtet haben nun jetzt ausgehen (also gewünschter 
effekt) jedoch nach kurzer Zeit ein wenig Flackern und dann wieder 
ausgehen und dann wieder Flackern und so weiter.

Ich habe überhaupt keine Ahnung woran das liegt.

[Läubi .. (laeubi)]

Ich sehe jezt so auf den erstenblick nix, aber ich habe auch mal nen NES 
Controller folgendermaßen ausgelesen:

decode_NES_keys:
  /* 
     Decodiert den Tastenstatus auf einem NES Controller
     ---------------------------------------------------
     Stack: 3bytes
     Ergebnis: temp
     bit_muster bleibt nach verlassen auf altem wert.
     SREG wird gesichert und vor verlassen zurückgeschrieben
  */
  push bit_muster
  in temp, SREG
  push temp
  
  ldi temp, 0
  sbi CONTROLLER, LATCH      ; Strobe HIGH
  cbi CONTROLLER, LATCH      ; Strobe LOW
  ldi bit_muster, 0b00000001    ; Bit Muster laden Wird gleichzeitig als Schleifenzähler verwendet

  _data:
    nop              ; Etwas Zeit lassen bis die Daten anliegen
    nop              ; noch etwas
    sbis CONTROLLER_PIN, DATA  ; Pin Status prüfen
    or temp, bit_muster      ; Pin als gedrückt setzen
    lsl bit_muster        ; Bitmuster shiften
    sbi CONTROLLER, CLK      ; CLK HIGH
    cbi CONTROLLER, CLK      ; CLK LOW
    tst bit_muster        ; Bitmuster auf 0 testen
  brne _data
  pop bit_muster
  out SREG, bit_muster
  pop bit_muster
ret

Im ANhang mein komplette Testroutine.

[e-noob (Gast)]

@Läubi
Danke für das Beispielprogramm

Mit sbi und cbi geht es, wieso dass so ist weis ich aber nicht. Habe 
gestern auch noch was daran geändert (weis im Moment nicht was), jedoch 
nicht mehr getestet.

Wenn es jemand schafft mir den Unterschied zu den beiden Programmen zu 
erklären wäre ich dankbar.

[Läubi .. (laeubi)]

ich könnte mir vorstellen, das durch das out die Flanken gleichzeitig 
kommen, und das der baustein nicht so gerne mag. zudem braucht cbi/sbi 
zwei takte gegenüber einem von out, also ggf auch nen timing problem.

[e-noob (Gast)]

Ersteres könnte ich mir vorstellen, zweites aber nicht, da ich auch 
schon Code für den Gamepad hatte, bei dem ich nahezu jeden Takt gezählt 
hatte.