Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
extrene_interrupts_mit_dem_mystm32_light [2020/06/04 16:39] – [Videozusammenfassung] huwi | extrene_interrupts_mit_dem_mystm32_light [2020/06/04 17:08] (aktuell) – [Weiter mit:] huwi |
---|
====== Externe Interrupts auswerten ====== | ====== Externe Interrupts auswerten ====== |
| {{tag>LED TOGGLE INT INTERRUPT}} |
In der vorausgegangenen Übung haben wir einen Timer als internen Trigger genutzt. Bei eingebetteten Systemen ist kommt externen Auslösern jedoch mindest die selbe Bedeutung zu wie die Nutzung von Timern. Beispiele lassen sich endlos aufzählen, in einem Auto finden wir Schalter als Auslöser für Systemaktionen an allen Türen, der Heck- oder Kofferaumklappe, den Sicherheitsgurten, dem Beleuchtungssystem, Fensterheber, jede Menge Schalter für den Fahrer im Cockpitbereich und am Lenkrad usw. usw. All diese Schaltelemente schalten längst nicht mehr plump irgendetwas ein oder aus. Die Signale von diesen Systembausteinen werden von Mikrocontrollern verarbeitet. Das könnte man natürlich durch ständiges Abfragen (polling) der Schalter tun. Bei der großen Anzahl von auszuwertenden Signalen kann das doch schon erheblich Rechenzeit fressen die dann für andere Aufgaben nicht zur Verfügung steht. Damit kommt dem erkennen von Änderungen (steigende oder fallende Flanken) an den Signaleingängen und dem Auslösen und Verarbeiten von Hardware-Ereignissen also Interrupts große Bedeutung zu, denn ereignisorientierte Verarbeitung verbraucht signifikant weniger Rechenzeit und kann zusätzlich noch viel besser Prioritäten der Signal beachten. | In der vorausgegangenen Übung haben wir einen Timer als internen Trigger genutzt. Bei eingebetteten Systemen ist kommt externen Auslösern jedoch mindest die selbe Bedeutung zu wie die Nutzung von Timern. Beispiele lassen sich endlos aufzählen, in einem Auto finden wir Schalter als Auslöser für Systemaktionen an allen Türen, der Heck- oder Kofferaumklappe, den Sicherheitsgurten, dem Beleuchtungssystem, Fensterheber, jede Menge Schalter für den Fahrer im Cockpitbereich und am Lenkrad usw. usw. All diese Schaltelemente schalten längst nicht mehr plump irgendetwas ein oder aus. Die Signale von diesen Systembausteinen werden von Mikrocontrollern verarbeitet. Das könnte man natürlich durch ständiges Abfragen (polling) der Schalter tun. Bei der großen Anzahl von auszuwertenden Signalen kann das doch schon erheblich Rechenzeit fressen die dann für andere Aufgaben nicht zur Verfügung steht. Damit kommt dem erkennen von Änderungen (steigende oder fallende Flanken) an den Signaleingängen und dem Auslösen und Verarbeiten von Hardware-Ereignissen also Interrupts große Bedeutung zu, denn ereignisorientierte Verarbeitung verbraucht signifikant weniger Rechenzeit und kann zusätzlich noch viel besser Prioritäten der Signal beachten. |
| |
* [[light all in one|alles bisherige in einem Beispiel zusammengefasst]] oder | * [[light all in one|alles bisherige in einem Beispiel zusammengefasst]] oder |
* [[ein kleines Projekt mit dem mySTM32 light]] <sub>(erfordert eine SiSy Lizenz ab Version 3.7x)</sub> | * [[ein kleines Projekt mit dem mySTM32 light]] <sub>(erfordert eine SiSy Lizenz ab Version 3.7x)</sub> |
| |
| ====== Suchbegriffe ====== |