Hallo,
nachdem ja mein Display erfolgreich am Datenbus des ATMega162 läuft,
wollte ich jetzt das SRam (32kb) benutzen.
Im Makefile ist eingetragen:
EXTMEMOPTS =
-Wl,--section-start,.data=0x800500,--defsym=__heap_end=0x8084ff
Im Source ist eingetragen:
void init_memory_mapped (void) _attribute_ ((naked)) _attribute_
((section (".init1")));
void init_memory_mapped(void)
{
MCUCR |= (1<<SRE)|(1<<SRW10);
EMCUCR |= (1<<SRW00);
}
Nur läuft nach diesem Eintrag das Programm gar nicht mehr. Woran kann
es liegen?
Kann der GCC den ext. Speicher so selber verwalten, das eine Variable
wie z.B. unsigned int test; das diese im ext. Ram liegt?
Mfg Sascha
Hi, also mit der Zeile: EXTMEMOPTS = -Wl,-Tdata=0x800500,--defsym=__heap_end=0x8084ff im Makefile, funktioniert es. Aber wie kommt es zu dieser Meldung von AVR-Size? Gibt es dafür Abhilfe??? Size after: AVR Memory Usage ---------------- Device: atmega162 Program: 7026 bytes (42.9% Full) (.text + .data + .bootloader) Data: 5164 bytes (504.3% Full) << (.data + .bss + .noinit) Mfg Sascha
abo Hallo Sascha, genauso wie Du habe ich auch einige Verständnissprobleme mit dem externen Speicher. Ich selber benutze zwar den ATmega128 jedoch sollte es vom Aufbau her gleich sein. In meinem Programm habe ich es ebenfalls mit der von dir beschriebenen Methode versucht, was mit dem Ergebnis eines nicht lauffähigen Programms belohnt wurde. Erst nach der Änderung der EXTMEMOPTS konnte das Programm schon mal gestartet werden. Was sagen die Parameter bei den EXTMEMOPTS genau aus? Soweit ich es verstanden habe, gibt es die Möglichkeit den XRAM als reinen HEAP zu nutzen, oder auch Variablendeklaration im externen Speicher zu erlauben. Wann ist was eingestellt? Ich finde, dass es hierzu mal Zeit wird einen ausführlichen Artikel zu schreiben, der die ganze Sache mit den exteren Speicher beschreibt. Es gibt zwar genügend Einträge zu dem Thema in den Foren, jedoch immer nur Bruchstücke die oft mit den Satz "es klappt" beendet werden. Aber was gemacht wurde, damit dieses klappt wird dann nicht beschrieben. Ich hoffe das ein GCC oder µC Guru dieses mal liest und eventuell mal Lust hätte dazu einen Artikel zu schreiben. Es wäre z.B. Gruß und Freude Beholder
Da stimme ich dir voll zu. Mein Problem ist immer noch nicht gelöst. Bin schon langsam am verzweifeln. Per google ist auch nicht viel zu finden. Mfg Sascha
Wo liegen die Verständnisprobleme ? Habt ihr die Dokumentation der avrlibc und die Datenblätter der MC gelesen und verstanden? Besonders durch den Einsatz von MFile lassen sich fehlerhafte Befehle im Makefile vermeiden. Aber ein gewisses Grundwissen an Hardwarekenntnissen (Anbindung RAM) und Wissen über die Arbeitsweise eines C-Compilers UND des dazugehörigen Linkers muss man schon haben. Solche Sachen findet man gewöhnlich nicht bei Google sondern in Büchern Dokumentationen. (da war doch noch was vor dem Internet, wo Menschen Wissen gespeichert haben) Wesentlicher Vorteil (Fach)Bücher haben gewöhnlicherweise einen höheren Informations-/Wahrheitsgehalt. Ich will euch keineswegs beleidigen, ich denke nur mit diesem Thema wird die Grenze überschritten wo man einfach nur nachbaut und es geht (mehr oder weniger). Da hier eine ganze Menge Möglichkeiten bestehen, kommt man nicht darum herum es selber zu verstehen und dann in ein Forum zu gehen und die Sachen zu klären die man nicht verstanden hat. Beschreibt doch einfach mal, bei welchen Sachen ihr hängengeblieben seid. Dann kann man daran nachvollziehen ob es auf mangelnde Dokumentation oder ein mangelndes Verständnis beim Lesen der Dokumentation zurückzuführen ist. Zumindest gibt es die Chance dass ein Thread entsteht wo die Hinweise alle drin stehen. Nur so nebenbei, ein JTag leistet hervorragende Dienste, da man unmittelbar im Prozessor sehen kann OB der RAM funktioniert und was das Programm tut.
Ich will euch keineswegs beleidigen, ich denke nur mit diesem Thema wird die Grenze überschritten wo man einfach nur nachbaut und es geht (mehr oder weniger). . Also. Nachbauen will ich schon gar nichts. Das Datenblatt habe ich halbwegs verstanden. AVRLIB habe ich angeschaut. Werde nur nicht so recht schlau daraus. Nebenbei, habe ich z.B. die Routinen für das T6963c Display slebst geschrieben. und nicht nur einfach so abgekupfert. Angefangen hat das Problem im Thread: http://www.mikrocontroller.net/forum/read-2-355388.html#new Mir geht es um die Einstellungen, das der Compiler Variablen usw. im ext. SRAM legt. Mfile macht viel. Aber nehme ich die einstellung für Variablen und Heap, und 32kb SRam, startet das Programm nicht mehr. JTAG ist abgeschaltet, da da ja der Adressbus angeschloßen ist Und so nebenbei, habe ich hier im ersten Thread ja ne Frage gestellt, oder????? Mfg Sascha
Ich kenne es nur so, dass die Variablen im internen RAM liegen, und das externe RAM für den Heap verwendet wird, du also darauf nur mit malloc() zugreifen kannst.
>Werde nur nicht so recht schlau daraus. Du kannst aber immer noch nicht genau benennen wo dein Verständnisproblem liegt. Also gehen wir Schritt für Schritt vor, 1.Man braucht eine gemeinsame Diskussionsgrundlage, das wäre erstmal der Schaltplan (bitte PDF oder sowas) um die Hardwareadressdekodierung zu sehen. 2. JTAG es wäre sehr hilfreich zu wissen, das das ganze funktioniert. klemme die JTAG PINS vom Adressebus ab und benutze sie als JTAG und schau dir den Speicher an, das eliminiert evt. Fehler wie Kurzschlüsse, kalte Lötstellen etc. Zumindest den Bereich bis A10 im externen RAM kannst du damit testen. 3. Liste die Adressbereiche auf von x1 bis x2 interner RAM von y1 bis y2 externer RAM etc. ->gegencheck mit Adressdekodierung ->Optionen zum Einstellen des Speicherinterfaces 4. Welche Speicheranordnung willst du , wo liegt dein Stack ,Variablen etc. 3. und 4. ergeben die einzustellenden Linkeroptionen 5. Das C Programm ->Zugriff auf Speicher korrekt? Dies liesse sich schon im AVRStudio anhand der Speicheradressen klären. Zu deiner Frage: Data: 5164 bytes (504.3% Full) wenn du 5164/5,043 rechnest kommst du auf 1024 Byte sieht so aus als würde für die Grössenangabe der interne RAM zur Berechnung herangezogen. Höchstwahrscheinlich beachtet avr-size hier nicht die Linkereinstellungen da es sich erst im nachhinein die objectfile anschaut und wahrscheinlich nichts davon weiss. Aber da du schriebst dein Problem wäre noch nicht gelöst und der Betreff "Hilfe bei XRAM" lautet ging ich mal nicht davon aus, dass dein Problem eine falsche Angabe vom Ramverbrauch war.
Angehängte Dateien:
-
Sheet.png
14 KB
Habe mal ebebn die Verdrahtung aufgezeichnet. So ist es auf Lochraster
zusammengebaut. Mittlerweile auch mehrmals durchgemessen.
Hardware-Fehler ist ausgeschloßen. Der A/D-Wandler und das Display
funktionieren einwandfrei.
Nach Verdrahtung wären die Adressen:
0000H-7FFFH ext. SRAM
C000H ext. A/D-Wandler
A000H/A001H LCD-Display Data/Command
E000H LCD-Reset
Einstellung über Mfile ergibt:
EXTMEMOPTS =
-Wl,--section-start,.data=0x800500,--defsym=__heap_end=0x8084ff
Momentan sieht die Initialisierung im C-Code so aus:
void init_memory_mapped (void) _attribute_ ((naked)) _attribute_
((section (".init1")));
void init_memory_mapped(void)
{
MCUCR = (1<<SRE) | (1<<SRW10); // externes RAM enablen, 1
}
Ich steuere z.B den A/D-Wandler über
uint8_t *ad = (uint8_t *) 0xC000;
unsigned char read_ad(void)
{
unsigned char byte;
// AD Wandler starten
*ad = 0xff;
for (unsigned char i=0;i < 25;i++)
{
asm volatile("nop\n\t" //Kurze Pause
::);
}
// Daten einlesen
byte = *ad;
return byte;
}
Diese Methode über Pointer möchte ich mir beim SRAM sparen. Mir geht es
darum, wie ich den Compiler/Linker dazu bringe, Variablen oder Array`s
im ext. Sram zu speichern. Da liegt mein Problem drin.
Mfg Sascha
Ok. Schritt für Schritt 1.Hardware Adress dekodierung du gibst an: 0000H-7FFFH ext. SRAM C000H ext. A/D-Wandler A000H/A001H LCD-Display Data/Command E000H LCD-Reset dies ist nicht korrekt der Adress/Datenbus wird rausgeführt an Adresse 0000 (Datenbus) liegt nicht dein externer RAM da liegen die Register/IO/Ports/interner RAM evt. Auswirkungen und Vereinfachungen durch den Prozessor kommen später Gib mal die Dekodierungsfkt. an die du durch den 74hct138n erreichen willst. (dies ist genau der Grund warum es nicht einen einfachen Artikel gibt. Wende die Dekodierungsfkt. an und überprüfe welche Adressbereiche die einzelnen Bausteine haben. Ich weiss es gibt eine erste, aber über welche anderen Adressen könntest du sie auch ansprechen mit dieser Dekodierungsfkt? Überlagern sich Bereiche (dies wäre ein Fehler der Bausteine zerstört wenn Ausgänge gegeneinander treiben) zu deinen Programm: eigentlich 5. aber >uint8_t *ad = (uint8_t *) 0xC000; volatile vergessen, sowas klappt mehr oder weniger je nachdem wie schlecht der Optimierer des Compilers arbeitet. >asm volatile("nop\n\t" //Kurze Pause ::); ein memory mapped AD Wandler so ansprechen??? der hat doch bestimmt einen Readypin mit dem er signalisiert wann er fertig ist. >Diese Methode über Pointer möchte ich... Bsp. unsigned char test[80]; malloc
"Gib mal die Dekodierungsfkt. an die du durch den 74hct138n erreichen willst. (dies ist genau der Grund warum es nicht einen einfachen Artikel gibt." Der ist dafür da, das es keine Überlagerungen geben soll. Über den Sinn eines Adressdekoder`s wollten wir bestimmt nicht diskutieren. Hauptgrund liegt darin, das unter der Adresse 8000H, das Ram liegt und nicht irgendeine eine Hardware angesteuert wird. Umgekehrt halt der andere Fall, steuere ich das Display an, soll das ext. SRAM nicht beschrieben werden. Bsp. unsigned char test[80]; malloc Wie funktioniert es mit dem malloc???? Mfg Sascha PS. Mit nem 8051 und nem ext. Ram wars einfacher :(
>Der ist dafür da, das es keine Überlagerungen geben soll. Über den Sinn >eines Adressdekoder`s wollten wir bestimmt nicht diskutieren. Nein absolut nicht. Es funktioniert nur irgendetwas bei dir nicht. Was geht wohl schneller? Du gibst die Dekodierungsfkt an ,denn die hast du ja irgendwann gemacht und ich überprüfe sie oder ich schaue in den Schaltplan ordne die Sachen zu gehe ins Datenblatt .. etc. Naja lies sich anscheinend nicht umgehen. Übrigens: Die Aussage ich habe diese Adressbusanbindung am 8051 schon 100mal verwendet hätte auch gereicht. Es gibt jetzt 2 Varianten den RAM zu testen entweder mit JTAG über das Abklemmen der JTAGleitungen vom Bus oder du greifts mit Pointer auf den RAM zu und machst Lese schreib tests mit einem Programm. Das Programm dabei normal kompilieren ohne Verwendung des externen Speichers. aber den Pointer natürlich ins externe Ram zeigen lassen. >malloc ist eine Fkt. die in jedem C Buch zu finden ist.
Werde mich mich jetzt der Geschichte mit den Pointern und auch malloc widmen. Mal schauen was dabei heraus kommt. Nur iritiert mich, das ich bei Mfile mein SRAM angeben kann. Hatte gehofft, das es damit und mit der initialisierung im Code reicht. Aber dem ist ja leider nicht so. Trotzdem wären in der Hinsicht ein paar Beispiele nicht schlecht, wird dann wohl besser zu verstehen sein. Mfg Sascha
>Hatte gehofft, das es damit und mit der >initialisierung im Code reicht Eigentlich schon nur wenn es nicht funktioniert, sollte man erstmal sicher sein das der RAM funktioniert. BTW: der MEGA162 ist doch hoffentlich nicht im MEGA161 Kompatibilitätsmodus? (FUSE)
Hi, das Ram sollte funktionieren. Im 80C32 Board geht es tadellos. Habe auch zwei neue ausprobiert. An den Fuse-Bits habe ich nur die für Takt, Brown-Out und Jtag geändert. Hoffe ja mal, das der nicht im Kompatibilitätsmodus ausgeliefert wird. Unter AVR-Studio ist das Häkchen nicht dabei gesetzt. Mfg Sascha
>das Ram sollte funktionieren. Im 80C32 Board geht es tadellos. Habe >auch zwei neue ausprobiert das der RAM als Bauteil funktioniert habe ich nie bezweifelt, du must dir aber sicher sein, dass er auch am AVR funktioniert. Wie schon gesagt entweder mit JTAG testen oder mit Programm. volatile uint8_t *ad = (volatile uint8_t *) 0x500; for (ad=0x500;ad<0x800;ad++)*ad= Testwert; damit Blöcke mit einem Testwert beschreiben und wieder auslesen. Testwerte (0 und 0xff) Wenn das klappt einzelne Bytes ändern und die restlichen anschauen ob sie sich ändern. Wichtig: Programm ganz normal kompilieren als wenn kein externer RAM angeschlossen ist. (Er soll ja nicht benutzt werden um im Fehlerfall das Programm nicht zu verfälschen. Wenn dich die Warnungen stören einfach mit (volatile uint8_t *) casten
Thread beobachten
Seitenaufteilung abschaltenBitte 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.