Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
extrene_interrupts_mit_dem_mystm32_light [2020/06/04 16:39] – [Videozusammenfassung] huwiextrene_interrupts_mit_dem_mystm32_light [2020/06/04 17:08] (aktuell) – [Weiter mit:] huwi
Zeile 1: Zeile 1:
 ====== 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. 
  
Zeile 106: Zeile 107:
   * [[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 ======