Hi,
ich krame gerade in einer fleury Lib rum und frage mich wie das
funktioniert:
#define LCD_PORT PORTA /**< port for the LCD lines */
#define LCD_DATA0_PORT LCD_PORT /**< port for 4bit data bit 0 */
#define LCD_DATA1_PORT LCD_PORT /**< port for 4bit data bit 1 */
#define LCD_DATA2_PORT LCD_PORT /**< port for 4bit data bit 2 */
#define LCD_DATA3_PORT LCD_PORT /**< port for 4bit data bit 3 */
#define LCD_DATA0_PIN 0 /**< pin for 4bit data bit 0 */
#define LCD_DATA1_PIN 1 /**< pin for 4bit data bit 1 */
#define LCD_DATA2_PIN 2 /**< pin for 4bit data bit 2 */
#define LCD_DATA3_PIN 3 /**< pin for 4bit data bit 3 */
DDR(LCD_DATA0_PORT) |= _BV(LCD_DATA0_PIN);
DDR(LCD_DATA1_PORT) |= _BV(LCD_DATA1_PIN);
DDR(LCD_DATA2_PORT) |= _BV(LCD_DATA2_PIN);
DDR(LCD_DATA3_PORT) |= _BV(LCD_DATA3_PIN);
Konkret geht es mir um diesen Ausdruck:
DDR(LCD_DATA0_PORT)
Wird daraus nicht:
DDR(PORTA)?
und müsste es dann nicht DDRA heißen?
Man, ich sehe es gerade:
#define DDR(x) (*(&x - 1)) /* address of data direction register of
port x */
So eine Sau, man defines lassen aber auch jede Sauerei zu...
Schön ist das nicht, warum macht man soetwas???
Maddin
Hallo, Damit macht man den Code besser auf andere Systeme anwendbar. Beispiel: Du hast jetzt diesen Code, die PortPins sind aber schon belegt. Währen diese defines nicht verwendet worden müsstest du jetzt die gesamte Lib abklappern. So änderst du nur die defines. Gruß Jannis
Na da wollte sich wohl jemand Schreibarbeit ersparen... Um quasi indirekt über den Port out auf den dazugehörigen Port in mithilfe Adressenmanipulation zuzugreifen sieht... ungewöhnlich aus. Würde ich nicht machen. Der Assembler-Code bzgl. der Performance wäre interessant...
Hallo Jannis, danke für deine Antwort, aber hier ging es mir um etwas Spezielles mit den Defines. Das Makro DDR(x) zieht von der Adresse des PORTA (in diesem Fall - PORTA wird ja später durch die entsprechende Adresskonstante ersetzt) eine Konstante (-1) ab. Damit greift man über die Angabe PORTA mehr oder minder indirekt auf die Adresse des entsprechenden DDRs zu. Ich habe das jetzt nochmal durchgesehen, das geht sogar soweit dass die unterscheidlichen Porzessortypen bei diesem Umgang mit den Defines nochmal berücksiochtigt werden müssen, denn allem Anschein nach liegt das DDR nicht bei jedem Typen eine Adresse vor dem PORT Register... Mir erschließt sich absolut nicht warum man eine solche "Krücke" nutzt an der Stelle. Ich als Nutzer der Lib suche nun das DDR und finde es nicht direkt... Naja, ich jedenfalls mache immer defines für: INPUT REG PIN OUTPUT REG PORT DIREKTION REG DDR PINNUMMER X für jeden Pin der in einer LIB genutzt wird. Das erzeugt bei einem 8 Bit Datenbus ggf. Overhead, aber so sieht man gleich was Sache ist. M.
@ Coder, auf die Performance dürfte das keinen Enfluss haben, denn es kommt ja am ende der selbe code raus, oder etwa nicht? Höchstens auf die Performance des "Code-Verstehers"... :-) Die Defines PORTA usw... stehen doch nur stellvertretend für Adressen, das ganze Zeug wird doch eh vorher ausgerechnet und fließt nur als Konstante in den ASM ein, und ob ich die nun direkt hinschreibe oder umständlich vorher ausrechnen lasse... M.
Zumindest wird da derefenziert, was man bei dem direkten und einfachen Registerzugriff nicht Quellcode mäßig nicht schreibt. Ob der Code identisch ist, hängt wohl von der Gnade des Compilers ab. War auch nur so ein Gedanke... was auch immer am Ende rauskommt.
Maddin schrieb: > > Mir erschließt sich absolut nicht warum man eine solche "Krücke" nutzt > an der Stelle. Weil die Alternative zur 'Konfiguration' von #define LCD_PORT PORTA /**< port for the LCD lines */ so aussieht #define LCD_PORT PORTA /**< port for the LCD lines */ #define LCD_PIN PINA #define LCD_DDR DDRA Um den Port umzustellen musst du 3 #define ändern, was eine potentielle Fehlerquelle ergibt. Im Original gibt es diese Fehlerquelle nicht, wenn die entsprechenden DDR Makros erst einmal korrekt sind. > Ich als Nutzer der Lib suche nun das DDR und finde es nicht direkt... Du als Nutzer der 'Lib' stellst einfach beim LCD_PORT Makro deinen verwendeten Port ein und um alles andere kümmert sich der Compiler. > Das erzeugt bei einem 8 Bit Datenbus ggf. Overhead Das erzeugt überhaupt keinen Overhead. Makros sind einfach nur Textersetzungen, die gemacht werden, ehe der Compiler den Quelltext überhaupt zu Gesicht bekommt. Peter hat sich einfach nur Komfortfunktionalität eingebaut.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.