Hallo Besucher, der Thread wurde 5,2k mal aufgerufen und enthält 37 Antworten

letzter Beitrag von CrazyIcecap am

Atmel-gebastel; Hilfe gesucht....

    Moinsen! Vorweg: Keinen Plan, ob ich hier im korrekten Bereich bin; allerdings habe ich die (hoffentlich nicht unbegründete) Hoffnung, dass bei der versammelten Anzahl an Elektronikfreaks doch der eine oder andere mit konkreter Hilfe aufwarten kann.


    Folgendes: Ich bin gerade dabei, ein kleines Projekt unter zuhilfenahme eines Atmel ATMega8 zu basteln (hatte halt noch ein paar wegen einer Wii-Bastelei rumfliegen :-) ).
    Einer der Bestandteile soll sein, ein CD32-Pad auszulesen. Hauptsächlich die Tasten. Ich habe nun ein kleines Testprogramm geschrieben, was aber irgendwie nicht die richtigen Resultate bringt....kennt sich hier jemand ausreichend mit AVR-ASM und CD32-Pads aus, um mir eventuell weiterzuhelfen?
    Das Endergebnis wird eine kleine, praktische Hilfe, der Code wird als OpenSource veröffentlicht.

    Hier gibt's ein paar Leute, die sich bestens mit AVR Assembler auskennen und die Dir bestimmt gerne weiterhelfen.
    Poste doch einfach mal Deinen Code hier rein und beschreibe was genau das Problem ist.

    Ich habe einen kleinen Versuchsaufbau gemacht, um erstmal ein wenig
    experimentieren zu können.
    Mein "Bastelboard" entspricht weitgehend dem, was im Tutorial von mikrocontroller.net (dort im Forum kam kein Feedback, nur am Rande) im 1.
    Kapitel vorgegeben ist; 4 Taster an PD0-3, 6 LEDs an PB0-5. Ergänzend habe ich
    eine SubD-Buchse an PC angebracht; Pin 6 an PC5, Pin 9 an PC4 und Pin 5
    an PC3. Pin 7 und 8 an VCC und GND.


    Nun wollte ich mit dem angehängten Code versuchsweise die Buttons vom
    Pad einzeln "manuell" abfragen. Aber irgendwie klappt es nicht; mir wird
    der Status von Blue angezeigt, wenn PC3 auf ON ist (was ja auch korrekt
    ist), aber alles andere lläuft nicht. Wenn ich PC3 auf OFF setze (per
    Button, klappt) und nen Logiktester an PC4 halte, wird mir ein low
    angezeigt; der Binärzähler vom Tester springt auch immer einen weiter,
    wenn ich Taster 0 (PD0) drücke, aber geht nie auf High, egal welche
    Buttons ich drücke.

    Hm.. so auf die Schnelle könnte ich mir vorstellen, dass Tastenprellen das Problem sein könnte. Das Programm macht vielleicht was es soll, aber die Tasten nicht. Schau mal ob Du die über Software entprellen kannst. Z.B. ein paar ms warten und dann nochmal nachschauen ob die Taste immernoch gedrückt ist. Erst dann den Ausgangsport ansteuern. Und bei der Gelegenheit vielleicht ein paar "nop"-Statements einbauen, damit das Schieberegister genug Zeit hat zu reagieren.

    LIFE IS SHORT - Break the rules, do more, need less, smile often, be brave, stay true, dream big, forgive quickley, kiss slowly, love truly, laugh uncontrollably and never regret anything that made you smile.

    Einmal editiert, zuletzt von Draco ()

    Das könnte es durchaus sein, muss ich mal austesten. Aber irgendwas war da noch...ich komm nur nicht mehr drauf....


    Ich habe auch ein MegaDrive-Pad versuchsweise ausgelesen, die NOPs haben mir da direkt geholfen :-)
    Was mich da nur wundert: Die LEDs pulsieren in der Helligkeit, woran das jetzt nu wieder liegt.....

    Das mit den LEDs ist bestimmt eine Art "Phasenschwebung". Das entsteht allgemein, wenn man ein Signal einer bestimmten Frequenz mit einem Signal einer anderen Frequenz mischt. Im speziellen Falle mit dem Mikrocontroller kann es daran liegen, dass man ein Eingangssignal einer bestimmten Frequenz nicht sauber abtasten kann, weil das Programm in seinen Abfragezyklen in einem ähnlichen Frequenzbereich liegt. So liest man bei einem Rechtecksignal eine Zeit lang immer 0 und dann auf einmal 1. Wenn sich das schnell genug abwechselt, dann "pulsiert" das gelesene Signal scheinbar.

    Kannst Dir ja das Programm dazu mal anschauen...hab das Pad an PortD gehängt und frage nur die Buttons ab, die über nen 74ls157 gemultiplext werden.
    Ich weiss, das ganze ist nicht sehr elegant gelöst, liegt wohl daran, weil ich mich erst seit vorgestern mit AVRASM beschäftige....

    Ich habe schon seit ca. einem Jahr nichts mehr mit dem AVR-ASM gemacht. Aber so aus dem Stand und ungeprüft :





    Etwas Struktur kann nicht schaden. Und wenn man einmal abgefragt hat, ob der Port nun "0" ist, braucht man mit dem nächsten Befehl eigentlich nicht nochmal die "1" überprüfen. Eine LED ist ein sehr träges Bauteil. Wenn viel an den Ports geschaltet wird, bekommen die diese Frequenz ab. Das kann man richtig eingesetzt dazu nutzen, die LEDs mit voller Leuchtkraft im Multiplexer-Betrieb zu schalten. Bei einer Tastaturabfrage sollte man die aber nicht umbeding im Poll beschalten.
    Nur nicht zu schnell aufgeben! - So ein AVR ist ein rasender Hirsch. Manchmal reicht es, wenn man mal etwas auf die Bremse tritt.


    Michael

    Danke für die Mühe....
    Hab das Programm mal eben getestet, nu sagen die LEDs nix. Ach ja, im Kommentar meines Codes hab ich nen Typo entdeckt, ganz oben sollte es natürlich "Port D" heissen und nicht "Port C".


    Irgendwie werde ich aus Deinem Code auch nicht richtig schlau, das mit dem Stackpointer habe ich nicht so wirklich verinnerlicht...
    Allerdings habe ich auch noch nie vorher programmiert. :P

    Code
    1. main: sbis PIND, 2
    2. rcall led0
    3. rcall wait
    4. sbis PIND, 4
    5. rcall led1
    6. rcall wait
    7. rjmp main


    Oh, wenn ich die Ports für die Tasten sehe : sbis ( : überspringen wenn 1) muss es wohl sein.


    Den Stack braucht man für die Subs. Ansonsten springt das Programm in den Tod.


    Code
    1. led0: in mp,LEDPORT ; Portbits holen
    2. andi mp,0b00000010
    3. cpi mp,0b00000010 ; vergleichen ob bit gesetzt ist
    4. brne led0_off ; nicht gleich, LED ausschalten
    5. cbi LEDPORT,2 ; oder LED einschalten
    6. ret
    7. led0_off:
    8. sbi LEDPORT,2
    9. rjmp main ; ret mal versuchen


    So oder so ähnlich könnte es klappen. Es wird der Zustand des Port-Latchs eingelesen. Danach wird per AND das passende bit maskiert und verglichen. Ist Bit ="1" wird die LED mit Löschen dieses bits eingeschaltet. Wenn das bit=0 dann wird es gesetzt (LED aus).


    Michael

    In dem Tastatur-Poll wird es doch sbic sein müssen. Ich bin auch ein bisschen raus. Hier : http://www.avr-asm-tutorial.net/avr_de/index.html ist ein schönes Tutorial mit Beispielen. Wenn Dir das zuviel Aufwand ist, kannst Du es auch mit BASCOM versuchen. Bei einfachen Port-Abfragen, LCD, ... allem wo es nicht auf zyklengenaues Timing ankommt, reicht der Basic-Matsch allemal.


    Michaeö

    BASCOM? Also richtig klassische BASIC-Programmierung? Hmmm....das könnte mir eher liegen. Ich will ja nur ein paar Joypads abfragen; da kommt es nicht auf zyklengenauigkeit an.


    edit: Ich habe mir ein paar Infos dazu mal durchgelesen; ich denke, das wirds für mich sein. Simpel und durchaus brauchbar....es muss nicht immer ASM sein.

    Einsteigern ist Bascom durchaus zu empfehlen. Wie einfach viele Programme mit Bascom sind, kann man hier schön sehen:
    http://www.roboternetz.de/wiss…ategorie:Quellcode_Bascom


    Eine Demoversion, die auf 4KB Code limitiert ist, findet man hier:
    http://www.mcselec.com/index.p…cat_view&gid=99&Itemid=54

    LIFE IS SHORT - Break the rules, do more, need less, smile often, be brave, stay true, dream big, forgive quickley, kiss slowly, love truly, laugh uncontrollably and never regret anything that made you smile.

    Einmal editiert, zuletzt von Draco ()

    Zitat von CrazyIcecap

    Hmmm......hat mal jemand eine deutschsprachige Befehlsübersicht mit Beispielen? Würde mir viel Zeit und Frust ersparen....


    Der Bascom hat eine sehr ausgiebige Hilfe wo alle Befehle in alfabetischer Reihenfolge genau erklärt sind. Es sind auch jede menge Beispiel Sourcecode dabei.

    Ich bin anscheinend selbst für BASIC zu blöd. Nun habe ich ein eigentlich ganz simples Programm geschrieben, und selbst das spackt rum. Auf 3 verschiedenen ATMegas ausprobiert.


    Zum Pad: Ich teste gerade mit einem MegaDrive-Pad. Siehe auch Hier.
    Dort ist ein 74HCT157 verbaut, um die Buttons zu multiplexen. Wenn auf Pin7 +5V gegeben werden, dann liegt das Signal von Button A auf Pin6 und Button Start auf Pin9 vom Joyport. Wenn Pin7 auf Masse geht, dann liegt das Signal von Button B auf Pin6 und Button C auf Pin9 vom Joyport. Im Pad sind Pullups für die Buttons und Richtungen.


    Wenn ich das ganze jetzt in den ATMega packe und das Pad anklemme, passiert folgendes:
    Button A gedrückt: Led0 und Led2 leuchten pulsierend.
    Button B: nix.
    Button C: nix.
    Start: Led1 und Led3 leuchten pulsierend.


    Bin ich zu doof, oder was?

    Hallo CrazyIcecap,

    Zitat von CrazyIcecap

    Dort ist ein 74HCT157 verbaut, um die Buttons zu multiplexen. Wenn auf Pin7 +5V gegeben werden, dann liegt das Signal von Button A auf Pin6 und Button Start auf Pin9 vom Joyport. Wenn Pin7 auf Masse geht, dann liegt das Signal von Button B auf Pin6 und Button C auf Pin9 vom Joyport. Im Pad sind Pullups für die Buttons und Richtungen.


    Wenn ich mir das Programm ansehe, finde ich folgendes:


    Dabei fällt auf, daß "Select7" obwohl es als Ausgang verwendet wird, als PIN (Port Input) definiert ist. Ich würde hier mal ein

    Code
    1. Select7 Alias Portb.6 ' PB6 geht an Pin 7 am Pad (Select-Line)


    draus machen. Das erklärt auch, warum LED0 und LED2 bzw. LED1 und LED3 immer zusammen leuchten!


    Gruß Martin