mikrocontroller.net

Forum: Compiler & IDEs Hilfe bei XRam


Autor: Sascha Str (sascha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Str (sascha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Wiemken (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Str (sascha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sascha Str (sascha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Sascha Str (sascha)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sascha Str (sascha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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 :(

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Sascha Str (sascha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: Sascha Str (sascha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.