Interrupt Problem

Bevor die ganze Welt scheinbar gegen Dich ist, suche nach 'Tasten
entprellen' hier oder irgendwo. Fang am besten in der Codesammlung an
:-)

hallo michael

danke für deinen beitrag, aber ich glaube nicht an ein prellen des
tasters, hab den taster schon mal harewaremäßig entprellt, mit nem
kondensator aber immer noch selbe funktion.

wiso geht´s springt das programm nach dem interrupt nicht zurück in
meine endlosschleife?

kann´s vielleicht daran liegen das ich einen at90s1200 einsetze?

Kann es sein, dass dein Compiler deine leere Endlosschleife
wegoptimiert?? Wie sieht denn das Ergebnis in ASM aus?

...

Hast Du das Interruptfag zurückgesetzt? sonst springt er immer wieder in
die Interruptroutine?

hallo hannes, mamut,

danke für eure antworten, dank das kann mir schon mal weiterhelfen:

ich habe das interruptflag auf negative flanke gesellt, er spring also
nur einmal rein wenn ich drücke, das hab ich mit dem oszilloskop
gemessen.

ich benutzte wiravr
wie kann ich das ergebis meies compeilers in asm ansehen?`

das problem liegt wohl an hannes vermutung.
könnt ihr mir nochmal helfen?

michael

hallo!
ich hatte probleme mit c als entpreller bei nen mega8
er resetete ab und zu einfach mal so
hab wieder auf standart r entprellung umgestellt laueft jetzt ohne
probleme
ich meine auch mal was ueber cs am port gelesen zu habe
so von wegen nich gut ??? keien ahnung
aber scheint bei dir ja eher nen software bug zu sein
gruss juergen

hallo

ich hab noch mal ein wenig rumgespielt und festgestellt, das mein
programm neu gestratet  oder resetet wird wenn der timer/counter
überläuft.
womit kann das zusammenhängen das er nicht an die stelle ins programm
zurückspringt von der er kommt?

hab mein programm auch nochmal angeängt mit dem ich das festgestellt
hab.

ich programmier in winavr und im makefile hab ich den 2313 eingestellt
obwohl ich nen 1200 benutze, aber sonst würde ja der compeiler mekern.

jemand ne idee?

gruß michael

>>ich programmier in winavr und im makefile hab ich den 2313
eingestellt
>>obwohl ich nen 1200 benutze, aber sonst würde ja der compeiler
mekern.

schonmal ein fehler

du kannst keinen diesel mit benzin betanken und hoffen, dass es klappt

"ich programmier in winavr und im makefile hab ich den 2313
eingestellt
obwohl ich nen 1200 benutze, aber sonst würde ja der compeiler
mekern."

das ist aber nicht sinn der sache. irgendwie hat doch gcc sram
gebraucht. genau das ist der grund warum er bei 1200 meckert. du
solltest auf asm umsteigen um das problem zu lösen. wenn du nen anderen
avr im makefile einstellst stimmen u.a. die interupt-vektoren nicht
mehr. auch durch die änderung im makefile bekommt der 1200 kein sram.

kann man also nen 1200 nicht mit c programmieren sondern nur in
assembler, oder gibts noch andere möglichkeiten damit ich bei winavr
und c bleiben kann?

ja sicher gibt es die. besorg dir einen avr mit sram. ganz einfach und
eigentlich gar nicht mal teuer.
also ganz im ernst. ich denke mit dem 1200 wirst du in c nicht
weiterkommen.
wenn du eine funktion aufrufst wird ja alles auf dem stack gesichert.
kein sram=kein stack (also keine den man so benutzen kann)

hi sebastian,

da hast du wohl recht, ist wohl am einfachsten wenn ich mir einen mit
sram besorge. der 2313 ist ja von den anschlüssen fast gleich, mit dem
müsste es gehen, oder?

Und warum nutzt du nicht die Gelegenheit, in ASM einzusteigen???
Ist doch bedeutend einfacher und übersichtlicher als jede Hochsprache.
Denn jeder ASM-Befehl entspricht exakt einem Maschinenbefehl. Da
"optimiert" dir kein Compiler dazwischen und macht Dinge, die du
nicht nachvollziehen kannst.

Der 1200 und 2313 hat Unterschiede in der Interrupt-Vektor-Tabelle, im
SRAM, im Stackpointer, im Timer1 usw. Das kann der Compiler nicht alles
berücksichtigen. In ASM ist es jedoch ganz gut möglich, einfache
Programme so zu gestalten, dass sie auf beiden Typen laufen.

Übrigens kann ich nicht so recht glauben, dass man einen AVR in einer
Hochsprache optimal programmieren kann, wenn man die ASM-Grundlagen
nicht beherrscht. Bei einem Rechner mit Betriebssystem mag das gehen,
bei einem AVR (bei dem man direkt an der Hardware programmiert) kaum.

...