mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR: Atmega16 Interrupt Timer0 über Bascom


Autor: Dieter S. (accutron)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Carsten Pietsch (papa_of_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die logische Reihenfolge sehe ich so:

' ### BASCOM Einstellungen ###
$regfile = "m16def.dat"
$crystal = 16000000

' ### Initialisierungen ###
Ddrd = &B11100000    
Portd = &B00000000
Config Timer0 = Timer, Prescale = 1024
On Timer0 Tim0_isr
Enable Timer0

' ### Hauptprogramm ###
  Enable Interrupts
  Do
  ' Nix
  Loop
End

' ### ISR Timer0 Overflow ###
Tim0_isr:
  If Pind.4 = 1 Then  ' Taster3 jetzt gedrückt?
    Set Portd.7       ' ja, dann Summer dauerhaft HIGH
  End if
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

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du den im Simulator auch das Kästchen "Simulate Timers" angeklickt?

MfG Paul

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, es fehlt ein "n". Kommt portofrei hinterher...:-)

Paul

Autor: Carsten Pietsch (papa_of_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul, bei dem Pollinboard ist das Abschalten der Pullups kein Fehler. 
Die Taster sind active high angeschlossen 
(http://www.mikrocontroller.net/articles/AVR-GCC-Tu...)

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan
Gut, dann weiß ich das jetzt, daß es bei diesem Board von Pollin so ist.

MfG Paul

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bj. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

// $regfile = "m16def.dat"      'definieren des verwendeten Chips

// $crystal = 16000000   'definieren des verwendeten externen Quarz (8MHz ???)
#define F_CPU 16000000

#include <avr/io.h>
#include <avr/interrupt.h>

int main(void)
{
// Ddrd = &B11100000  'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
// Portd = &B00000000 'definieren der einzelnen Pins an einem Port ( 0= low level; 1= high level)
  DDRD = 0b11100000;
  PORTD = 0b00000000;

// Config Timer0 = Timer, Prescale = 1024
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#8-Bit_Timer.2FCounter
  TCCR0 |= (1<<CS00)|(1<<CS02);
  TCNT0 = 0;

// On Timer0 Tim0_isr

// Enable Timer0
  TIMSK |= (1<<TOIE0);

// Start Timer0

// Enable Interrupts
  sei();

//Main:               'Hauptprogramm
//   Do               'Anfang der Schleife
//   Loop             'zum Anfang der Schleife
  do {
    asm("nop;");  // Gelegenheit für Breakpoint im Simulator
  } while(1);

// End
}

// Tim0_isr:
ISR(TIMER0_OVF_vect)
{
//  If Pind.4 = 1 Then
//    Set Portd.7
//  End If

  if ( PIND & (1<<PD4) )
    PORTD |= (1<<PD7);

//  Toggle Portd.6
  PORTD ^= (1<<PD6);

// Return
  return;
}


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.

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt auch mit einem Summer experimentiert.
Schau mal hier rein:
Beitrag "Re: Die große Wanderkiste elektronischer Bauteile - Projektidee !"

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan,

also der erste Test mit Deinem Hexfile hat auch nicht geklappt, d. h. 
der Summer-Port hat nicht geschaltet.

Gruß

Dieter

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter S. (accutron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.