Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ATmega128, Timer1-overflow Problem

21 views
Skip to first unread message

Stefan

unread,
Mar 12, 2012, 4:31:02 AM3/12/12
to
Hallo,

ich hab hier gerade ein kleines Problem.

Timer1 eines ATmega128 soll mit dem Prozessortakt getaktet werden. Bei
overflow soll ein weiterer 16 Bit-Zähler incrementiert werden.

Initialisierung sieht folgendermaßen aus:

...
TCCR1B = (0<<CS12)+(0<<CS11)+ 1<<CS10);
TCNT1 = 0;
TIMSK = (1<<TOIE1);
...


Dazu die INT-Routine:


Signal (SIG_OVERFLOW1)
{
timer1_high++;
}


In Main() frage ich timer1_hight ab und gebe den Wert aus.
Wenn ich TIMSK = (1<<TOIE1) ausklammere läuft mein Programm, natürlich
ohne Timer1_high zu incrementieren. Wenn ich die Zeile drin lasse,
knallt es.

Hat jemand eine Idee, woran das liegen könnte?

Gruß

Stefan

Heiko Lechner

unread,
Mar 12, 2012, 5:01:51 AM3/12/12
to
Am 12.03.2012 09:31, schrieb Stefan:

> TCCR1B = (0<<CS12)+(0<<CS11)+ 1<<CS10);

Hier sollte es schon eine Fehlermeldung geben (Klammer fehlt).

Warum nicht einfach: TCCR1B = (1 << CS10);?

> Signal (SIG_OVERFLOW1)

Signal wird nicht mehr benutzt:
http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

> Wenn ich TIMSK = (1<<TOIE1) ausklammere läuft mein Programm, natürlich
> ohne Timer1_high zu incrementieren. Wenn ich die Zeile drin lasse,
> knallt es.

Was knallt?

#include <avr/io.h> vergessen?

Stefan

unread,
Mar 12, 2012, 5:13:38 AM3/12/12
to
Am 12.03.2012 10:01, schrieb Heiko Lechner:
> Am 12.03.2012 09:31, schrieb Stefan:
>
>> TCCR1B = (0<<CS12)+(0<<CS11)+ 1<<CS10);
>
> Hier sollte es schon eine Fehlermeldung geben (Klammer fehlt).

ups, die Klammer ist irgendwie beim Kopieren verloren gegangen, ist im
Programm aber ok und kein Problem

>> Signal (SIG_OVERFLOW1)
>
> Signal wird nicht mehr benutzt:
> http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

ok, werd ich mal testen

>
>> Wenn ich TIMSK = (1<<TOIE1) ausklammere läuft mein Programm, natürlich
>> ohne Timer1_high zu incrementieren. Wenn ich die Zeile drin lasse,
>> knallt es.
>
> Was knallt?

Kann ich nicht genau sagen. Mein Programm stürzt ab, bzw. mein
LCD-Display zeigt nichts mehr an.

Ich habe das Programm mal modifiziert und statt TOIE1 den OCIE1A und den
compare-int aktiviert. Damit geht es.
...
TCCR1B = (0<<CS12)+(0<<CS11)+(1<<CS10);
TCNT1 = 0;
OCR1A = 0;
TCNT1 = 0;
TIMSK = (1<<OCIE1A);
...

SIGNAL (SIG_OUTPUT_COMPARE1A)
{
timer1_high++;
}

An _delay_ms() kann es nicht liegen, oder? Ich verwende _delay_ms in
main(). Nur so eine Idee, aber das sollte ja wohl ohne Timer1 laufen...

Gruß

Stefan

Stefan

unread,
Mar 12, 2012, 5:17:37 AM3/12/12
to
Am 12.03.2012 10:01, schrieb Heiko Lechner:
> Am 12.03.2012 09:31, schrieb Stefan:
>
>> Signal (SIG_OVERFLOW1)
>
> Signal wird nicht mehr benutzt:
> http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
>

Hm, mit ISR(SIG_OVERFLOW1) funktioniert es.

Seltsam...

Danke für den Tipp

Gruß

Stefan

Heiko Lechner

unread,
Mar 12, 2012, 5:53:15 AM3/12/12
to
Am 12.03.2012 10:17, schrieb Stefan:

> Hm, mit ISR(SIG_OVERFLOW1) funktioniert es.
>
> Seltsam...

Wenn schon dann: ISR(TIMER1_OVF_vect).

Aber wirklich seltsam- das kann eigentlich nicht alles sein was du
geändert hast [SIGNAL(SIG_OVERFLOW1) = ISR(TIMER1_OVF_vect) =
ISR(SIG_OVERFLOW1) = SIGNAL(TIMER1_OVF_vect)].

Du schrubst aber im ersten Posting:

Signal (SIG_OVERFLOW1)
{
timer1_high++;
}

Hattest du da wirklich "Signal" oder "SIGNAL" (oder gar "signal") stehen?

Stefan

unread,
Mar 12, 2012, 6:03:31 AM3/12/12
to
Am 12.03.2012 10:53, schrieb Heiko Lechner:
> Am 12.03.2012 10:17, schrieb Stefan:
>
>> Hm, mit ISR(SIG_OVERFLOW1) funktioniert es.
>>
>> Seltsam...
>
> Wenn schon dann: ISR(TIMER1_OVF_vect).
>

ok ;-)


> Aber wirklich seltsam- das kann eigentlich nicht alles sein was du
> geändert hast [SIGNAL(SIG_OVERFLOW1) = ISR(TIMER1_OVF_vect) =
> ISR(SIG_OVERFLOW1) = SIGNAL(TIMER1_OVF_vect)].
>
> Du schrubst aber im ersten Posting:
>
> Signal (SIG_OVERFLOW1)
> {
> timer1_high++;
> }
>
> Hattest du da wirklich "Signal" oder "SIGNAL" (oder gar "signal") stehen?

Puh, das weiss ich nicht mehr, aber da hätte der Compiler ja
gegebenenfalls meckern müssen.

Ich habs gerade mal probiert, der Compiler meckert, aber er macht kein
Error, nur ein Warning. Habs jetzt mit "SIGNAL" probiert und es
funktioniert. Lag also an der Groß/Kleinschreibung...

Scheiss C ;-) in Delphi wär das nicht passiert...

Gruß

Stefan

Klaus Bahner

unread,
Mar 12, 2012, 8:57:59 AM3/12/12
to
>
> Ich habs gerade mal probiert, der Compiler meckert, aber er macht kein
> Error, nur ein Warning. Habs jetzt mit "SIGNAL" probiert und es
> funktioniert. Lag also an der Groß/Kleinschreibung...
>
> Scheiss C ;-) in Delphi wär das nicht passiert...
>

Das hat nichts mit C zu tuen, sondern mit dem Compiler zu tuen.

Was kann C dafuer, dass du eine Interruptroutine anspringst, die der
Compiler nicht angelegt hat?

Gruss
Klaus

Heiko Nocon

unread,
Mar 12, 2012, 2:05:40 PM3/12/12
to
Klaus Bahner wrote:

>Was kann C dafuer, dass du eine Interruptroutine anspringst, die der
>Compiler nicht angelegt hat?

Er müßte es merken. Wenn C als Programmiersprache irgendwas taugen
würde, könnte er es auch merken...

Heiko Nocon

unread,
Mar 12, 2012, 2:05:40 PM3/12/12
to
Stefan wrote:

>Hat jemand eine Idee, woran das liegen könnte?

Vermutlich an diesem Scheißdreck namens C, den manche völlig Verrückte
eine Programmiersprache nennen...

Zeig' das Disassemblat. Nur da sieht man, was wirklich passiert!

Stefan

unread,
Mar 12, 2012, 2:50:53 PM3/12/12
to
Am 12.03.2012 19:05, schrieb Heiko Nocon:

> Vermutlich an diesem Scheißdreck namens C, den manche völlig Verrückte
> eine Programmiersprache nennen...

Ich vermute ja eher, dass exessives C - Programmieren erst zu Wahnsinn
führt ;-)

Gruß

Stefan

Gernot Fink

unread,
Mar 12, 2012, 3:00:02 PM3/12/12
to
In article <rlesl7tlckta905r1...@4ax.com>,
Heiko Nocon <Heiko...@gmx.net> writes:
>
> Er müßte es merken. Wenn C als Programmiersprache irgendwas taugen
> würde, könnte er es auch merken...

GCC gibt eine Warnung aus wenn man sich bei einem Interrupptnamen täuscht.
Wenn du aber den falschen Interrupt aktivierst merkt das keiner.

--
MFG Gernot

Alfred Gemsa

unread,
Mar 12, 2012, 3:12:17 PM3/12/12
to
Am 12.03.2012 19:50, schrieb Stefan:

>> Vermutlich an diesem Scheißdreck namens C, den manche völlig Verrückte
>> eine Programmiersprache nennen...
>
> Ich vermute ja eher, dass exessives C - Programmieren erst zu Wahnsinn
> führt ;-)

Entspann' dich bei

http://www.henning-thielemann.de/CHater.html

Alfred.

Heiko Nocon

unread,
Mar 12, 2012, 3:39:41 PM3/12/12
to
Alfred Gemsa wrote:

>Entspann' dich bei
>
>http://www.henning-thielemann.de/CHater.html

Hmm, Lesen allein gibt nicht den richtigen Eindruck.

Um C wirklich so richtig hassen zu lernen, muß man zumindest
gelegentlich selber in C programmieren.

Am besten Änderungen/Erweiterungen in einem bestehenden, etwas
länglicheren Machwerk sog. erfahrener C-"Programmierer".

Das ist echte Härte.

Stefan

unread,
Mar 12, 2012, 3:58:52 PM3/12/12
to
Ich hab dazu auch noch was:

http://www.pbm.com/~lindahl/real.programmers.html


Gruß

Stefan

Klaus Bahner

unread,
Mar 12, 2012, 5:14:40 PM3/12/12
to
Nein, das ist nun mal compiler-spezifisch. Ein vernuenftiger AVR
Compiler meckert so was ueberigens auch an bzw. benutzt eine eindeutige
Syntax fuer ISRs.

Gerade C ermoeglicht es dem Compiler-Entwickler uebrigens genau solche
Checks sehr einfach durchzufuehren.

Dass gcc diese Checks offenbar nicht implementiert, zweitens
antiquierten Unix Stil ("SIGNAL") erlaubt und drittens offenbar ISRs
wegoptimiert, wenn sie keinen Inhalt haben, koennte man eher als Beleg
fuer die kuerzlich von MaWin gemachte Einschaetzung zur Brauchbarkeit
von open-source-software deuten :-(

[Duck und weg]
Klaus

Frank Buss

unread,
Mar 12, 2012, 5:47:14 PM3/12/12
to
Klaus Bahner wrote:
>
> Dass gcc diese Checks offenbar nicht implementiert, zweitens
> antiquierten Unix Stil ("SIGNAL") erlaubt und drittens offenbar ISRs
> wegoptimiert, wenn sie keinen Inhalt haben, koennte man eher als Beleg
> fuer die kuerzlich von MaWin gemachte Einschaetzung zur Brauchbarkeit
> von open-source-software deuten :-(

Könnte man auch als Feature sehen. GCC muß ja auch alte Programme
compilieren können. Gut ist übrigens immer per -Wall zu compilieren,
oder gar -Werror. In meinen Programmen versuche ich sowieso immer alle
Warnings zu eliminieren, und nur wenn es gar nicht anders geht (z.B.
Fremdbibliothek eingebunden) per Compiler-Switch zu unterdrücken, so
übersieht man keine wichtigen neuen Warnings. Jedes Werkzeug ist immer
nur so gut wie derjenige der es verwendet. GCC zählt meiner Meinung nach
zu den eher positiven Beispielen von Open Source Software.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Jan Kandziora

unread,
Mar 12, 2012, 6:09:30 PM3/12/12
to
Klaus Bahner wrote:
>
> Dass gcc diese Checks offenbar nicht implementiert, zweitens
> antiquierten Unix Stil ("SIGNAL") erlaubt und drittens offenbar ISRs
> wegoptimiert, wenn sie keinen Inhalt haben, koennte man eher als Beleg
> fuer die kuerzlich von MaWin gemachte Einschaetzung zur Brauchbarkeit
> von open-source-software deuten :-(
>
Quark, in Binary-Only-Software ist so ein Mist auch regelmäßig drin und wird
evtl. niemals gefixt, weil der Hersteller daran nichts verdient.

Bei OSS kannst du das notfalls selbst fixen. Oder jemanden bitten, der mehr
Ahnung hat, es für dich zu tun.

Mit freundlichem Gruß

Jan

Falk Willberg

unread,
Mar 12, 2012, 6:53:01 PM3/12/12
to
Am 12.03.2012 22:14, schrieb Klaus Bahner:
> On 12-03-2012 19:05, Heiko Nocon wrote:
>> Klaus Bahner wrote:
>>
>>> Was kann C dafuer, dass du eine Interruptroutine anspringst, die der
>>> Compiler nicht angelegt hat?
>>
>> Er müßte es merken. Wenn C als Programmiersprache irgendwas taugen
>> würde, könnte er es auch merken...
>>
> Nein, das ist nun mal compiler-spezifisch. Ein vernuenftiger AVR
> Compiler meckert so was ueberigens auch an bzw. benutzt eine eindeutige
> Syntax fuer ISRs.

Was ich am gcc schätze, ist, daß ich *einen* Compiler für viele
Plattformen habe. Ein AVR-Compiler kann sicher viele Eigenschaften der
AVR berücksichtigen. Die genaue Kenntnis der Plattform ersetzt er nicht.
Ein anderer Zielprozessor benötigt dann einen anderen Compiler, die
Handbücher muß man trotzdem lesen. Wer mal mit ADCs in AVR und MSP430 zu
tun hatte, weiß,was ich meine.

...

Wer in C programmiert, muß sehr genau wissen, was er tut. Wer in java
programmiert, muß das anscheinend nicht. Und das merkt man oft genug.

Falk
--
Es gibt doch diese Kombimodelle, die man auch ans Fahrrad hängen kann,
wenn man sein Kind nicht so gern hat.
Ulrich G. Kliegis in d.r.s.s über Kinderwagen

Matthias Weingart

unread,
Mar 13, 2012, 5:20:25 AM3/13/12
to
Stefan <stefan@hier_steht_absichtlich_keine_EMail_Adresse_1234567890.de>:
Was wollt ihr? C ist doch bloss ein Wrapper für den Assembler. Ein klein
wenig weiterentwickelter als eine Assembler Macrosprache und es hat ne
Gleitkommabibliothek eingebaut. Mehr nicht. ;-)

M.

Hergen Lehmann

unread,
Mar 13, 2012, 5:46:43 AM3/13/12
to
On 13.03.2012 10:20, Matthias Weingart wrote:

>>> Um C wirklich so richtig hassen zu lernen, muß man zumindest
>>> gelegentlich selber in C programmieren.
>>>
>>> Am besten Änderungen/Erweiterungen in einem bestehenden, etwas
>>> länglicheren Machwerk sog. erfahrener C-"Programmierer".
>>>
>>> Das ist echte Härte.

Man kann in jeder Programmiersprache unlesbare Programme schreiben, und
von den möglichen Alternative in kleinen Embedded-Umgebungen (C,
Assembler, evtl. noch Forth) ist C noch mit Abstand am besten lesbar.

> Was wollt ihr? C ist doch bloss ein Wrapper für den Assembler. Ein klein
> wenig weiterentwickelter als eine Assembler Macrosprache und es hat ne
> Gleitkommabibliothek eingebaut. Mehr nicht. ;-)

Für antikes K&R-C hat das einen wahren Kern. Moderne Varianten (ANSI-C,
C++) bieten dann aber doch eine ganze Menge Features, mit denen ein
guter Programmierer sehr gut les- und wartbare Programme produzieren kann.

Hergen

Dieter Wiedmann

unread,
Mar 13, 2012, 6:05:08 AM3/13/12
to
Am 13.03.2012 10:46, schrieb Hergen Lehmann:

> Für antikes K&R-C hat das einen wahren Kern. Moderne Varianten (ANSI-C,
> C++) bieten dann aber doch eine ganze Menge Features, mit denen ein
> guter Programmierer sehr gut les- und wartbare Programme produzieren kann.

Wichtig sind hier die Worte 'guter' und 'kann'. :-)


Gruß Dieter

Matthias Weingart

unread,
Mar 13, 2012, 6:22:01 AM3/13/12
to
Dieter Wiedmann <dieter....@t-online.de>:
Letzlich sind die Krankheiten von C nichts anderes wie der Gebrauch der
unregelmässigen Verben in natürlichen Sprachen: das menschliche Gehirn ist
flexibel genug, sich die Ausnahmen zu merken und damit umzugehen. Aber das
braucht Zeit. Die meisten Probleme haben die Neulinge.... ;-).
Warum setzt sich das Beste eigentlich so gut wie nie durch?

M.

Horst-D.Winzler

unread,
Mar 13, 2012, 6:36:05 AM3/13/12
to
Am 13.03.2012 11:22, schrieb Matthias Weingart:

> Warum setzt sich das Beste eigentlich so gut wie nie durch?
>
> M.

Weil das Beste nie fertig wird. Das Zweitbeste zu spät kommt und das
Drittbeste für Anschlußaufträge sorgt.

--
mfg hdw

Klaus Bahner

unread,
Mar 13, 2012, 7:57:11 AM3/13/12
to
Hat es doch - oder kennst du etwas besseres als C?

SCNR
Klaus

Edzard Egberts

unread,
Mar 13, 2012, 8:06:44 AM3/13/12
to
Klaus Bahner schrieb:
> On 13-03-2012 11:22, Matthias Weingart wrote:
>> Warum setzt sich das Beste eigentlich so gut wie nie durch?
>>
>
> Hat es doch - oder kennst du etwas besseres als C?

C++, das hat sich auch recht gut durchgesetzt. :o)

Matthias Weingart

unread,
Mar 13, 2012, 8:10:49 AM3/13/12
to
Edzard Egberts <ed...@tantec.de>:
Vom Regen in die Traufe? *duck* ;-)

M.

Edzard Egberts

unread,
Mar 13, 2012, 9:11:01 AM3/13/12
to
Matthias Weingart schrieb:
Eigentlich sogar im Regen in die Traufe, denn C++ hat viele tolle
zusätzliche Möglichkeiten, Fehler zu machen. Aber wenn man einfach nur
das ++ nutzt und nicht das C, ist es schon eine erhebliche Verbesserung.

Allerdings habe ich noch nie ein echtes C++-Tutorial gesehen, das z.B.
Zeiger als "advanced programming" ganz hinten behandelt und kein
printf() oder scanf() verwendet, sondern konsequent mit Streams
arbeitet. So ein Code sieht nicht besonders nach C aus...

Michael Baeuerle

unread,
Mar 13, 2012, 9:18:21 AM3/13/12
to
Matthias Weingart wrote:
> Edzard Egberts wrote:
> > Klaus Bahner schrieb:
> > >
> > > Hat es doch - oder kennst du etwas besseres als C?
> >
> > C++, das hat sich auch recht gut durchgesetzt. :o)
>
> Vom Regen in die Traufe? *duck* ;-)

Wie hat Bjarne Stroustrup doch gesagt:
|
| C makes it easy to shoot yourself in the foot.
| C++ makes it harder, but when you do,
| you blow away your whole leg!


Micha

Michael Schwingen

unread,
Mar 21, 2012, 5:56:52 PM3/21/12
to
On 2012-03-13, Michael Baeuerle <michael....@stz-e.de> wrote:
> Wie hat Bjarne Stroustrup doch gesagt:
>|
>| C makes it easy to shoot yourself in the foot.
>| C++ makes it harder, but when you do,
>| you blow away your whole leg!

Da wäre dann wohl der Verweis auf

http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/

angebracht ;-)

cu
Michael

Michael Baeuerle

unread,
Mar 22, 2012, 5:04:50 AM3/22/12
to
Michael Schwingen wrote:
> Michael Baeuerle wrote:
> >
> > Wie hat Bjarne Stroustrup doch gesagt:
> >|
> >| C makes it easy to shoot yourself in the foot.
> >| C++ makes it harder, but when you do,
> >| you blow away your whole leg!
>
> Da wäre dann wohl der Verweis auf
>
> http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/
>
> angebracht ;-)

Manchem Microcontroller *muss* man in den Fuss schiessen, sonst wacht er
nicht mehr auf oder stolpert wegen einem anderen Errata ueber den
intakten Fuss. *Deswegen* ist C so geeignet fuer diese Dinger. Wenn man
daneben zielt ist man natuerlich selber schuld.

#ifdef joke
C ist halt eine amerikanische Sprache - man kann rumballern wie man will
;-)
#endif


Micha
0 new messages