Hallo zusammen, versuche gerade, auf dem Pollinboard per Bascom einen Interrupt zu realisieren. Anhängend das sehr einfache Programm in Basic. Hierin soll einfach beim Timer0-Überlauf der Interrupt angesprungen werden, falls ich dort eine Taste drücke bzw. den entspr. Port Hi mache, soll ein anderer Port Hi werden (und bleiben). Normalerweise benötigt man hierzu keinen Interrupt, aber ich wollte lediglich anhand dieses sehr einfachen Codes diese Funktion zum Laufen bringen. Leider bleibt der Port Lo. Lege ich dagegen die Routine ins Hauptprogramm, reagiert der Port wie erwartet. Die Interrupt-Routine wird anscheinend gar nicht angelaufen, weil sie vermutlich falsch konfiguriert ist... Gruß Dieter
1) versuchs mal im Simulator 2) laß die Prüfung auf den Eingabepin erstmal weg in der ISR. Schreib nur "toggle portd.7" in die ISR und guck ob es blinkt 3) vielleicht warst Du auch zu ungeduldig - nimm mal einen kleineren Prescaler-Wert
Die logische Reihenfolge sehe ich so:
1 | ' ### BASCOM Einstellungen ### |
2 | $regfile = "m16def.dat" |
3 | $crystal = 16000000 |
4 | |
5 | ' ### Initialisierungen ### |
6 | Ddrd = &B11100000 |
7 | Portd = &B00000000 |
8 | Config Timer0 = Timer, Prescale = 1024 |
9 | On Timer0 Tim0_isr |
10 | Enable Timer0 |
11 | |
12 | ' ### Hauptprogramm ### |
13 | Enable Interrupts |
14 | Do |
15 | ' Nix |
16 | Loop |
17 | End |
18 | |
19 | ' ### ISR Timer0 Overflow ### |
20 | Tim0_isr: |
21 | If Pind.4 = 1 Then ' Taster3 jetzt gedrückt? |
22 | Set Portd.7 ' ja, dann Summer dauerhaft HIGH |
23 | End if |
24 | Return |
Bei deiner Reihenfolge werden die Interrupts eingeschaltet bevor die Routine dafür eingerichtet ist. Enable Timer0 ' Timer0 Interrupt zulassen Enable Interrupts ' Alle Interrupts einschalten On Timer0 Tim0_isr ' Wenn interript kommt Tim0_isr anspringen
Die Einhaltung der Reihenfolge Konfiguration/Interruptenable klingt logisch, hilft aber bei diesem Problem nicht. Exakt obige genannter Code bringt selbes Ergebnis, d. h. der Interrupt wird NICHT angelaufen. Wie gesagt, dieselbe Routine If Pind... Set Port... in die Hauptschleife gesetzt arbeitet ordnungsgemäß. Gibt es denn Leute hier, die mit der Demoversion von Bascom und Interrupt-Programmierung Erfahrung haben? Kann es sein, dass die Demoversion die Implementierung von Interrupts verweigert? Gruß Dieter
Hast Du den im Simulator auch das Kästchen "Simulate Timers" angeklickt? MfG Paul
Oh, es fehlt ein "n". Kommt portofrei hinterher...:-) Paul
Die Demo kann auch Interrupts. Zum Simulieren die Direktive $sim eintragen. Wenn Du in der ISR nur eine LED umschaltest - funktioniert das denn? Lies mal die Bascom-Hilfe zu "CONFIG TIMER0" - da stehen auch Beispiele.
Hallo, dann muss ich wohl weiter im Nebel stochern...und mal die Simulation probieren. Die Doku von Bascom bringt mich nicht weiter. Ob LED schalten oder Buzzer ist zweitrangig. Der Buzzer geht ja (obwohl da Pollin ja einen AC-Typ vorgesehen hat, der auch noch sehr nierderohmig ist). Gruß Dieter
Hast Du gemerkt, daß Du mit der Zeile Portd = &B00000000 die Ziehwidertände abschaltest? Dann wird das If Pind.4 = 1 Then.... nicht funktionieren. mach mal oben das hin Portd = &B00010000 und frage im Interrupt: If Pind.4 = 0 Then.... MfG Paul
Paul, bei dem Pollinboard ist das Abschalten der Pullups kein Fehler. Die Taster sind active high angeschlossen (http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Tasten_und_Schalter)
Im Simulator der BASCOM AVR Demoversion funktioniert dein Programm (im Screenshot durch Toggle einer LED ergänzt). Der Programmzeiger ist gerade beim Verlassen der ISR.
@Stefan Gut, dann weiß ich das jetzt, daß es bei diesem Board von Pollin so ist. MfG Paul
Hallo, also folgendes habe ich jetzt noch testen können: 1) Austausch gegen ein anderes Exemplar des Atmega16. => keine Änderung, d. h. am Chip liegt es nicht. 2) Timer0 mal so testen -- im Hauptprogramm: Arbeitet ordnungsgemäß. Das Timing entspricht exakt dem Wert, den man rechnerisch aus Quarzfrequenz und Prescale-Faktor erhält. Frage: Beim IDE-Fenster unter Project/Project Settings findet sich unter dem Tab Compiler folgende Zeile: {TOOLKITDIR}\bascomp {SOURCEFILE} hw=20 ss=20 fr=20 chip=8 Weiß jemand, was es damit auf sich hat und was die einzelnen Werte zu bedeuten haben? Ich habe nirgends in der Beschreibung etwas Konkretes finden können. Vor allem der Zusatz 'Chip=8' ist interessant. Mir ist ebenfalls nicht klar, wie der Compiler die relevanten und Chip-spezifischen Adressen hernimmt, denn wenn ich das $regfile = "m16def.dat" im Quellcode auskommentiere, gibt es beim Compilieren trotzdem keinen Fehler. Ich suche auch nach einem geeigneten einfachen Code in C, den ich mal ins AVRStudio laden könnte. So langsam glaube ich, der Bascom spinnt ein bisschen. Gruß Dieter
Dieter S. wrote: > 2) Timer0 mal so testen -- im Hauptprogramm: Arbeitet ordnungsgemäß. Das > Timing entspricht exakt dem Wert, den man rechnerisch aus Quarzfrequenz > und Prescale-Faktor erhält. Ich verstehe nicht, was du gemacht hast. Angenommen die Teilprobleme sind da: 1/ Summer summen lassen 2/ Timer timen lassen 3/ Taster tasten lassen 4/ LED toggeln lassen Alles zusammen funktioniert nicht. Wie sieht es mit den Teilen aus: 1/ Funktioniert, wenn SET PORTD.7 im Hauptprogramm verwendet wird. Richtig? 2/ ???, hängt das mit obigem Versuch zusammen? Wie genau wurde der gemacht? 3/ Funktioniert, wenn IF PIND.4 = 1 THEN ... ENDIF im Hauptprogramm verwendet wird. Richtig? 4/ Hast du das probiert? Die Toggelfrequenz ist ziemlich hoch (16,4 ms) und es ist wahrscheinlich, dass man kein Blinken sieht, sondern nur eine Abschwächung der LED gegenüber einer dauernd leuchtenden LED.
Hallo Dieter, hast zu einfach mal versucht, zyklische Overflow Interrupts vom Timer0 generieren zu lassen ? Ich hatte mit dem Mega16 auch das Problem, dass kein Overflow erzeugt wurde. Allerdings in C unter WinAVR. Geprüft On-Chip mit dem Dragon. Hatte dann aber keine Lust mehr zu suchen und habe einfach das Compare-Register auf 0xFF gesetzt und den Compare-Interrupt benutzt. Das klappte. Mein Gefühl sagt mir dass diese Chip nicht ganz in Ordnung ist. So habe ich z.B. nicht hinbekommen den Watchdog zu benutzen. Als eine Portierung vom Mega8 nicht lief habe ich ewig gesucht und schliesslich ein minimales Testprogramm generiert: SetWatchdog(Zyklus) For(;;){_delay_ms(50);TriggerWatchdog();} Trotzdem hat der Watchdog zyklisch resettet. Ich traue dem Mega16 nicht mehr und werde mich nach einem anderen Typen umschauen. Vielleicht kannst du meine Vermutung mit dem nicht funktionierenden T0-Overflow ja bestätigen. Hat jemand sonst hier Erfahrungen mit dem Mega16 ? Gruss - Bj
Stefan, zu 1) Der Summer arbeitet. Kann man ja feststellen, wenn man im Hauptprogramm den Port hierfür zyklisch umschalten lässt. zu 2) Wenn ich Timer0 im Hauptprogramm abfrage und z. B. den Port für den Summer bei einem Timer-Stand < 128 auf Lo und bei >= 128 auf Hi setze, ist die Funktionalität des Timers geprüft. Oszilloskop bestätigt auch korrekte Frequenz (16,384 ms, was einer Frequenz von ca. 61 Hz entspricht, mit dem Summer gut hörbar). zu 3) Der Taster arbeitet bzw. wird korrekt erkannt. Bestätigung durch andere Programme. zu 4) Die LEDs brauche ich für diesen Versuch nicht, sie gehen aber dennioch beide -- Test durch ein anderes Programm (testtool.bas, das von Pollin mitgeliefert wurde). Ich habe in meinem zweiten Posting geschrieben, dass der Port für den Summer, wenn die entsprechende Zeile ins Main lege, korrekt gesetzt wird. Der Summer macht dann zwar nur einen 'Knack', da er ja ein AC-Typ ist. Aber man hört es und sieht es auch sofort am Stromverbrauch, dass der Port gesetzt ist. Wenn ich den Port im Main toggeln lasse, ist der Summer laut vernehmbar. Ich bin mir ziemlich sicher, dass die Interrupt-Routine nicht angelaufen wird. Und im Verdacht habe ich dabei, dass der Compiler nicht richtig für den Atmega16 eingestellt ist (siehe {TOOLKITDIR}\bascomp {SOURCEFILE} hw=20 ss=20 fr=20 chip=8), wobei mir nicht klar ist, was tatsächlich einzustellen ist. Die Zeile mit der Direktive &m16def.dat wird anscheinend total ignoriert, weil die Compiler-Einstellung entscheidend ist. Dieses werde ich noch weiter verfolgen. Als nächsten Versuch bliebe mir noch, es auf einem Atmega8 zu versuchen bzw. das Ganze in C zu programmieren. Ich habe mit PICs schon viel mit Interrupt gearbeitet. Das sollte doch mit dem Atmega auch gelingen. Gruß Dieter
Dieter S. wrote: > zu 1) Der Summer arbeitet. Kann man ja feststellen, wenn man im > Hauptprogramm den Port hierfür zyklisch umschalten lässt. Zyklisch umschalten tust du in der ISR ja nicht. Dort wird immer auf HIGH gesetzt, d.h. der Summer hat nie ein LOW. Zyklischen Umschalten wäre ein TOGGLE statt SET. > zu 2) Wenn ich Timer0 im Hauptprogramm abfrage und z. B. den Port für > den Summer bei einem Timer-Stand < 128 auf Lo und bei >= 128 auf Hi > setze, ist die Funktionalität des Timers geprüft. Oszilloskop bestätigt > auch korrekte Frequenz (16,384 ms, was einer Frequenz von ca. 61 Hz > entspricht, mit dem Summer gut hörbar). Siehe 1. > zu 3) Der Taster arbeitet bzw. wird korrekt erkannt. Bestätigung durch > andere Programme. Gut. > zu 4) Die LEDs brauche ich für diesen Versuch nicht, sie gehen aber > dennioch beide -- Test durch ein anderes Programm (testtool.bas, das von > Pollin mitgeliefert wurde). Auch gut. Vorsicht Offtopic! Es ist aber für mich (und andere Antworter) i.A. hilfreich, wenn Tipps wie die LED-Schaltung einzubauen auch umgesetzt werden. Die Tipps werden nicht böswillig gegeben, sondern um bestimmte Ergebnisse *im aktuellen Kontext* zu produzieren. Manchmal hat man als Antworter eine Theorie und die möchte man gerne geprüft haben bevor man Sinn oder Unsinn in die Welt postet bzw. sich überhaupt die Mühe macht grosse Erklärungen abzulassen. Eine LED ist das einfachste Debugmittel... > Ich habe in meinem zweiten Posting geschrieben, dass der Port für den > Summer, wenn die entsprechende Zeile ins Main lege, korrekt gesetzt > wird. Der Summer macht dann zwar nur einen 'Knack', da er ja ein AC-Typ > ist. Aber man hört es und sieht es auch sofort am Stromverbrauch, dass > der Port gesetzt ist. Wenn ich den Port im Main toggeln lasse, ist der > Summer laut vernehmbar. Den Stromverbrauch hast du nicht, wenn die Summeransteuerung in der ISR steht? > Ich bin mir ziemlich sicher, dass die Interrupt-Routine nicht angelaufen > wird. Genau das könntest du sicher an der LED sehen, statt es zu vermuten. > Und im Verdacht habe ich dabei, dass der Compiler nicht richtig> > für den Atmega16 eingestellt ist (siehe {TOOLKITDIR}\bascomp > {SOURCEFILE} hw=20 ss=20 fr=20 chip=8), wobei mir nicht klar ist, was > tatsächlich einzustellen ist. Die Zeile mit der Direktive &m16def.dat > wird anscheinend total ignoriert, weil die Compiler-Einstellung > entscheidend ist. Dieses werde ich noch weiter verfolgen. So tief möchte ich in BASCOM nicht gehen, sorry. > Als nächsten Versuch bliebe mir noch, es auf einem Atmega8 zu versuchen > bzw. das Ganze in C zu programmieren.
1 | // $regfile = "m16def.dat" 'definieren des verwendeten Chips
|
2 | |
3 | // $crystal = 16000000 'definieren des verwendeten externen Quarz (8MHz ???)
|
4 | #define F_CPU 16000000
|
5 | |
6 | #include <avr/io.h> |
7 | #include <avr/interrupt.h> |
8 | |
9 | int main(void) |
10 | {
|
11 | // Ddrd = &B11100000 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
|
12 | // Portd = &B00000000 'definieren der einzelnen Pins an einem Port ( 0= low level; 1= high level)
|
13 | DDRD = 0b11100000; |
14 | PORTD = 0b00000000; |
15 | |
16 | // Config Timer0 = Timer, Prescale = 1024
|
17 | // http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#8-Bit_Timer.2FCounter
|
18 | TCCR0 |= (1<<CS00)|(1<<CS02); |
19 | TCNT0 = 0; |
20 | |
21 | // On Timer0 Tim0_isr
|
22 | |
23 | // Enable Timer0
|
24 | TIMSK |= (1<<TOIE0); |
25 | |
26 | // Start Timer0
|
27 | |
28 | // Enable Interrupts
|
29 | sei(); |
30 | |
31 | //Main: 'Hauptprogramm
|
32 | // Do 'Anfang der Schleife
|
33 | // Loop 'zum Anfang der Schleife
|
34 | do { |
35 | asm("nop;"); // Gelegenheit für Breakpoint im Simulator |
36 | } while(1); |
37 | |
38 | // End
|
39 | }
|
40 | |
41 | // Tim0_isr:
|
42 | ISR(TIMER0_OVF_vect) |
43 | {
|
44 | // If Pind.4 = 1 Then
|
45 | // Set Portd.7
|
46 | // End If
|
47 | |
48 | if ( PIND & (1<<PD4) ) |
49 | PORTD |= (1<<PD7); |
50 | |
51 | // Toggle Portd.6
|
52 | PORTD ^= (1<<PD6); |
53 | |
54 | // Return
|
55 | return; |
56 | }
|
Hexfile für den Atmega16 ist im Anhang (ohne Gewähr). > Ich habe mit PICs schon viel mit Interrupt gearbeitet. Das sollte doch > mit dem Atmega auch gelingen. No Panic! Das tut es auch.
Stefan B. wrote: > Dieter S. wrote: > >> zu 1) Der Summer arbeitet. Kann man ja feststellen, wenn man im >> Hauptprogramm den Port hierfür zyklisch umschalten lässt. > > Zyklisch umschalten tust du in der ISR ja nicht. Dort wird immer auf > HIGH gesetzt, d.h. der Summer hat nie ein LOW. Zyklischen Umschalten > wäre ein TOGGLE statt SET. Das weiß ich. Ich habe beides versucht, einen statischen Set und einen Toggle. Beides hätte ich gehörsmäßig registrieren können, so es funktioniert hätte. Bei ISR hat es aber nicht funktioniert, bei Einbau in Hauptprogramm eben schon. > >> zu 2) Wenn ich Timer0 im Hauptprogramm abfrage und z. B. den Port für >> den Summer bei einem Timer-Stand < 128 auf Lo und bei >= 128 auf Hi >> setze, ist die Funktionalität des Timers geprüft. Oszilloskop bestätigt >> auch korrekte Frequenz (16,384 ms, was einer Frequenz von ca. 61 Hz >> entspricht, mit dem Summer gut hörbar). > > Siehe 1. > >> zu 3) Der Taster arbeitet bzw. wird korrekt erkannt. Bestätigung durch >> andere Programme. > > Gut. > >> zu 4) Die LEDs brauche ich für diesen Versuch nicht, sie gehen aber >> dennioch beide -- Test durch ein anderes Programm (testtool.bas, das von >> Pollin mitgeliefert wurde). > > Auch gut. > > Vorsicht Offtopic! > > Es ist aber für mich (und andere Antworter) i.A. hilfreich, wenn Tipps > wie die LED-Schaltung einzubauen auch umgesetzt werden. Die Tipps werden > nicht böswillig gegeben, sondern um bestimmte Ergebnisse *im aktuellen > Kontext* zu produzieren. Manchmal hat man als Antworter eine Theorie und > die möchte man gerne geprüft haben bevor man Sinn oder Unsinn in die > Welt postet bzw. sich überhaupt die Mühe macht grosse Erklärungen > abzulassen. Eine LED ist das einfachste Debugmittel... Meine Antwort war ja auch nicht böse gemeint ;-)), nur habe ich den Test mit dem Port am Summer schon sicher durchgeführt bzw. sicher eruiert. Wenn ich toggeln bzw. schalten im Hauptprogramm schaffe, im ISR aber nicht, so weiß ich, dass der Summer geht und der Port auch richtig gewählt ist. > >> Ich habe in meinem zweiten Posting geschrieben, dass der Port für den >> Summer, wenn die entsprechende Zeile ins Main lege, korrekt gesetzt >> wird. Der Summer macht dann zwar nur einen 'Knack', da er ja ein AC-Typ >> ist. Aber man hört es und sieht es auch sofort am Stromverbrauch, dass >> der Port gesetzt ist. Wenn ich den Port im Main toggeln lasse, ist der >> Summer laut vernehmbar. > > Den Stromverbrauch hast du nicht, wenn die Summeransteuerung in der ISR > steht? Nein, eben nicht, kein Knacken, kein erhöhter Stromverbrauch. Habe ich mehrmals gegengetestet (Hauptprogramm/ISR). > >> Ich bin mir ziemlich sicher, dass die Interrupt-Routine nicht angelaufen >> wird. > > Genau das könntest du sicher an der LED sehen, statt es zu vermuten. Das kann ich am Summer auch klären, zumal ich sogar immer auch noch das Scope an den Port gelegt habe. > >> Und im Verdacht habe ich dabei, dass der Compiler nicht richtig> >> für den Atmega16 eingestellt ist (siehe {TOOLKITDIR}\bascomp >> {SOURCEFILE} hw=20 ss=20 fr=20 chip=8), wobei mir nicht klar ist, was >> tatsächlich einzustellen ist. Die Zeile mit der Direktive &m16def.dat >> wird anscheinend total ignoriert, weil die Compiler-Einstellung >> entscheidend ist. Dieses werde ich noch weiter verfolgen. > > So tief möchte ich in BASCOM nicht gehen, sorry. > >> Als nächsten Versuch bliebe mir noch, es auf einem Atmega8 zu versuchen >> bzw. das Ganze in C zu programmieren. Vielen Dank für die Portierung ins C. Das werde ich dann wohl als nächstes testen bzw. gleich mal Dein Hex-File laden. Resultat wird berichtet. Dieter
Ich habe jetzt auch mit einem Summer experimentiert. Schau mal hier rein: Beitrag "Re: Die große Wanderkiste elektronischer Bauteile - Projektidee !"
Stefan, also der erste Test mit Deinem Hexfile hat auch nicht geklappt, d. h. der Summer-Port hat nicht geschaltet. Gruß Dieter
Dann weiss ich im Moment auch nicht weiter. Abgesehen davon hat mein Pollin Funk AVR Board v1.1 auch ein Problem mit PD7 bei der 28-Pol Fassung (Atmega8 u.a.). Da fehlt - nachgemessen mit Durchgangsprüfer - eine Verbindung zur PD7 an der 40-Pol-Fassung und zu dem entsprechenden Pin an der 40-Pol Wannenbuchse. Die Verbindung PD7-40-Pol zu der 40-pol Wannenbuchse ist vorhanden. Möglicherweise wurde das schon vorher beobachtet: http://robotikportal.de/phpBB2/viewtopic.php?p=321115#321115 Jedfenfalls hat es mich heute mittag bestimmt eine Stunde gekostet, um das festzustellen und dann die Source auf einen anderen Pin umzukrempeln.
Hallo, inzwischen habe ich den bzw. die Fehler gefunden, weshalb der Interrupt nicht arbeitete. Ich schreibe es hier mal nieder, vielleicht hat jemand irgendwann mit ähnlichen Problemen zu kämpfen. In Bascom ist unter 1) Project/Settings/Compiler => chip=18 einzutragen für den Atmega16. Defaultmäßig steht hier chip=8 für den Atmega8. 2) Der Bascom-Compiler (jedenfalls ist es bei meiner Demoversion 1.11.7.9 so) interpretiert die Prescaler-Werte falsch: Quellcode effektiv 1 1 8 8 32 64 64 256 128 1024 256 no go 1024 no go Somit war mein Wert 1024 zu hoch bzw. falsch, jedoch nicht aus messtechnischen Gründen, sondern aus programmtechnischen. Darüber hinaus ist es irrelevant für das Arbeiten der ISR, a) in welcher Reihenfolge Config Timer0, On Timer0 und die Enables erscheinen. b) Ob ein Start Timer0 erscheint oder nicht. c) ob ein $regfile erscheint oder nicht. d) ob das END-Statement zw. Main und ISR oder erst ganz am physischen Ende des Codes steht. Obwohl das generierte Hexfile tatsächlich diesbezüglich variiert... Dieter
Hi Schon mal überlegt, dass der ATMega16 keine Vorteiler von 32 und 128 besitzt. Mit einem Blick ins Datenblatt hättest du dir deine 'Untersuchung' sparen können. MfG Spess
Spess, habe ja auch nicht behauptet, er hätte diese Teilerfaktoren. Diese Werte erscheinen in der Tabelle meines Postings auf der linken Seite, also im Quellcode. Die effektiven Teilerfaktoren sind dann 64 bzw. 256. Dieter
Hallo, mit der Version 1.11.9.1 sind die oben beschriebenen Probleme anscheinend behoben. Was jetzt immer noch problematisch ist, ist das Brennen des Flash über Bascom. Das ist aber ein anderes Thema (und war bei der alten Version auch schon so). Dieter
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.