Forum: Mikrocontroller und Digitale Elektronik Digitale Signale mit Interrupt auslesen Probleme


von Florian R. (rager)


Angehängte Dateien:

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
}

von H. Bunse (Gast)


Lesenswert?

Bildformate!

von Krapao (Gast)


Lesenswert?

Bildformate

Was ist in den Bildern zu sehen?

[ ] INT0
[ ] INT1
[ ] PB0
[ ] PB1
[ ] PB3
[ ] PC0
[ ] PC1
[ ] PC2
[ ] PC3
[ ] PC4
[ ] PC5
[ ] PC6
[ ] PC7
[ ] PD0
[ ] PD1
[ ] PD4
[ ] PD5
[ ] PD6
[ ] PD7

von Florian R. (rager)


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.

von Karl H. (kbuchegg)


Lesenswert?

Florian Roesner schrieb:
> Stimmt was mit den Bildern nicht?

2MB Bilder (noch dazu JPG) werden von den Moderatoren gnadenlos 
runterskaliert. Wenn man dann nichts mehr erkennen kann - dein Pech. 
Benutz ein für den Zweck angemessenes Bildformat (JPG ist für Photos 
gut, für etwas, wo es auf Linien ankommt nicht (siehe Link) und eine 
angemessene Größe.

von Florian R. (rager)


Lesenswert?

Okay Ich werde das nächste mal besser drauf achten :-)
Falls es von Relevanz ist, die gleichen Ergebnisse wurde auch von einem 
Freund erzielt der den gleichen Versuch aufgebaut hat, unabhängig von 
mir und mit einem anderen Atmega8A.

von Krapao (Gast)


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?

von Hans (Gast)


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

von Florian R. (rager)


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

von Krapao (Gast)


Angehängte Dateien:

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.

von Krapao (Gast)


Lesenswert?

Anm.: Ein #endif fehlt noch

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.