Pins in Ethersex definieren: Unterschied zwischen den Versionen
RE: (Diskussion | Beiträge) K (→Symbolische Pinnamen) |
|||
| Zeile 1: | Zeile 1: | ||
== Symbolische Pinnamen == | == Symbolische Pinnamen == | ||
| − | Um es zu ermöglichen schnell eine Funktion von einem Pin auf einen anderen zu verlagern | + | Um es zu ermöglichen, schnell eine Funktion von einem Pin auf einen anderen zu verlagern ohne den ganzen Code zu ändern, hat Ethersex eine Abstraktionsschicht, die symbolische Namen für Pins vergibt. Die symbolischen Namen werden dann im Code verwendet. So kann ganz einfach ein anderer Pin für eine Funktion definiert werden. |
Die Pindefinitionen, pinning genannt, liegt im ethersex Projektordner unter pinning: | Die Pindefinitionen, pinning genannt, liegt im ethersex Projektordner unter pinning: | ||
| Zeile 7: | Zeile 7: | ||
{| border=1 cellspacing=0 | {| border=1 cellspacing=0 | ||
| pinning/controllers | | pinning/controllers | ||
| − | | Hier werden spezielle Pindefinitonen und die Größe des uip Buffers, die typisch sind für den Controller (z. | + | | Hier werden spezielle Pindefinitonen und die Größe des uip Buffers, die typisch sind für den Controller (z.B. atmega32), definiert. Welche Datei ausgewählt wird, hängt von der Konfiguration im menuconfig ab. |
|- | |- | ||
| pinning/hardware | | pinning/hardware | ||
| − | | Hier werden die einzelnen Pins definiert die typisch sind für die Plattform (z. | + | | Hier werden die einzelnen Pins definiert, die typisch sind für die Plattform (z.B. das pollin netio board). Vornehmlich werden hier applikationsspezifische Pins definiert. Welche Datei ausgewählt wird, hängt von dem Hardware-Profil im menuconfig ab. |
|- | |- | ||
| pinning/internals | | pinning/internals | ||
| − | | Hier kommt all der foo rein, der | + | | Hier kommt all der foo rein, der Inkompatibilitäten (z.B. von der AVR Libc) umschiffen soll. Er wird wie pinning/hardware nach dem Prozessornamen ausgewählt. Außerdem ist hier das Pin-System definiert (header.m4/footer.m4) |
|- | |- | ||
|} | |} | ||
| Zeile 27: | Zeile 27: | ||
Dem m4 wird dabei die Konfiguration mittels der Variabelen conf_BLAHFASEL (als Beispiel für das menuconfig Flag BLAHFASEL_SUPPORT) mitgeteilt. Als Beispiel, wie diese verwendet wird, einfach die Dateien unter pinning/hardware anschauen. | Dem m4 wird dabei die Konfiguration mittels der Variabelen conf_BLAHFASEL (als Beispiel für das menuconfig Flag BLAHFASEL_SUPPORT) mitgeteilt. Als Beispiel, wie diese verwendet wird, einfach die Dateien unter pinning/hardware anschauen. | ||
| − | + | Ein symbolischer Pinnamen wird mit dem Makro pin definiert ( pin($NEUER_PINNAME, $PIN) ). Ein Beispiel: | |
<pre> | <pre> | ||
| Zeile 33: | Zeile 33: | ||
</pre> | </pre> | ||
| − | Es ist auch möglich gleich im pinning den Pin als Ausgang zu definieren, damit das passende DDR Register gleich bei Start richtig gesetzt ist. | + | Es ist auch möglich, gleich im pinning den Pin als Ausgang zu definieren, damit das passende DDR Register gleich bei Start richtig gesetzt ist. |
<pre> | <pre> | ||
pin(PS2_CLOCK, PD2, OUTPUT) | pin(PS2_CLOCK, PD2, OUTPUT) | ||
Aktuelle Version vom 21. September 2009, 22:46 Uhr
Symbolische Pinnamen
Um es zu ermöglichen, schnell eine Funktion von einem Pin auf einen anderen zu verlagern ohne den ganzen Code zu ändern, hat Ethersex eine Abstraktionsschicht, die symbolische Namen für Pins vergibt. Die symbolischen Namen werden dann im Code verwendet. So kann ganz einfach ein anderer Pin für eine Funktion definiert werden.
Die Pindefinitionen, pinning genannt, liegt im ethersex Projektordner unter pinning:
| pinning/controllers | Hier werden spezielle Pindefinitonen und die Größe des uip Buffers, die typisch sind für den Controller (z.B. atmega32), definiert. Welche Datei ausgewählt wird, hängt von der Konfiguration im menuconfig ab. |
| pinning/hardware | Hier werden die einzelnen Pins definiert, die typisch sind für die Plattform (z.B. das pollin netio board). Vornehmlich werden hier applikationsspezifische Pins definiert. Welche Datei ausgewählt wird, hängt von dem Hardware-Profil im menuconfig ab. |
| pinning/internals | Hier kommt all der foo rein, der Inkompatibilitäten (z.B. von der AVR Libc) umschiffen soll. Er wird wie pinning/hardware nach dem Prozessornamen ausgewählt. Außerdem ist hier das Pin-System definiert (header.m4/footer.m4) |
Die Datei pinning.c (im Hauptverzeichnis) wird durch m4 aus den folgenden Dateien in dieser Reihenfolge generiert.
- pinning/internals/header.m4
- pinning/controllers/$(MCU).m4
- pinning/internals/hackery_$(MCU).m4
- pinning/hardware/$(HARDWARE_PROFILE).m4
- pinning/internals/footer.m4
Dem m4 wird dabei die Konfiguration mittels der Variabelen conf_BLAHFASEL (als Beispiel für das menuconfig Flag BLAHFASEL_SUPPORT) mitgeteilt. Als Beispiel, wie diese verwendet wird, einfach die Dateien unter pinning/hardware anschauen.
Ein symbolischer Pinnamen wird mit dem Makro pin definiert ( pin($NEUER_PINNAME, $PIN) ). Ein Beispiel:
pin(PS2_DATA, PD3)
Es ist auch möglich, gleich im pinning den Pin als Ausgang zu definieren, damit das passende DDR Register gleich bei Start richtig gesetzt ist.
pin(PS2_CLOCK, PD2, OUTPUT)
Auch besteht die Möglichkeit, ein Alias für einen anderen Pin zu definieren:
pin(GENERAL_HUPE, PD2) pin(MEINE_HUPE, GENERAL_HUPE)
Um die Pins dann im Code zu verwenden, sind einige Makros definiert (MEINE_HUPE durch symbolischen Pinnamen ersetzen):
| DDR_CONFIG_IN(MEINE_HUPE) | Pin wird Eingang (DDR Register) |
| DDR_CONFIG_OUT(MEINE_HUPE) | Pin wird Ausgang (DDR Register) |
| PIN_SET(MEINE_HUPE), PIN_CLEAR(MEINE_HUPE) | Pin setzen oder Löschen (PORT Register) |
| PIN_TOGGLE(MEINE_HUPE) | Ausgangszustand des Pins umkehren (PORT Register) |
| PIN_PULSE(MEINE_HUPE) | Pin zuerst löschen, dann wieder setzen (PORT Register) |
| PIN_HIGH(MEINE_HUPE) | Eingangszustand des Pins auslesen (PIN Register) |
| PIN_NR(MEINE_HUPE) | PD2 -> 2, PD6 -> 6 |
| PIN_BV(MEINE_HUPE) | PD1 -> 2, PD7 -> 128, 1 << PIN_NR(MEINE_HUPE) |
