Hi, nachdem ich mir jetzt die Nächte um die Ohren gehauen hab: sobald ich mit : EXTMEMOPTS = -Wl,--section-start=.noinit=0x802000 die Startadresse verändere wird printf vollständig ignoriert. (printf soll daten aus dem ext. ram senden) Nehm ich extmomopts wieder raus , geht wieder alles. Das Datenarray ist mit Sicherheit so groß , dass es in den ext. RAM hineinreicht. So oder so wird von "extern" gelesen. Ich kann in jedem Fall die Daten holen und versenden. aber mit printf NUR wenn EXTMEMOPTS = -Wl,--section-start=.noinit=0x802000 nicht an ist. Hab ich was überlesen , verpasst , vergessen ??? Ciao Uwe
(Die Frage gehört wohl besser ins GCC-Forum.) Ohne die exakten Details ist da kaum eine Aussage möglich. Versuch' doch mal, den Fehler auf das Minimum runterzubrechen, das man zum Nachvollziehen des Fehlers benötigt. (Vermutlich wird's Dir dann sowieso wie Schuppen aus den Haaren fallen. ;-)
Wir sind bereits magisch ins GCC-Forum umgezogen worden. ;-) Hat wohl der Webmaster getan...
Hi, also da ist irgendwo der Wurm so dermaßen drin, dass ich es nicht finde. Ursprünglich war der Code viel viel größer, aber schon diese rudimentären Dinge funktionieren nicht. Also eine Urache ist irgendwie in .noinit: Sobald ich .noinit mit einer neuen Startadresse versehe kommt vom ext. RAM nur noch ne hochlaufende Zahl. Könnte auch der Pointer innerhalb des Arrays sein. (Aber warum sollte es ?) Zum zweiten: Sobald ich auch nur ansatzweise Text in printf mit übergebe außer den formatstrings und Argumenten , geht garnichts mehr, dann wird die kompl. Anweisung "ignoriert". Makefile ist dabei ansonsten ist da ja nichts dran. Vielleicht kann mir ja jemand mal vor´s Hirn hauen. Danke
Eins fällt mir auf, wenn ich auf die Symboltabelle gucke (avr-nm -n smarttest.elf): 00800110 B __iob 00800116 B __brkval 00800118 B __flp 0080011a B __bss_end [Ende des internen RAM] 00802000 B la 00802fa0 B __heap_start ... Hmm, Dein Heap landet auf dem externen RAM (ein Seiteneffekt davon, daß Du .noinit verschiebst). fdevopen() und floating point vfprintf() benutzen beide malloc(), brauchen also den Heap. Bist Du Dir denn sicher, daß Dein externer RAM funktioniert? Kannst ja mal den Heap nach intern verlegen. Genaue Syntax habe ich nicht im Kopf, aber im Kapitel über malloc() in der Doku niedergeschrieben. ;-)
Also der ext. Ram funktioniert höchstwarscheinlich. Ich hab mal ein Array mit 10000Werten angelegt. konnte alle Werte wieder zurücklesen. Deswegen im Code die 3Zeilen zum extern lesen. Wobei das jetzt auch nicht mehr geht.... zuviel durcheinanderverändert. Den Heap werd ich mal nach intern verschieben. Könnte schon ein Ansatz sein. Ich hatte erst den Verdacht, das die Auswertung der Formatstrings irgendwie den Fehler verursacht, hat sich aber noch nicht bestätigt. Bis später Uwe
Hab jetzt selber mal nachgeschaut: 000010ff W __stack 00800100 D __data_start 00800100 D __malloc_margin 00800102 D __malloc_heap_start <- was ist das denn ? 00800104 D __malloc_heap_end 00800106 B __bss_start 00800106 D __data_end 00800106 D _edata 00800106 b brkval 00800108 b flp 0080010a B br 0080010c B __iob 00800112 B __bss_end 00800112 B la 00804f32 B __heap_start 00804f32 B _end 00810000 ? __eeprom_end auf jeden Fall bekommen ich bei: EXTMEMOPTS = -Wl,--section-start=.noinit=0x802000 ,-Wl,--defsym=__malloc_heap_start=0x800400,--defsym=__malloc_heap_end=0x 800600 Linking: smarttest.elf avr-gcc -mmcu=atmega128 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=smarttest.o -std=gnu99 -Wp,-M,-MP,-MT,smarttest.o,-MF,.dep/smarttest.elf.d smarttest.o --output smarttest.elf -Wl,-Map=smarttest.map,--cref -Wl,--section-start=.noinit=0x802000 ,-Wl,--defsym=__malloc_heap_start=0x800400,--defsym=__malloc_heap_end=0x 800600 -lm avr-gcc: ,-Wl,--defsym=__malloc_heap_start=0x800400,--defsym=__malloc_heap_end=0x 800600: No such file or directory C:\winavr\utils\bin\make: *** [smarttest.elf] Error 1 langsam wird das nervig. Ciao Uwe
-Wl leitet für den C-Compiler eine Option ein, bei der er den Rest an den Linker weitergibt. In diesem Rest sollte nicht nochmal -Wl drin sein. ;-) Am besten eine separate -Wl,dies,jenes für jede Linkeroption.
Och nö , oder ;-) die Fehlermeldung ist wech.. Mittlerweile kann ich auch ohne Probleme printf benutzen. hab jetzt _malloc_heap_ und __heap nach "intern" verlegt. Scheint zu helfen. Allerdings scheint doch noch ein temporärer HW-Fehler da zu sein. Sieht nach ner Knobelaufgabe aus. So wie früher in der Lehre: welche Ltg sind wohin kurzgeschlossen, damit dieser Fehler auftritt.... Ist eben doch sch.... wenn man schnell ne Adapterplatine baut und noch eine dazu usw... irgendwann ist mal schluss Ich danke Dir erstmal für die Tipps mit dem Heap. Hab auch an sowas gedacht.. wär aber nieeee auf die Idee gekommen den Heap zu verschieben. Falls ich nicht weiterkomme , bin ich wieder hier zum betteln ;-) Ciao Uwe
Hi, wollte nur nochmal den Endstand melden, vielleicht haben ja andere auch mal so ein Problem. Falls der ext. SRAM keinen Schaden durch einen kaputten octal-Latch erlitten hat.... ;-) sollte es kein Problem geben , außer man lässt den heap_ und _malloc_heap extern. Dann tauchen zuweilen Probleme mit "Anwendungen" , die malloc()(z.B. printf) benutzen, auf. Welche, wann usw. keine Ahnung . Aber danke mal an alle für die Hilfe. Uwe
Das kann ich so allgemein nicht stehen lassen: ich habe malloc() sehr wohl ausgiebig auch mit externem Speicher getestet. Selbstverständlich funktioniert das alles auch damit. Wenn Du damit ein Problem hast, solltest Du es wohl besser analysieren.
Auf sowas in der Art hab ich ja schon gewartet. :-) Darauf kannst Du dich verlassen, das finde ich schon raus, woran das liegt. Uwe
:-) Bist Du Dir sicher, daß Dein address latch schnell genug ist? Vor allem bei höheren Taktfrequenzen am ATmega128 sind die timing-Forderungen recht knapp bemessen. Hast Du mal probiert, ob sich die Situation bessert, wenn Du mit wait states arbeitest?
Hi. hatte anfangs den Verdacht, dass das Timing kritisch ist. Lt. Datenblättern bin ich im grünen Bereich, zumal ich eh nur mit 8Mhz arbeite, weil das Grafikdisplay sonst am Limit ist und ich dann dort überall Waitstates gebraucht hätte. Trotzdem hab ich mal welche im Speicher-timing gesetzt aber es ist nicht besser geworden. War auch unwahrscheinlich weil ja die "richtigen" Daten sauber rüberkommen. Ich bleib aber mal dran. Uwe
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.