Hallo Zusammen,
ich stecke etwas in Schwierigkeiten ;-)
Ich habe ein LCD welche schon in eine Schaltung eigendlich Funktioniert.
Jetzt will ich einen Quarz zusätlich anlöten(weil ich genaue Zeit
brauche), allerdings sitzt dieser LCD mit den 8 Pins am gesammten PORTB.
Somit sind die Pins des ATmega8 für den Quarz schon belegt ;-(
Ich möchte eigendlich nur per Software die Oberen zwei Pins
(PINB7,PINB6)
frei bekommen und den PORTD (PIND1,DIND0) zuweisen.
also:
LCD_DDR = DDRB0, DDRB1, DDRB2, DDRB3, DDRB4, DDRB5, DDRD0, DDRD1
LCD_PORT = PORTB0, PORTB1, PORTB2, PORTB3, PORTB4, PORTB5, PORTD0,
PORTD1
LCD_PIN = PINB0, PINB1, PINB2, PINB3, PINB4, PINB5, PIND0, PIND1
Ich hoffe dass ist anschaulich erklärt...
Wie kann man denn so was C-technisch programmieren?
Könnt ihr mich da bitte etwas unterstützen?
Herzlichen dank
Khan
Ach ja alle anderen Ports sind auch belegt...
Es fehlen die Angaben zum LCD und den Steuerleitungen.
Die Kristallkugel sagt: Wo 8-Bit-Bus geht sollte auch
4-Bit-Bus gehen.
Also schau mal in dein Datenblatt.
avr
;-) Kristalkugel :-)
LCD ist schon in 4-Bit Modus betrieben.
An den beiden genannten Pins sind OC1 und OC0 angeschlossen...
Ich habe es deshalb nicht den LCD-Daten angegeben weil dies mehr ATmega8
betrifft.
grüße
Khan
Vielen dank,
richtig so kann ich es machen, allerdings gibt es noch eine Möglichkeit
dass ich nur mit einer Varieble x die 5pins von PORTB und die 2Pins von
PORTD ansteuern kann....
Denn dadurch muss ich nicht soviel Kode ändern....
Grüße und Dank
Khan
> könnte mir das Jemand Bitte erklären ?
So etwas nennt man einen 'Include Guard' also einen "Einschluss Wächter"
Er verhindert, dass ein und dasselbe include File in einer Compilation
Unit (gemeinhin ein einzelnes *.c File) mehrfach includiert wird.
D.h. er wird schon mehrfach includiert, aber der Compiler sieht den
Inhalt nur ein einziges mal.
Natürlich wird jetzt niemand hergehen und schreiben
1
#include"a.h"
2
#include"a.h"
3
#include"a.h"
4
#include"a.h"
5
#include"b.h"
das wäre unsinnig. Aber trotzdem kann es auf Umwegen schon einmal
vorkommen, dass ein Include File mehrfach indirekt includiert wird
zb.
File basis.h
************
1
// Basis.h
2
// Datei enthält irgendwelche Basisdefinitionen die
3
// überall gebraucht werden
4
//
File uart.h
***********
1
#include"basis.h"
2
// uart spezifische Dinge, die aber auch
3
// ein paar Dinge aus basis.h benötigen
4
//
File lcd.h
**********
1
#include"basis.h"
2
// lcd spezifische Dinge, die aber auch
3
// ein paar Dinge aus basis.h benötigen
4
//
Und dann gibt es natürlich noch das main.c, welches zb eine uart und ein
lcd gemeinsam einsetzen möchte
File main.c
***********
1
#include"uart.h"
2
#include"lcd.h"
3
4
.....
Nachdem sich der Präprozessor die main.c vorgenommen und alle #include
aufgelöst hat, geht dieser Quelltext zum eigentlichen C-Compiler
1
// Basis.h
2
// Datei enthält irgendwelche Basisdefinitionen die
3
// überall gebraucht werden
4
//
5
// uart spezifische Dinge, die aber auch
6
// ein paar Dinge aus basis.h benötigen
7
//
8
// Basis.h
9
// Datei enthält irgendwelche Basisdefinitionen die
10
// überall gebraucht werden
11
//
12
// lcd spezifische Dinge, die aber auch
13
// ein paar Dinge aus basis.h benötigen
14
//
15
16
.....
Und wie man sieht, ist der Inhalt von basis.h jetzt zweimal in dieser
Zwischenstufe vorhanden.
Der include Guard verhindert das.
1
#ifndef BASIS_H
2
#define BASIS_H
3
// Basis.h
4
// Datei enthält irgendwelche Basisdefinitionen die
5
// überall gebraucht werden
6
#endif
Wenn der Präprozessor die build.h das erste mal hereinzieht, dann
existiert das Makro BASIS_H nicht, alles was nach dem #ifndef kommt wird
also in den entstehenden Quelltext mit übernommen. Aber genau dadurch
wird in Folge das Makro BASIS_H definiert. Wird das zweite mal versucht
basis.h zu includieren, existiert das Makro dann schon, und alles
zwischen dem #ifndef und dem zugehörigen #endif wird vom Präprozessor
nicht in den entstehenden Quelltext übernommen. Fazit: Der Inhalt von
basis.h wird nur einmal vom Prärpozessor in die Zwischenstufe eingebaut
die dann zum Compiler geht.
Und das war der ganze Sinn der Übung.
Khan schrieb:
> Vielen dank,>> richtig so kann ich es machen, allerdings gibt es noch eine Möglichkeit> dass ich nur mit einer Varieble x die 5pins von PORTB und die 2Pins von> PORTD ansteuern kann....>> Denn dadurch muss ich nicht soviel Kode ändern....
Wenn dein Code so unflexibel ist, dass er sich nicht darauf anpassen
lässt, zumindest die LCD Steuerleitungen frei auf Port Pinzuordnung
anzupassen, dann ist es sowieso besser, du überarbeitest ihn.
Die 4 Datenleitungen kann man beieinander lassen, das artet tatsächlich
in eine Codeschlacht aus, aber die Steuerleitungen so in den Code
einzuweben, dass man sie mit ein paar #define einfach auf beliebige Port
Pins verteilen kann, ist eine simple Übung.
Fang damit an, dass du dir für die 4 Steuerleitungen gleichwertige Port
Definitionen #define erzeugst, wie hier
1
#define LCD_DATA_DDR DDRB
2
#define LCD_DATA_PORT PORTB
3
#deinfe LCD_DATA_PIN PINB
4
5
#define LCD_EX_DDR DDRB
6
#define LCD_EX_PORT PORTB
7
#define LCD_EX_PIN PINB
8
9
#define LCD_RW_DDR DDRB
10
#define LCD_RW_PORT PORTB
11
#define LCD_RW_PIN PINB
12
13
#define LCD_OC1_DDR DDRB
14
#define LCD_OC1_PORT PORTB
15
#define LCD_OC1_PIN PINB
16
17
#define LCD_OC2_DDR DDRB
18
#define LCD_OC2_PORT PORTB
19
#define LCD_OC2_PIN PINB
Und dann gehst du deinen Code durch und ersetzt dein bisher einziges
LCD_DDR, LCD_PORT, PCD_PIN durch die jeweils benötigten neuen #define
Wenn der Rest halbwegs sauber geschrieben ist, sollte das dann schon
fast die komplette Änderung sein.
Hallo Karl heinz Buchegger,
ich glaub du hast Recht!
Ich sollte mich einmal hinsetzten und diesen Kode einfür allemal
flexibel gestalten...Beim nächsten einsatz habe ich wieder dass gleiche
Problem wahrscheinlich....
Grüße
Khan
Karl heinz Buchegger schrieb:
> Die 4 Datenleitungen kann man beieinander lassen, das artet tatsächlich> in eine Codeschlacht aus
Na na, übertreib mal nicht so.
Das sind nur 4 * CBI, SBRC, SBI, also 12 Befehle.
Das merkst Du garnicht, aber gewinnst die absolute Flexibilität.
Peter
Peter Dannegger schrieb:
> Karl heinz Buchegger schrieb:>> Die 4 Datenleitungen kann man beieinander lassen, das artet tatsächlich>> in eine Codeschlacht aus>> Na na, übertreib mal nicht so.
Du hast recht. Ich hätte es anders formulieren sollen.
Wo ich ihn hinbringen wollte: In einem ersten Schritt ist es sicherlich
ausreichend, wenn er sich die Steuerleitungen frei konfigurierbar macht.
Das ist eine Sache auf ein paar Minuten und wird in vielen Fällen
ausreichen, da ja deren Ansteuerung sowieso schon auf Einzelbitebene
realsiert ist. D.h. am vorhandenen Code ändert sich funktional so gut
wie nichts, ein paar #define kommen dazu und werden im vorhandenen Code
verwendet. Und das wars dann schon.
Thread beobachten
Seitenaufteilung abschalten