Warum läuft mein Programm nicht?!

jetzt mal grob drüber geschaut sehe ich sofort, das deine 
Interruptroutinen unvollständig sein ..

von der struktur her sollten sie so aufgebaut sein (habs mal eben aus 
meinem akt. projekt kopiert)

1

#pragma code high_vector=0x08

2

void MY_HIGH_INT (void)

3

  {

4

  _asm GOTO MY_HIGH_HANDLER _endasm

5

  }

6

7

#pragma code low_vector=0x18

8

void MY_LOW_INT (void)

9

  {

10

  _asm GOTO MY_LOW_HANDLER _endasm

11

  }

12

#pragma code

13

#pragma interrupt MY_HIGH_HANDLER

14

void MY_HIGH_HANDLER(void)

15

  {

16

        .... high interrupt routine ....

17

  }

18

19

/********************************************************/

20

/********************* L O W ****************************/

21

/********************************************************/

22

#pragma interruptlow MY_LOW_HANDLER

23

void MY_LOW_HANDLER(void)

24

  {

25

  .... low interrupt routine ...

26

  }

Hallo

steinigt mich bitte nicht! :-)
Ich hab gerade das falsche hochgeladen. Tut mir leid..

Hab mal den PIN 2 in der ISR wackeln lassen das geht schon.
also der Timer scheint zu laufen.

Wo ist Debounce_D0 ?

(Lass mal den ganzen Input-Teil weg, also eine möglichst einfache 
Hauptschleife:

1

    while(1){

2

3

      //******** Display und Counter aktualisieren ************  

4

      if ( sek_alt != sekunde ) {

5

        sek_alt = sekunde;

6

        lcd_ausgabe();

7

      }

8

    }

(Deine Kommemntare an dieser Stelle sind unsinnig und geben nur das was 
ohnehin im Code steht in mehr oder weniger denselben Worten wieder. Lass 
sie lieber weg, dann können sie wenigstens nicht falsch sein.)


Für Sekunde, Minute, Stunde solltest du einen unsigned char nehmen. Dann 
brauchst du dir auch um atomaren Zugriff keine Gedanken machen.

dr.schmock schrieb:
> Wenn es ein 8-Bit-Controller ist, und unsigned int von 0 bis 255 zählt,
> dann wird die 1000 nie erreicht.
> (weiß aber nicht wie "unsigned int" bei die definiert ist)

kann nicht sein.
ein int hat immer mindestens 16 Bit. Das ist so normiert.

>     TIMSK |= (1<<TOIE0); //Timer-Interrupt aktivieren

Wo ist die zugehörige ISR?

Wenn du einen Interrupt freigibst, dann MUSST du auch eine zugehörige 
ISR schreiben. Freigeben und keine ISR haben geht gar nicht.
(D.h. es geht schon. Nur führt das dazu, dass der Standardhandler einen 
Prozessor-Reset auslöst)


Ich denke, das ist dein eigentliches Problem.

Karl Heinz Buchegger schrieb:
> Wenn du einen Interrupt freigibst, dann MUSST du auch eine zugehörige
> ISR schreiben. Freigeben und keine ISR haben geht gar nicht.

Das wars..Volltreffer!
Vielen Dank!

eine Frage noch:
"(D.h. es geht schon. Nur führt das dazu, dass der Standardhandler einen
Prozessor-Reset auslöst)"

Ich habe in die Initi Funktion mal den PinWackler eingebaut
(das mag etz lustig klingen, aber so versuche ich immer Festzustellen 
wie weit das Programm geht):
PORTC ^= (1<<PC2);
mit dem Oszi hab ich erkennen können das der Pin auch dort hin und her 
wackelt.

Also ist es so zu verstehen das ich bis in die Init() gekommen bin dann 
er den Pinzustand geändert hat und dann im Timer sich quasi wieder 
resetet?
Sorry für meine Laienhafte Ausdrucksweise :-)

hans schrieb:
> Karl Heinz Buchegger schrieb:
>> kann nicht sein.
>> ein int hat immer mindestens 16 Bit. Das ist so normiert.
>
> wo ist das normiert?

C Standard

> also ich bin da der selben meinung wie dr.schmock und konnte eben auf
> die schnelle auch im c-standard nichts finden, was deine aussage
> unterstützt.

Ich hab jetzt keinen C Standard bei mir. Es ist aber mit 100% Sicherheit 
festgelegt, dass ein int mindestens 16 Bit haben muss. Er kann größer 
sein, aber kleiner ist nicht zulässig.

Matthias Kugler schrieb:

> Also ist es so zu verstehen das ich bis in die Init() gekommen bin dann
> er den Pinzustand geändert hat und dann im Timer sich quasi wieder
> resetet?


So ungefähr.
Das Programm ist soweit gekommen, bis der Timer seinen Overflow erreicht 
hat. Da du keine ISR hast, wurde alles resettet und das Programm hat 
wieder von vorne angefangen. Wieder und immer wieder

Karl Heinz Buchegger schrieb:

>> also ich bin da der selben meinung wie dr.schmock und konnte eben auf
>> die schnelle auch im c-standard nichts finden, was deine aussage
>> unterstützt.
>
> Ich hab jetzt keinen C Standard bei mir. Es ist aber mit 100% Sicherheit
> festgelegt, dass ein int mindestens 16 Bit haben muss. Er kann größer
> sein, aber kleiner ist nicht zulässig.


Da ich auf die Schnelle kein frei zugängliches ISO C-Standard Dokument 
finden konnte, darf ich mir erlauben auf Wiki (ich weiß, Wiki kann man 
auch nicht alles glauben) zu verweisen

http://en.wikipedia.org/wiki/C_variable_types_and_declarations

Karl Heinz Buchegger schrieb:
> Karl Heinz Buchegger schrieb:
>
>>> also ich bin da der selben meinung wie dr.schmock und konnte eben auf
>>> die schnelle auch im c-standard nichts finden, was deine aussage
>>> unterstützt.
>>
>> Ich hab jetzt keinen C Standard bei mir. Es ist aber mit 100% Sicherheit
>> festgelegt, dass ein int mindestens 16 Bit haben muss. Er kann größer
>> sein, aber kleiner ist nicht zulässig.
>
>
> Da ich auf die Schnelle kein frei zugängliches ISO C-Standard Dokument
> finden konnte, darf ich mir erlauben auf Wiki (ich weiß, Wiki kann man
> auch nicht alles glauben) zu verweisen
>
> http://en.wikipedia.org/wiki/C_variable_types_and_declarations

Ah. Hab einen gefunden

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
(Ist zwar nur ein Draft, allerdings von 2005. Diese Dinge sind aber seit 
Anbeginn von C immer gleich geblieben, waren also auch so schon in 
vorhergehenden Standards und wenn ich mich nicht sehr täusche schon im 
Ur-C von K&R schon mit dieser Konsequenz beschrieben.)

1

Seite 21. Clause 5.2.4.2 "Numerical Limits"

2

3

5.2.4.2.1 Size of integer types

4

5

1  ..... Their implementation-defined values shall be equal or greater

6

   in magnitude (absolute value) to those shown, with the same sign.

Also: die Limits müssen gleich oder größer sein, als die im Dokument 
gezeigten.

Welche sind

1

— minimum value for an object of type short int

2

      SHRT_MIN -32767 // −(2^15 − 1)

3

— maximum value for an object of type short int

4

      SHRT_MAX +32767 // 2^15 − 1

5

— maximum value for an object of type unsigned short int

6

      USHRT_MAX 65535 // 2^16 − 1

7

— minimum value for an object of type int

8

      INT_MIN -32767 // −(2^15 − 1)

9

— maximum value for an object of type int

10

      INT_MAX +32767 // 2^15 − 1

11

— maximum value for an object of type unsigned int

12

      UINT_MAX 65535 // 2^16 − 1

mit weniger als 16 Bits sind diese Limits nicht zu erreichen. Daher: ein 
int muss mindestens 16 Bit haben. Drunter geht nicht. Mehr ist möglich.


(und damit keine Missverständnisse aufkommen. Das Wörtchen 'shall' 
bedeutet in diesem Standard Dokument nicht, dass man es sich aussuchen 
darf, sondern es ist ein definitives 'das muss so sein')

dr.schmock schrieb:

> Interessant ist, dass eindeutige Typen wie "uint16_t" durch das
> "unsigned int" definiert ist, und nicht umgekehrt.

Hat historische Gründe


ursprünglich gab es die ganzen uint16_t (und wie sie alle heißen) nicht, 
sondern nur int, long, unsigned, short int etc. etc.

Die Idee war, dass es den Programmierer gar nicht kümmern soll, wieviele 
Bits der jeweilige Datentyp hat. Er wusste: ein int geht auf jeden Fall 
von -32766 bis +32767 und das war alles was ihn interessieren sollte. 
Wenn jetzt es auf einer CPU so wäre, dass Integer Operationen mit 3 
Bytes schneller sind als solche mit 2 Bytes (konstruiertes Beispiel ich 
weiß), dann sollte der Compiler in der Lage sein, das auch nutzen zu 
dürfen, selbst wenn er damit 1 Byte zuviel rumschleppt. 'int' sollte 
sowas wie der 'Leib und Magendatentyp' der jeweiligen CPU sein. Erlaubt 
ist was gefällt und was für Dampf auf der CPU sorgt, solange es nur 
mindestens den Bereich -32766 +32767 abdeckt.


Das war auch alles schön und gut. Nur in der µC Programmierung ist man 
halt gezwungen, manchmal konkrete Bitzahlen vorzuschreiben. Auch beim 
Einlesen von binären Files oder überhaupt Datenkommunikation ist es eher 
hinderlich, wenn man keine konkreten Bitzahlen festgelegt hat.

Das hat dazu geführt, dass jeder Programmierer sein eigenes Süppchen 
gekocht hat, indem er sich einen Header ähnlich wie stdint.h aufgebaut 
und benutzt hat. Das Problem: Jeder hat natürlich seine eigenen Namen 
für die Datentypen erfunden.
Und um das abzustellen, hat man sich dann endlich im Normungsgremium 
erbarmt und dafür einen Standard-Header ins Leben gerufen.

Ich wollt hier nochmal einhaken, da sich das ganze sehr interessant 
entwickelt.

ist es jetzt besser ich verwende

uint8_t statt unsigned char
uint16_t statt unsinged int
usw...
oder andersrum?

Wenn ich mir das durchlese ist es für C Programmierung auf uC besser ich 
verwende die uint8_t Bezeichnungen um mit konkreten Bitzahlen zu 
arbeiten?!

Das hängt (wie immer) vom Einsatz ab.

Für einen Schleifenzähler der 0 bis 10 zählt ist (in der Regel) ein 
int oder unsigned int "optimal", da hier der Compiler den 
schnellsten internen Datentyp verwenden darf. Alternativ kann man noch 
etwas nachhelfen indem man den "schnellsten Datetyp" der mindestens n 
Bits breit ist "anfordert". Das ist in diesem Fall int_fast8_t oder 
uint_fast8_t. Damit darf sich der Compiler (oder besser gesagt, der 
Compilerentwickler) den schnellten Typ der diese Bedingung erfüllt 
aussuchen. Je nach Zielprozessor und Compilerhersteller kann dabei etwas 
anderes eingestellt sein. Was eben auf dieser Plattform am schnellsten 
ist. Auf dem AVR wird daraus zB ein 8-Bit char, auf einem i386 ein 
32-Bit int.

Anderersets hat du zB beim FAT Dateisystem Strukturen mit fest 
definierten Feldlängen. Hier für einen 16Bit Wert einfach unsigned int 
zu verwenden und für 32 Bit unsigned long mag auf dem einen System 
funktionieren, ist aber höchst unportabel, da unsigned int auf einer 
anderen Architektur oder Compiler auch 32 Bit breit sein darf. Darum 
nimmt man hierfür besser die Datentypen mit der fest definierten Länge.

Edit. da war Rolf wieder schneller ;-(