Hi, habe an meinem ATmega162 ein 32kb Ram, einen ADC0820 und ein T6963c Display angehängt. Ram liegt von 0000H-7FFFH, LCD an A000H & A001H und der A/D an C000H. Aber irgendwie kriege ich es mit Speicherinterface nicht im Griff. Wie Kann ich zum Bsp. Daten an das Display senden in GCC? Speichereinstellung: MCUCR=0x80; //64kb EMCUCR=0x00; Mfg Sascha
>Aber irgendwie kriege ich es mit Speicherinterface nicht im Griff Wo liegt dein Problem? In der Hardware oder in C einen Pointer zu erstellen der auf die Adresse der LCD Register zeigt? >Wie Kann ich zum Bsp. Daten an das Display senden in GCC? Das ist schlecht zu sagen da du nicht angibst ,worum es sich bei den LCD Registern 0xa000 und 0xa001 handelt (Command/Datenregister ,2x8 Bit Datenregister etc.)
Hardwaremäßig gibt es keine Probleme. Die Adressauflösung erfolgt mittels eines 74HCT138. Hauptproblem ist es, in C einen Pointer zu erstellen der auf die Adresse der LCD Register zeigt. Mit 0xA000 und 0xA001 schalte ich zwischen Comman/Data um. Mfg Sascha
Also Command 0xA000 /Data 0xA001 ? volatile unsigned char * CommandPtr=0x0a000; volatile unsigned char * DataPtr=0x0a001; volatile da du mit memory mapped Registern zu tun hast die sich ändern können.
Also ungefähr so #define LCD_ADR 0xA000 #define LCD_RST 0xE000 #define LCD_CMD 1 #define LCD_DATA 0 void lcd_status(void) { volatile unsigned char *base = (unsigned char *)(LCD_ADR+LCD_CMD); LCD_STATUS = *base; // Status lesen LCD_STATUS &= (0x03); // Bits ausmaskieren } Nur funktioniert nichts. Bin ratlos. Mfg Sascha
Anbei mal der Code. Die Display-Routinen funktionieren im I/O-Mode wunderbar. Nur habe ich noch niemals was am Bus eines AVR`s betrieben. Bin für jede Hilfe dankbar. Mfg Sascha
> Also ungefähr so
Nein. Nicht ungefähr so.
Wolfram hat dir schon gezeigt, wie's geht.
volatile unsigned char * CommandPtr=0x0a000;
volatile unsigned char * DataPtr=0x0a001;
void lcd_status(void)
{
unsigned char Status;
Status = *CommandPtr; // von 0xA000 nach 'Status' lesen
Status &= (0x03); // Bits ausmaskieren
}
@Karl Heinz Buchegger Damit bekomme ich die Fehlermeldung: Compiling: T6963.c avr-gcc -c -mmcu=atmega162 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=T6963.lst -std=gnu99 -MD -MP -MF .dep/T6963.o.d T6963.c -o T6963.o T6963.c:9: Warnung: Initialisierung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung T6963.c:10: Warnung: Initialisierung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung T6963.c:11: Warnung: Initialisierung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung Der Code im Anhang(Um 19:23) weiter oben wird zwar einwandfrei kompiliert, aber funktioniert leider nicht. Paßt überhaupt die einstellung für: MCUCR=0x80; //64kb EMCUCR=0x02; // oberer bereich 2 waitstats ? Weil ich stelle ja die Adreßleitungen ein, die benötigt werden? Oder habe ich das Datenblatt falsch verstanden? Mfg Sascha
OK. Der Compiler sagt dir schon wo das Problem liegt: Auf volatile unsigned char * CommandPtr=0x0a000; antwortet er mit: Initialisierung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung Was meint er damit? Auf der linken Seite des = ist der Datentyp ein Zeiger, auf der rechten Seite ist das eine ganze Zahl. Eine Zahl kann man nicht so ohne weiteres einem Pointer zuweisen. Meist ist das ein ganz einfacher Logik-Fehler. Aber nicht in diesem Fall. Wir wissen, dass das so stimmt. Daher raten wir dem Compiler mal ganz schnell den Mund zu halten und das kommentarlos zu übersetzen. Das Mittel mit dem wir das machen ist ein 'cast'. volatile unsigned char * CommandPtr = (unsigned char*)0x0a000; Jetzt zwingen wir den Compiler den rechten Teil als Pointer mit dem Wert 0xa000 aufzufassen. Damit steht links und rechts der selbe Datentyp und der Compiler ist friedlich. Aber aufpassen: cast's sind Waffen! Letztendlich kann man mit einem cast das komplette Typ-System und dessen Überwachung durch den Compiler komplett abschalten. Ein Programmierer sollte daher beim Einsatz eines cast sehr genau wissen, ob das was er tut auch tatsaechlich richtig ist.
Um's ganz korrekt zu machen, sollte der cast auch den gleichen Qualifier wie der Zieltyp haben, also (volatile unsigned char *) Ist in diesem Falle aber eher theoretischer Natur.
Hallo, so, das Display funktioniert, freu. Danke erstmal. Man sollte sich auch auch nicht mit der Adressleitung A0 (High/Low-Pegel) vertuen. Mal aber noch ne Frage zu dem Ram (32kb), das ich dazu noch verwenden will. Es gibt ja die möglichkeit, im Makefile dem Compiler mitzuteilen, das er das Ram für Heap und Variablen nutzen kann. Gibt es ne Möglichkeit, festzustellen, welches Ram er dann jeweils benutzt? Mfg Sascha
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.