Pin wird einfach auf high gesetzt

Gast #2232502
Lesenswert?

Hi Leute
Mal schaun vieleicht könnt ihr mir helfen.

Im Anhang ist mein kompletes Programm, aber das Problem liegt hier:

1
ISR(TIMER1_COMPA_vect)
2
{
3
  if (hilf == 0)
4
  {
5
    PORTA |= 0x20;
6
    hilf = 1;
7
  }
8
  else
9
  {
10
    PORTA &= ~0x20;
11
    hilf = 0;
12
  }  
13
}


Am PINA5 hab ich eine LED angeschlossen und am PINA6 einen Summer.
In dieser ISR sollte nur der PIN5 getoggelt werden. Aus irgendeinen 
Grund wird jedoch auch der PIN6 getoggelt was dazu führt, wenn die LED 
leuchtet auch der Summer ein Signal von sich gibt. Wenn ich beim 
Debuggen wärend des Programmverlaufes stoppe hängt das Programm immer in 
der DELAY BASIC (delay loop 2).

Ich hoffe ihr könnt mir weiterhelfen ;)
Angehängte Dateien:
Gast #2232531
Lesenswert?

Mal abgesehen von dem wahrscheinlich vorhandenen Kurzschluss zwischen 
PIN5 und PIN6, kannst Du das Toggeln auch viel einfacher, ohne 
Hilfsvariable, erreichen.
Die Information die in der Hilfsvariablen steckt, ist ja auch in dem 
Zustand des Pins enthalten. Es reicht also:
1
ISR(TIMER1_COMPA_vect)
2
{
3
  PORTB ^= (1<<PB5);
4
}
Gast #2232538
Lesenswert?

>naja dann müsste es umgekehrt genau sein wenn der Summer auf high is das
>auch die LED leuchtet was nicht der Fall ist

Um das abschliessend zu beurteilen, müsste man die Schaltung kennen. Da 
aber üblicherweise bei den AVR-Schaltungen die LED an Vcc angeschlossen 
wird und nicht an Masse, ist die Vermutung, dass ein Kurzschluss 
vorliegt erstmal plausibel.

Also, das nächste Mal die Schaltung angeben, dann brauchen wir nicht 
herumzuraten. ;-)
Gast #2232556
Lesenswert?

>es ist 100% was programmier technisch ...
>ich habe ein neues programm geschieben welches genau das selbe macht ...
>außer den Externen Interrupt

>und dabei bleibt der Summer stumm

Mein lieber Chris: Du kannst ja Deine eigenen Fehlersuchmethoden 
anwenden. Das sei Dir unbenommen. Aber dann frage nicht uns.

Es ist nunmehr also bei zwei Programmen, von denen wir eines garnicht 
und ein anderes nur in einem Fragment kennen, fraglich ob Du genau das 
geschrieben hast, was Du beabsichtigt hast oder nicht.
Und warum Du nun nicht einfach die Platine umdrehst und mal nachschaust 
(oder nachmisst) ist mir ehrlich gesagt auch nicht recht verständlich.

Ich halte mich 'raus.
Gast #2232567
Lesenswert?

Sorry aber wenn du nicht mal alles liest dann kannst dich ruhig 
aufregen...

1) ICH HABE EIN STECKBRETT und dabei die Kontakte auf Kurzschluss 
gemessen
2) Hab ich am anfang bereits erwähnt, das sich das Programm in der DELAY 
Schleife aufhängt
Gast #2232583
Lesenswert?

Ich habe Dir unrecht getan in Bezug auf das vorliegen des kompletten 
Quellcodes. Das tut mir leid.

>Sorry aber wenn du nicht mal alles liest dann kannst dich ruhig
>aufregen...

Mir ist das egal ob Du Dein Problem löst oder nicht. Du schätzt Deine 
Bedeutung zu hoch ein, wenn Du meinst, das ich mich Deinetwegen aufrege.

>1) ICH HABE EIN STECKBRETT ...
Schrei mich nicht an!

Das mit dem Steckbrett hast Du geschrieben während ich meine Antwort 
schrieb. Deswegen konnte ich es noch nicht wissen.
#2232596
Lesenswert?

Nebenbei:
> #include <avr/iom32.h>
Ist überflüssig, Raus damit.
<avr/io.h> sollte das schon inkludiert haben.


Wegen dem Toggeln von PIN6: Das macht vermutlich deine main().

Nimm das da mal raus, und schau ob das noch auftritt. Wenn nicht: Check 
deine Timer/ISR initialisierungen. Evtl. löst ein nicht abgefangener 
Interrupt (oder der WDT, ist der sicher nicht aktiv?) regelmäßig einen 
Reset aus.
Gast #2232605
Lesenswert?

ok wenn ich das Setzen des Pin6 aus der Main raus mach dann ist das 
problem weg ... aber müsste der prozessor nicht zurück in die while 
schleife springen nach dem Interrupt ... demnach das vor der schleife 
ignorieren ?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren