Digitale Signale mit Interrupt auslesen Probleme

Florian R. OP #2636999
Lesenswert?
• ▲
▼ 
Hallo Leute
Ich bin gerade dabei einen Logikanalysator zu programmieren/bauen und 
bin jedoch auf folgendes Problem gestoßen:

Ich möchte INT0 und INT1 als Trigger benutzen
die softwareeinstellungen(siehe Programm) stimmen soweit auch.(Level an 
+5V und GND)

Das Problem: als Test habe ich mir einen Takt über ein paar IO-Pins 
erzeugt ... an manchen triggert er auch wie gewollt ... an anderen nicht 
(wie in den Oszi-Bilder sehr gut zu sehen.

verwendet wurden:
Ein belibiger PORTC pin -> triggert bei steigender Flanke an 
INT1(Oszi-Bild 0626)
Bei allen PORTD-Pins ergibt sich nur ein komisches Signal(siehe 
Oszi-Bild 0624)
Anstatt das sich das Signal nur bei steigender Flanke ändert, egal ob 
vorher HIGH oder LOW(in diesem Fall LOW), springt es sofort wieder 
zurück. Ich habe diesen Effect durch ein 100ms Delay besser sichtbar 
gemacht. Sonst wäre der Puls nur ca. 3us lang.


Die Frage ist nun: Warum toggelt er bei ALLEN PORTD-Pins nun "nonsens" 
und bei ALLEN PORTC-Pins gehts anständig ???

Ich Danke für jede Hilfe :-)


1
/*

2
 * TEST_1.c

3
 *

4
 * Created: 04.04.2012 13:42:59

5
 *  Author: LD

6
 */

7


8
#ifndef F_CPU

9
#define F_CPU  8000000UL   //atmega8a mit internen 8MHz takt

10
#endif

11


12
#include <avr/io.h>

13
#include <avr/interrupt.h>

14
#include <util/delay.h>

15


16
void main(void)

17
{

18
 DDRD  &=~(1<<PD2)|(1<<PD3);          //interrupt_pins als input

19
 DDRD  |= (1<<PD0)|(1<<PD1)|(1<<PD4)|(1<<PD5)|(1<<PD6)|(1<<PD7); //restlichen d-pins als ausgänge zum toggeln

20
 DDRB  |= 0xFF;             //ebenfals als toggel-pins

21
 DDRC  |= 0xFF;             //und noch mal toggel-pins zur interrupt-signal erzeugung

22
 MCUCR |= (1<<ISC11)|(1<<ISC10)|(1<<ISC01);      //int1 steigend, int0 fallend

23
 GICR  |= (1<<INT1)|(1<<INT0);         //int0/1 freigeben

24
 sei();               //global interrupt

25
 

26
 while(1)

27
 {

28
  PORTD ^=(1<<PD0)|(1<<PD1)|(1<<PD4)|(1<<PD5)|(1<<PD6)|(1<<PD7);//d-pins als takt-quelle

29
  PORTB ^=(1<<PB3);             //einen b-pin toggeln als konntrolle ob programm läuft

30
  PORTC ^=0xFF;              //c-pins als takt-quelle

31
  _delay_ms(1000);             //noch nen delay für einen schön sichtbaren takt aller toggel-pins

32
 } 

33
}

34


35
ISR(INT0_vect)    //int0 routine

36
{

37
 PORTB ^=(1<<PB1);  //für LED/Oszi

38
 _delay_ms(100);

39
} 

40


41
ISR(INT1_vect)    //int1 routine

42
{

43
 PORTB ^=(1<<PB0);  //für LED/Oszi

44
 _delay_ms(100);

45
}
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Florian R. OP #2637036
Lesenswert?
• ▲
▼ 
Stimmt was mit den Bildern nicht?
Bei mir funktionieren sie beide in Firefox und Opera.

Die rote  Linie ist in beiden Bildern INT1
Die gelbe Line in Bild 0626 ist PC0 und
Die gelbe Line in Bild 0624 ist PD6.

Die gelbe Linie liegt jeweils immer am interrupt an.

es wurde mit beiden Interrupts (INT0 + INT1), alles PC's und allen PD's 
getestet.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Krapao Gast #2637324
Lesenswert?
• ▲
▼ 
> Die rote  Linie ist in beiden Bildern INT1
> Die gelbe Line in Bild 0626 ist PC0 und
> Die gelbe Line in Bild 0624 ist PD6.

Diese Versuchsplanung verstehe ich nicht.

Ich würde in einem ersten Experiment PB0 (steigende Flanke INT1) und PB1 
(fallende Flanke INT0) als Ergebnis des Programms (Signale während ISR 
Verarbeitung) überwachen. Die Signalquelle (PD0 oder PC0) liegt auf dem 
Trigger des Oszis.

In einem zweiten Experiment (Signale vor ISR Verarbeitung) würde ich die 
Signale an den Eingängen von INT0 und INT1 abgreifen und auf dem Oszi 
anzeigen und mit dem ersten Experiment vergleichen. Die Signalquelle 
(PD0 oder PC0) liegt auf dem Trigger des Oszis.

Hast du schon nachgesehen, ob zwischen PB1 und PB0 eine Verbindung in 
der restlichen Schaltung besteht?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Hans Gast #2637473
Lesenswert?
• ▲
▼ 
Hi Leute,

also des mit dem "zweiten Versuch" verteh ich nicht.
Ich gehe mal davon aus, dass zum Verbinden von INTx und den Takt-Pins 
einfach nur Kabel oder so genommen wurden.

Wenns also mit einzelnen Pins als Takt geht und mit anderen nicht ist es 
finde ich unwahrscheinlich,
dass es an den Verbindungsleitungen liegt ... sonst würde es doch 
garnicht gehen oder wie war des gemeint ???

MfG
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Florian R. OP #2637502
Lesenswert?
• ▲
▼ 
Ich vergaß noch zu erwähnen das alle PORT's durch getestet wurden und es 
nur bei PORTD auftritt.
Natürlich habe ich als allererstes sämtliche Verlötungen 4-fach gecheckt 
und bin mir sicher, dass dort kein Problem liegt. Wie schon erwähnt wird 
dieses "Experiment" von zwei Leuten mit zwei Atmega8A's durchgeführt und 
zweimal genau das gleiche festgestellt wird. Es scheint also Atmega8A 
bedingt zu sein.
Die Frage ist ob schon jemand das gleiche beobachten konnte und/oder 
eine Erklärung/Lösung dafür hat :-)

LG,
Florian
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Krapao Gast #2637536
Lesenswert?
• ▲
▼ 
Ich kann beobachten, dass die Art der Takterzeugung in while einen 
Einfluss darauf hat, wie oft IRQs ausgelöst werden. Zu oft und die LEDs 
blitzen nur kurz (vgl. Bild 0624)!

Die Takterzeugung an PD4 (d.h. am gleichen Port an dem INT1/INT0 
eingeschaltet sind) nur mit XOR führt zu Problemen mit den ISRs. Bei PC4 
kann ich XOR benutzen. Es ist auch egal, ob ich den Takt von PC4 oder 
von PD4 auf INT0/INT1 gebe.

Ändere ich die Takterzeugung an PD4 dadurch dass ich die IRQs kurzzeitig 
sperre, kann ich XOR benutzen. Ändere ich die Taktertzeugung von XOR auf 
OR/AND, funktionieren INT1/INT0 auch erwartungsgemäß.

Interne Pullups an PD2/PD3 (INT0/INT1) haben keinen sichtbaren Einfluß 
auf das Ergebnis.
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren