Important announcement: there is an English version of this forum on 
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 :-)
/* * TEST_1.c * * Created: 04.04.2012 13:42:59 * Author: LD */ #ifndef F_CPU #define F_CPU 8000000UL //atmega8a mit internen 8MHz takt #endif #include <avr/io.h> #include <avr/interrupt.h> #include <util/delay.h> void main(void) { DDRD &=~(1<<PD2)|(1<<PD3); //interrupt_pins als input DDRD |= (1<<PD0)|(1<<PD1)|(1<<PD4)|(1<<PD5)|(1<<PD6)|(1<<PD7); //restlichen d-pins als ausgänge zum toggeln DDRB |= 0xFF; //ebenfals als toggel-pins DDRC |= 0xFF; //und noch mal toggel-pins zur interrupt-signal erzeugung MCUCR |= (1<<ISC11)|(1<<ISC10)|(1<<ISC01); //int1 steigend, int0 fallend GICR |= (1<<INT1)|(1<<INT0); //int0/1 freigeben sei(); //global interrupt while(1) { PORTD ^=(1<<PD0)|(1<<PD1)|(1<<PD4)|(1<<PD5)|(1<<PD6)|(1<<PD7);//d-pins als takt-quelle PORTB ^=(1<<PB3); //einen b-pin toggeln als konntrolle ob programm läuft PORTC ^=0xFF; //c-pins als takt-quelle _delay_ms(1000); //noch nen delay für einen schön sichtbaren takt aller toggel-pins } } ISR(INT0_vect) //int0 routine { PORTB ^=(1<<PB1); //für LED/Oszi _delay_ms(100); } ISR(INT1_vect) //int1 routine { PORTB ^=(1<<PB0); //für LED/Oszi _delay_ms(100); } |
Datum:
Bildformate!
Datum:
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
Datum:
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.
Datum:
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.
Datum:
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.
Datum:
> 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?
Datum:
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
Datum:
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
Datum:
Angehängte Dateien: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.
Datum:
Anm.: Ein #endif fehlt noch
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten