mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Stack overflow durch nested Interrupts?


Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Können nested Interrupts einen Stack Overflow bewirken?

Und wo kann man eigentlich eine Liste der häufigsten Fehler-Ursachen und 
eine Liste aller Fehlerursachen (bei Microcontrollern) finden?

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber sicher. Bei jedem Sprung in einen Interrupt wird die 
Rücksprungadresse ins Hauptprogramm auf dem Stack abgelegt (je nach 
Controller-Typ auch mehr), hinzu kommen noch evtl. gesicherte Register. 
Wenn nun sehr viele Interrupts verschachtelt aufgerufen werden, z.B. 
durch Aufrufe in mehreren Prioritäten, kann der Stack schon mal ins 
Schwitzen kommen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt ganz auf den Prozessor an:

Z.B. beim 8051, der verschiedene Prioritäten in Hardware macht, nicht, 
da ja jede Priorität (max 4) auch nur einmal aktiv sein kann.


Aber z.B. beim AVR muß man höllisch aufpassen. Einfach nur die 
Interrupts wieder freigeben reicht da bei weitem nicht.
Damit ist ein Interrupt, der sich immer wieder selbst unterbricht schon 
vorprogrammiert. Ist dann quasi wie eine Rekursion ohne 
Abbruchbedingung.

Man muß also in sämtlichen Interrupts niederer Priorität sämtliche 
Interruptfreigaben neu setzen, d.h. nur die hohen enabled lassen, ehe 
der globale wieder freigegeben wird.


Fehlerlisten habe ich bisher noch nicht gesehen.
Das ist ja auch stark unbterschiedlich, z.B. je nach Architektur, 
Programmierstil, Programmiersprache bzw. reine Anfängerfehler.

Es gibt aber eine Menge Empfehlungen für gutes Programmieren.


Peter

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, dann müssen einige Eingänge wohl hardwaremäßig enptprellt werden 
oder es müssen häufiger alle Interrupts disabled werden.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es ums Entprellen geht, dann ist der externe Interrupt ja auch 
völlig fehl am Platze. So etwas muß man doch im Timerinterrupt machen 
(siehe Codesammlung).

Externe Interrupts sind nur dann gut, wenn man auch wirklich sehr 
schnell auf etwas reagieren muß, z.B. die Daten von einem Ethernetchip 
lesen oder von einer Festplatte usw., also Signale von digitalen 
Quellen.

Der externe Interrupt reagiert ja innerhalb 1µs oder weniger und so 
schnell drückt kein Mensch eine Taste.


Peter

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber ich habe hier Code von einem anderen, der auf rund 100.000 
Geräten läuft u. der nun nach einer kleinen Hardware-Änderung nicht mehr 
richtig läuft. Es gibt da auch eine Funktion für busy wating um so zu 
entprellen, aber elegant ist das nicht.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Timerinterrupt hat ja auch überhaupt nichts mit "busy waiting" zu 
tun.
Er liefert Dir ganz genau so, wie der externe Interrupt ein Signal, 
bloß, daß es eben bereits entprellt ist und um die Entprellzeit 
(10..100ms) verzögert.
Diese Entprellzeit wird aber nicht nutzlos verwartet, sondern ist 
einfach die Zeit, die bis zum nächsten Timerinterrupt
vergeht.
Dein Mainprogramm kann in dieser Zeit alles mögliche andere machen.


Auch, wenn eine Software auf einer Billion Geräte läuft, ist das nicht 
der geringste Beweis ihrer Fehlerfreiheit.


Peter

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde zum Entprellen einfach mit jedem Timer-Interrupt die 
Ports überprüfen und einen gleitenden Mittelwert bilden (z. B. x = 2.0*x 
+ (P1 & X) * 0.333333333). Wenn der größer als 0,5 ist, dann wird der 
Wert 1 genommen und ansonsten 0. Es ist dann ein Tiefpass mit 
nachgeschaltetem Schmitt-Trigger (ohne Hysterese) in Software.
Damit braucht man keine Interrupts und es müsste nur regelmäßig der 
Zustand der Tasten abgefragt werden.

Was meinen denn die Experten dazu?

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Korrektur, ich meine natürlich

x = 2.0*x + (float)(P1 & X);
x *= 0.3333333333;

Minimal wäre

x += (float)(P1 & X);
x *= 0.5;

und allgemein wäre es

x = (n-1)*x + (float)(P1 & X);
x /= (float)n;

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FLOAT zur Tastenentprellung??? Das ist völlig unnötige Speicher- und 
Rechenzeitverschwendung.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"... mit jedem Timer-Interrupt ... braucht man keine Interrupts ..."

Also was denn nun ?


Da muß ich Andreas recht geben, das ist mit Abstand die umständlichste 
aller Methoden.


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

natürlich. Was den sonst? Warum sollte ein einziges Bit in einem 
Register genügen wenn mans mit float machen kann. Warum denn nicht 
gleich mit double? Das passiert wenn der übliche PC-Hobby-Hacker auf µC 
umsteigt. Einem PC mag es nichts ausmachen wenn er mal ein paar 
float-Zahlen berechnen muß. Der macht das in Hardware und Speicher ist 
eh genug da. Ein µC braucht aber diverse Routinen die float per Software 
nachbilden was Flash, RAM und Geschwindigkeit kostet.

Deswegen gilt auf µC (8-Bitter):
Verwende kein float.
Wenn du doch float brauchst denk dir einen anderen Algorithmus aus.
Wenns garnicht anders geht rechne mit deutlich höherem Speicherverbrauch 
und beschwer dich nicht über langsame Programmausführung und knappes 
Flash.

Matthias

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also einen Timer-Interrupt hat man doch zu 99,9 % sowieso; den braucht 
man nicht extra!
Für die Ports kann man die Interrupts einsparen.

Und ein Float pro Taster-Eingang ist doch nicht viel, außer man hat nur 
128 Byte RAM (statt den üblichen 2 kB).
Und wenn bei den üblichen 10 Mips noch das letzte Quentchen CPU-Zeit 
rausgequetscht werden muss, kann man das ganze auch in int realisieren. 
Mit dem Hardware-Multiplier ist es dann in jedem Fall schnell genug, 
weil nur Additionen u. Multiplikationen nötig sind.
Wichtig ist doch, dass es fehlertolerant funktioniert, keine CPU-Zeit 
mit busy wating verschwendet und fast immer problemlos realisierbar ist!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn es unbedingt sein muß, kannst Du auch float nehmen.

Allerdings bringt das keinerlei Vorteile in jeder Hinsicht.

Und so, wie Du es beschrieben hast, entprellst Du auch nicht richtig.
Du müßtest noch hinter Deinen Tiefpaß einen Schmitt-Trigger setzen, z.B. 
mit den Schwellen 0,25 und 0,75 sonst ist in der Nähe von 0,5 trotzdem 
ein Prellen möglich.

Einen Schmitt Trigger ohne Hysterese gibt es nicht, die Hysterese ist ja 
gerade der Sinn eines Schmitt Triggers. Sie soll nämlich das Schwingen 
in der Nähe des Schwellwertes verhindern.


Die üblichen Entprellbeispiele arbeiten aber viel viel einfacher:

Sie zählen nur, wie oft hintereinander Nullen bzw. Einsen auftreten, und 
wenn der Zähler z.B. bei 4 anlangt, d.h. 4 Einsen hintereinander gelesen 
wurden, dann wird dieser Eins-Zustand übernommen und man zählt dann 
wieder 4 aufeinaderfolgende Nullen usw.


Das Codebeispiel von mir macht das z.B. gleichzeitig für bis zu 8 Tasten 
und merkt sich auch den Übergang einer Taste von
Losgelassen zu gedrückt.



Peter

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dein Algorithmus verwendet aber auch einen gleitenden Mittelwert 
(mit einer Theta-Funktion).
Bei meinem hat der Schmitt-Trigger eine infenitesimale Hysterese, damit 
es keinen verbotenen Bereich gibt (den es in der boolschen Algebra nicht 
gibt), aber das kann man natürlich ausbauen und z. B. mit einer 
dreiwertigen Logik rechnen oder auch eine Hysterese einbauen.

Jedenfalls kann man bei meinem Algorithmus über die Zeitkonstante des 
exponentiell gleitenden Mittelwert ganz gut zwischen häufigen 
Tastendrücken und Prellern unterscheiden, wenn die deutlich 
unterchiedliche Zeitdauern haben.
Mit einer Zeitkonstante von rund 100 ms sollte es sehr gut 
funktionieren.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

du kannst Tasten auch mit Differenzialgleichungen entprellen. Ist nur 
die Frage ob das sinnvoll ist. Float-Berechnungen (Addition und 
Multiplikation) kosten beim AVRGCC etwa 3,2k Code. für einen Mega8 ist 
das ne Menge.
Ich verwende pro Taste im Allgemeinen 4 Bit.
2 Bit zur Entprellung im Timer-INT

2 Bit zur Zustandsanzeige
0: Taste nicht gedrückt aber abgefragt (vom Hauptprogramm)
1: Taste gedrückt aber noch nicht abgefragt
2: Taste gedrückt und abgefragt
3: Taste nicht gedrückt aber noch nicht abgefragt

Macht pro zwei Tasten 1 Byte. Bei 16-Tasten sind das 8 Byte. Bei deiner 
Methode brauchst du pro Taste ein float (4 Byte) sprich 64 Byte für 16 
Tasten.

Matthias

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also da ist einiges übertrieben. Float hat nur 32 Bit und nicht 64.
Und zum Entprellen reicht das ganze mit 16-Bit-Integer und wem das noch 
zu viel ist, der kann 8-Bit-Integer nehmen.
Bei einem MC mit Hardware-Multiplikator macht die eine Multiplkation u. 
Addition pro Taster nicht viel aus.

Hm, vielleicht sollte ich das Verfahren patentieren lassen ...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte nenne einen einzigen Vorteil den das Verfahren in der Praxis hat.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Selbst-Zitat:
pro Taste ein float (4 Byte)

Zitat Rolf F.
Float hat nur 32 Bit und nicht 64.

Und wieviel Bit hat nochmal ein Byte?

Matthias

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Byte hat 8 Bit und weil pro Taster im worst case nur ein Float 
benötigt wird braucht man nur 32 Bit pro Taster (im best case sind es 
nur 8); ganz einfach.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

was genau 64 Byte für 16 Taster bedeutet. Und nichts anderes habe ich 
heute morgen um 9.18 geschrieben.

Matthias

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Aber bei 60 kB Flash u. 2 kB RAM macht das nicht viel aus.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"vielleicht sollte ich das Verfahren patentieren lassen"

Etwas patentieren, was keinerlei Vorteile hat klingt ziemlich unsinnig. 
Aber keiner hindert Dich daran.


Ich denke auch, daß 4 Bit je Taste zum Entprellen und Flanke erkennen 
vollkommen ausreichend sind.

Zumal mein Code außerdem noch extrem fix ist (10 Zyklen, das C-Beispiel 
braucht ein kleines bischen mehr).

Bei mehr als 8 Tasten nehme ich einen anderen Code, da man diese dann 
doch besser als Matrix verschaltet.

Hatte ihn schon mal in 8052.com gepostet (für 3*8=24 Tasten).


Peter

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, das war eigentlich sarkastisch gemein, das mit dem Patent (obwohl 
ich das in USA problemlos patentiert bekäme).

Und wo findet man denn die Code-Beispiele mit den paar Bits?

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.