ATMEL SAM3X8 (Arduino Due) printf auf beliebiges Device umleiten?

[Hanns-Jürgen M. (yogy)]

Hallo zusammen,

bekanntlich bin ich über den HC11 zum AVR2560 (Arduino-HW) mit Atmel 
Studio gekommen. Nun vergnüge ich mich mit dem SAM3X8 (Auf Arduino DUE 
Hardware) mit Atmel Studio 7, da ich mehr Leistung benötige, und will 
meine Routinen portieren. Ich mache da gerade meine ersten Versuche... 
sehr zäh. Timer und LED Ansteuerung habe ich laufen, auch einen Ausgabe 
über einen UART.

Ich möchte aktuell als Standardausgabe ein 4x20 LCD (über TWI 
angesteuert) verwenden, später ein TFT über SPI. Bei den AVRs ging das 
ganz einfach durch Zuweisung. Beispiel:

#if defined  LCD_OUTPUT
  FILE disp_str = FDEV_SETUP_STREAM(lcd_putchar, NULL, _FDEV_SETUP_WRITE);
#elif defined TFT_OUTPUT
  FILE disp_str = FDEV_SETUP_STREAM(TFT_putchar, NULL, _FDEV_SETUP_WRITE);
#elif defined SCI0_OUTPUT
  FILE disp_str = FDEV_SETUP_STREAM(SCI_putchar, NULL, _FDEV_SETUP_WRITE);
#endif

Nur beim SAM (ARM-gcc) geht das nicht. ich habe bei github etc gesucht 
und finde nur eine Umschaltung zwischen verschiedenen UARTs zur Ausgabe.

Ich welcher Library muß ich was umstellen? Ach ja, ich möchte ein reines 
gcc-Project, ohne ASF, könnte eventuell die ASF Libs umbauen.

Ich bin für jeden Tip dankbar. Rumgegoogelt nach putchar, prnzf zusammen 
mit Atmel SAM3X8 habe ich natürlich, auch hier im Forum gesucht.

THX Yogy

[Dr. Sommer (Gast)]

Siehe z.B. hier, das müsste für die Atmels genauso funktionieren, falls 
da auch der gcc-arm-embedded mit newlib genutzt wird:
https://www.mikrocontroller.net/articles/STM32_Eclipse_JLink_Linux/Windows#Optional:_Syscalls_implementieren

[Hanns-Jürgen M. (yogy)]

Dr. Sommer schrieb:
> Siehe z.B. hier, das müsste für die Atmels genauso funktionieren, falls
> da auch der gcc-arm-embedded mit newlib genutzt wird:
> 
https://www.mikrocontroller.net/articles/STM32_Eclipse_JLink_Linux/Windows#Optional:_Syscalls_implementieren


Danke für den Link, aber der hat mir so nicht geholfen, er brfachte mir 
aber Suchhinweise.

Mittlerweile habe die Ausgabe auf ein LCD VIA TWI weitgehend laufen. 
Notwendig waren di zusätzlichen _write und _read Routinen, Veränderungen 
in der Linkerdatei sowie eine Änderung bei den "additional Specs" bei 
der Einstellung zu ARM/GNU Linker -> General.

Soweit so gut, ich reiche detaillierte Infos hier gerne weiter.

ABER: Die printf-Sunktion funktieniert NICHT mit floatingpoint 
Variablen... Suche im Netz bbt nur Ergebnisse für ATmel Studion 7 mit 
den AVRs (Da hatte ich  selber das makefile manuell geschrieben), 
Bezüglich SAM3X8 sind mit bei Studio 6.2 Hinweise zu finden, die es bei 
Studio 7 nicht gibt.

Ich nehme an, ich müßte eine bestimmte Library dazu linken???

Hat einer eine Idee? Danke, Yogy

[Johannes S. (Gast)]

Hanns-Jürgen M. schrieb:
> ABER: Die printf-Sunktion funktieniert NICHT mit floatingpoint
> Variablen...

Da fehlt vermutlich nur eine Linker Option, -u ? Müsste ich noch mal 
nachsehen, aber andere sind hier meist schneller bei solchen Fragen.

LDFLAGS += -u _printf_float

Müsste es sein.

[W.S. (Gast)]

Hanns-Jürgen M. schrieb:
> Ich welcher Library muß ich was umstellen?
...
> Ich bin für jeden Tip dankbar.

So?

Na denne:
Also printf kennt ja von hause aus gar keine Gerätezuweisung. Also wäre 
der erste Gedanke, dich nach einer Alternative für sowas wie printf 
umzusehen - und zwar nach einer, die eine Art Gerätezuweisung 
beinhaltet.

Sowas läuft auf einem µC dann auf Selbstgeschriebenes hinaus. Das hat 
dann auch den Vorteil, daß du nicht immer den ganzen riesigen Sack an 
Formatstring-Interpreter vom printf mit herumschleppen mußt.

Den Nachteil sieht man aber auch gleich: man muß sich beim Schreiben 
schon überlegen, was man so alles in seinem String auszugeben gedenkt - 
also den Formatstring selber vor dem Kompilieren auflösen. Das ist bei 
Vielen wider die innere Faulheit.

Ich hänge dir mal ein Beispiel namens "gio.c" zusammen mit einigen .h 
als Erklärung dran. Die Idee dahinter ist ein Schichtenmodell:
- ganz zu unterst sind die Lowlevel-Treiber, hier die "serial(xxxx).c" 
für diverse Controller, die aber alle eine gleiche serial.h haben.

- darüber ist die Schicht "gio", dort werden die Ausgaben nach ihren 
Gerätekennzeichen auf verschiedene I/O's verteilt. In umgekehrter 
Richtung also für Inputs geht das dann auch über gio.c.

- in gio gibt es noch ein paar Vorbereitungen für anderweitige I/O's wie 
ein 'CommandWindow', also ein Konsolenfenster in grafischer Oberfläche 
oder FileStream, also in/aus einer Datei, die aber derzeit unbenutzt 
sind. Ebenfalls gibt es die Möglichkeit, die Ausgabe in einen Puffer im 
RAM zu geben. Und ich habe für Leute, die am PC in C schreiben, einen 
billigen Ersatz für stdin und stdout eingebaut.

Die Benutzung ist denkbar einfach:
String_Out("heute ist der ", toUART1);
Dezi_Out(Tag, 2, toUART1);
Char_Out('.', toUART1);
Dezi_Out(Monat, 2, toUART1);
CRLF_Out(toUART1);

Tag und Monat sind irgendwelche Variablen, und das ganze ist sehr schön 
portabel, sofern man nicht auf I/O's herumhackt, die es im konkreten 
Controller garnicht gibt. Zum Portieren muß man nur die Lowlevel-Treiber 
an den neuen Chip anpassen.

W.S.

[Hanns-Jürgen M. (yogy)]

q@w.S.,

danke, aber etwas mißverstanden.

Die Aufgabeumleitung auf das LCD funbktioniert, will sagen, puts und 
putchar werden richtig umegleitet. auch printf funktioniert 
"eigentlich", aber nicht mit Floating-Point Größen.:

putchar('c'); funzt
puts"Teststring" funzt;
int IntVar = 6125
printf("%04d",IntVariable); funzt auch, nur
float FloatVar = 6,125;
printf("%03.4f",FloatVar);  funzt nicht

Ergänzung: Die Möglichkeit, eigene Ausgaberoutinen zu schreiben, habe 
ich bei "schwachen" Prozessoren oder zur Assemblerzeit auch schon 
gemacht, nur der SAM3x8E hat bei meinem aktuellen "Spielereien" genug 
Platz und Power.

[S. R. (svenska)]

Johannes S. schrieb:
> LDFLAGS += -u _printf_float

Es kann auch

LDFLAGS += -u_printf_float

sein, je nach Version der Toolchain.

Hanns-Jürgen M. schrieb:
> Die Aufgabeumleitung auf das LCD funbktioniert, will sagen, puts und
> putchar werden richtig umegleitet. auch printf funktioniert
> "eigentlich", aber nicht mit Floating-Point Größen.

Du musst dem Linker sagen, welche printf-Implementation er benutzen 
soll. Die newlib unterstützt mehrere. Schau in dein Makefile bzw. die 
Compiler-Befehlszeile.

Nachtrag: Du solltest dem Compiler selbst auch ein 
"-Wl,-u,_printf_float" mitgeben können. Sollte den gleichen Effekt 
haben.

[Hanns-Jürgen M. (yogy)]

Tja, so einfach scheint das nun doch nicht zu sein.

Bei meinen "Spielerteien" mit den AVRs  (2560; 328) hatte ich das 
makefile selber angelegt, und dort konnte ich z.B. bei dem kleinen 328 
die Floatingpoint-Unterstützung abwählen.

Nur hier beim SAM3x8e verwende ich ein automatisch generierte Makefile 
und in  in der Toolchain läßt sich keines der angegebenen Optionen, 
weder beim Compiler noch beim Linker, angeben, ohne daß vehement Fehler 
generiert werden

(Project -> properties -> toolchain)

Ich bin vlt zu alt für diese Prozessoren :-)

Nein, Ernst mal beiseite, ich sethe ziemlich auf dem Schlauch, 
Internetsuchen habe bislang kein brauchbares Ergebnis gebracht, zumeist 
sind es Lösungen für den AVR, und um den geht es ja nicht, oder sie sind 
sonst unbrauchbar bzw. geben keine Lösung an (stackoverflow-forum)

Ach jam, ich habe auch versucht, die zuätzlichen Optionszeilen händisch 
in das Makefile einzutragen. Ergebnis: Fehlermeldungen.

Update: Die Compiler-Anweisungen enthalten die Option: 
-W1,-u,_printf_float. Bringt aber nichts. Ich finde keine eigetragenen 
Linkeroptionenvariable (LDFLAGS)??? Versuche, etwas über toolchain -> 
Linker -> miscellaneous einzugeben brachte nur wieder Fehlermeldungen.

[Dr. Sommer (Gast)]

Hanns-Jürgen M. schrieb:
> -W1,-u,_printf_float

Das muss ein kleines L sein und keine 1. Das muss nur beim Linken, nicht 
beim Kompilieren, angegeben werden. Das Prefix -Wl, kommt nur genau dann 
da hin wenn der Linker via "gcc" oder "g++" aufgerufen wird, nicht wenn 
ld direkt aufgerufen wird, oder die IDE das gar automatisch davor setzt.

Hanns-Jürgen M. schrieb:
> Optionen, weder beim Compiler noch beim Linker, angeben, ohne daß
> vehement Fehler generiert werden

Du kannst sicherlich irgendwo manuell Linker Optionen angeben.

[Hanns-Jürgen M. (yogy)]

@Dr. Sommer

Ich werde folgenden Weg beschreiten: Ich werde eine neues GCC Projekt 
anlegen undlediglich eine Ausgabefunktion implementieren.

So weiß ich, ob oder wo ich ggf. Mist eingebaut habe. Jeden Schritt 
werde ich dann dokumentieren.

Ich welde mich dann wieder und berichte.

VG Yogy

[Hanns-Jürgen M. (yogy)]

So, ich habe ein neues Projekt angelegt mit den wichtigsten Routinen. 
DUE_display enthält die Routinen zur Ausgabe auf einem 4x20 LCD. Das 
funktioniert auch.

Quelltext in main:

#include "sam.h"
  #include "DUE_mocodefs.h"
  #include "DUE_TWI1.h"
  #include "DUE_LCD_display.h"
  #include "stdio_LCD.h"
//  #include "DUE_clock.h"
//#include "DUE_global.h"


int main(void)
{
    U16 IVar = 12345;
  float FVar = -3.245;
  /* Initialize the SAM system */
    SystemInit();
  
  init_twi1();

  
  InitLCD();
  
  
  
  ptr_put = (int (*)(void volatile*,char))&lcd_putchar;  //Ausgabe Festlegung auf LCD, eigene Routine)
  setbuf(stdout, NULL);
  setbuf(stdin, NULL);
  
  
  

  csabs(1,1);  // Setze Cursor absolut in Zeile 1 und Spalte 1), eigene Routine 
  printf("TEST  IVAR  %06d",IVar);
  
  csabs(2,1);
  printf("TEST FVAR %02.4f",FVar);
  
  

    /* Replace with your application code */
    while (1) 
    {
    }
}

Sysgalls.c enthaelt fi _write und _read Routine.

sam3xa_flash-ld wurde ergänzt, um einen .end Fehlermeldung zu vermeiden. 
(wurde als GIF angehaengt)

Aber ich hänge hier einmal das Makefile an, daß IMHO die notwendigen 
Options für Compiler u/o linker enthält.

Aber dennoch wird nur angezeigt:

TEST  IVAR  012345
TEST  FVAR -0.0000

Die Kiste-Maggi Frage: wo liegt das Problem? Ach, wie war die Welt mit 
libc und dem AVR doch so schoen....

VG yogy

[Johannes S. (Gast)]

da gabs auch schon mal so ein Problem, vielleicht sind da passende 
Hinweise bei: Beitrag "[ARM] Nützliches newlib-nano float printf"

das dürfte hier nicht der Fehler sein:
float FVar = -3.245;

Aber beim Umsetzen von Code aus der 8 Bit AVR Welt sollte man darauf 
achten ob man double oder float Konstanten braucht. Die ARM Libs 
unterstützen die double und erzeugen entsprechend mehr und langsameren 
Code.

[Dr. Sommer (Gast)]

Hanns-Jürgen M. schrieb:
> Aber ich hänge hier einmal das Makefile an, daß IMHO die notwendigen
> Options für Compiler u/o linker enthält.

Es muss -u _printf_float sein, nicht _print_float.

Steht z.B. hier: https://launchpadlibrarian.net/287100883/readme.txt

Hanns-Jürgen M. schrieb:
> Ach, wie war die Welt mit
> libc und dem AVR doch so schoen....

Da war es halt vordefiniert. Macht's das so viel besser?

[Hanns-Jürgen M. (yogy)]

Dr. Sommer schrieb:
> Hanns-Jürgen M. schrieb:
>> Aber ich hänge hier einmal das Makefile an, daß IMHO die notwendigen
>> Options für Compiler u/o linker enthält.
>
> Es muss -u _printf_float sein, nicht _print_float.
>

Beim Linkeraufruf steht das auch so. Bei den Compileraufrufen geht -u 
_printf_float  nicht, sondern nut -u,_printf_float, was aber auch nichts 
bringt (Weglassen -u,_printf_float von ändert nichts).

> Steht z.B. hier: https://launchpadlibrarian.net/287100883/readme.txt

da war ich auch schon draufgestoßen


>
> Hanns-Jürgen M. schrieb:
>> Ach, wie war die Welt mit
>> libc und dem AVR doch so schoen....
>
> Da war es halt vordefiniert. Macht's das so viel besser?

Nein, nicht wirklich... aber bequemer... BTW: Es gibt noch viele weitere 
Ungereimtheiten in der SAM3X8 Geschichte... Aber eines nach dem anderen

[Dr. Sommer (Gast)]

Hanns-Jürgen M. schrieb:
> Beim Linkeraufruf steht das auch so.

In dem von dir gezeigten makefile nicht.

Hanns-Jürgen M. schrieb:
> was aber auch nichts
> bringt (Weglassen -u,_printf_float von ändert nichts).

Logisch, das ist nur für den Linker relevant.

[Hanns-Jürgen M. (yogy)]

Dr. Sommer schrieb:
> Hanns-Jürgen M. schrieb:
>> Beim Linkeraufruf steht das auch so.
>
> In dem von dir gezeigten makefile nicht.
>
> Hanns-Jürgen M. schrieb:
>> was aber auch nichts
>> bringt (Weglassen -u,_printf_float von ändert nichts).
>
> Logisch, das ist nur für den Linker relevant.

Hmm, habe ich jetzt etwas mißverstanden oder übersehen? Im unteren roten 
Kästchenen (aus meinem makefile ?) steht doch -u _printf_float  ?

Ach ja, Vertauschen mit "-Tsam3x8e_flash.ld" bringt nichts, ebensowenig 
wie ein Weglassen des Leerzeichens nach "-u"

[Dr. Sommer (Gast)]

Hanns-Jürgen M. schrieb:
> Im unteren roten Kästchenen (aus meinem makefile ?) steht doch -u
> _printf_float

Knick in der Optik? Brille verloren? Da steht _print_float, es fehlt ein 
f!

[W.S. (Gast)]

Dr. Sommer schrieb:
> Knick in der Optik? Brille verloren? Da steht _print_float, es fehlt ein
> f!

Und?

Was schließt du daraus?

Ich habe in der Vergangenheit schon genug Eigenheiten von IDE's erleben 
dürfen, die all das, was man von Hand an Parametern eingegeben hat, nach 
ihrem Gusto parsen und das draus machen, was die IDE denkt, daß es genau 
SO besser sei. Der TO schrieb ja ausführlich, daß er das Betreffende 
KORREKT eingegeben hätte.

Meine Ratschläge an den TO wären
a) die eigentliche Toolchain per Batchdatei/Shellscript aufzurufen und 
auf die diesbezüglichen Dienste der IDE glatt zu verzichten
b) auf printf zu pfeifen und sich auf Eigenes zu verlassen.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> Was schließt du daraus?

Dass das falsche Symbol definiert wird und somit die floating Point 
Behandlung von printf nicht mit gelinkt wird. IDE's parsen keine 
Kommandozeilen Optionen, und hier wird ja nicht mal eine IDE genutzt, 
sondern nur make.

[Hanns-Jürgen M. (yogy)]

Ja, ich habe tatsächlich einen bösen Knick in der Optik 
(Hornhautverkrümmung mit Doppelsichtigkeit beidseitig)

Aber dennoch hätte mir das "eigentlich" auffallen müssen, das mit dem f.

Ich habe das jetzt mal gefixed, Geändert hat sich aber nichts... Ausgabe 
für FVar ist immer noch -0.0000 (wenigstens das "-" wird korrekt 
wiedergegeben)....

[guest (Gast)]

Hanns-Jürgen M. schrieb:
> Ich habe das jetzt mal gefixed,

Nicht ganz. Du benutzt GCC als Frontend zum Linken, da fehlt das "-Wl,", 
siehe den Post von Dr. Sommer vom 18.07.2018 22:05

[guest (Gast)]

Dr. Sommer schrieb:
> und hier wird ja nicht mal eine IDE genutzt,
> sondern nur make.

Falsch, gleich im ersten Post steht "Atmel Studio 7". In dem gezeigten 
Makefile steht nicht umsonst "Automatically-generated file. Do not 
edit!".

[Dr. Sommer (Gast)]

guest schrieb:
> Falsch, gleich im ersten Post steht "Atmel Studio 7". In dem gezeigten
> Makefile steht nicht umsonst "Automatically-generated file. Do not
> edit!".

Richtig, und er nutzt testweise das generierte makefile direkt. Oder 
nicht? Ist auch egal, das makefile zeigt eindeutig dass die Optionen 
ankommen. Kann natürlich sein dass das Atmel Studio einfach eine andere 
GCC Distribution nutzt, bei der das anders oder auch gar nicht geht. 
float ist eh böse, besonders auf MCU's ohne FPU :)

[Hanns-Jürgen M. (yogy)]

So, nochmal zusammengefaßt:

Ich nutze Atmel Studio 7 und das dort autom. generierte makefile, in dem 
ich manuell nichts ändere. Änderungen laufen über die 
Toolchain-Einstellungen (siehe meinen letzten Post mit Bildschirmfoto).

und zu Autor "guest" (Gast): Die Optionsvariante  -Wl,-u _printf_float 
oder auch -Wl,-u,_printf_float anstelle von -u _printf_float bei dem 
Linker Optionen bringt eine Fehlermeldung bzw. ändert nichts am Ergnebis 
(mit "," nach "-u" Ausgabe -0.0000).

Ich glaube, ich schmeiße den ganzen DUE Mist auf den Müll, wenn es so 
schwierig oder gar unmöglich ist bzwe. sein wird, die vielen Probleme 
und Problemchen auszumerzen.

So long, Yogy

[Hanns-Jürgen M. (yogy)]

Der Screenshot fehlte noch..

[Dr. Sommer (Gast)]

Hanns-Jürgen M. schrieb:
> bringt eine Fehlermeldung

Und... was für eine?

Hanns-Jürgen M. schrieb:
> Ich glaube, ich schmeiße den ganzen DUE Mist auf den Müll,

Schade drum, ich würd ihn nehmen.

[Dr. Sommer (Gast)]

Hanns-Jürgen M. schrieb:
> Der Screenshot fehlte noch..

Ach. Entfern das "-Wl,-u _printf_float" mal aus dem  Eingabefeld da 
oben, und füge bei "Other Options" einfach nur "-u _printf_float" hinzu. 
Offensichtlich (Fehlermeldungen lesen!) kann man mit "-Wl," nicht so 
direkt Leerzeichen übergeben. -Xlinker ist ein Alias für "-Wl". 
Alternativ probiere mal "-Wl,-u -Wl,_printf_float".

[Kaj (Gast)]

Hanns-Jürgen M. schrieb:
> Ich glaube, ich schmeiße den ganzen DUE Mist auf den Müll, wenn es so
> schwierig oder gar unmöglich ist bzwe. sein wird, die vielen Probleme
> und Problemchen auszumerzen.
Entspann dich erstmal ne Runde, und dann schaust du mal hier rein:
https://community.atmel.com/comment/1999256#comment-1999256

How to use printf with software floating point in the
Atmel ARM GNU Toolchain in Atmel Studio project?

To add the software floating point support to the printf library
in Atmel Studio 6 project, do the following:

    Open the project properties in Atmel Studio 6

    Go to Miscellaneous in Toolchain -> ARM/GNU Linker

    Add --specs=nano.specs -lc -u _printf_float in the linker flags

    Rebuild the project

Vielleicht musst du auch das '--specs=nano.specs' weglassen. Musst du 
mal ausprobieren.

[guest (Gast)]

Dr. Sommer schrieb:
> Offensichtlich (Fehlermeldungen lesen!) kann man mit "-Wl," nicht so
> direkt Leerzeichen übergeben. -Xlinker ist ein Alias für "-Wl".
> Alternativ probiere mal "-Wl,-u -Wl,_printf_float".

Eventuell auch mit Anführungszeichen?

-Wl,"-u _printf_float"

[Dr. Sommer (Gast)]

guest schrieb:
> Eventuell auch mit Anführungszeichen?

Also wenn schon dann die ganze Option:
"-Wl,-u _printf_float"
scheint ja eine große Herausforderung zu sein, eine Kommandozeilenoption 
unfallfrei zu übergeben...

[Kaj (Gast)]

Nach etwas hin und her, hab ich es compiliert bekommen, kann es aber 
aufgrund fehlender Hardware nicht testen.

#include <stdio.h>
#include "sam.h"

int main(void)
{
  unsigned short IVar = 12345;
  float FVar = -3.245;
  
  /* Initialize the SAM system */
  SystemInit();
  
  printf("TEST  IVAR  %06d",IVar);
  printf("TEST FVAR %02.4f",FVar);

  /* Replace with your application code */
  while (1)
  {
  }
}

Toolchain -> ARM/GNU Linker -> General

[x] Use Size optimized library (--specs=nano.specs)

Additional Specs: Use syscall stubs

Toolchain -> ARM/GNU Linker -> Miscellaneous

Linker Flags: -Tsam3x8e_flash.ld -lc -u _printf_float

Build output:

Program Memory Usage : 14396 bytes  2,7 % Full
Data Memory Usage    : 66048 bytes  67,2 % Full

Printf mit float braucht ne menge platz.

Es kann sein, dass du noch die Linkerscripte etwas anpassen musst.

[Hanns-Jürgen M. (yogy)]

Ich fasse es nicht! Problem ist (hoffentlich) gelöst.

Ich fand bei erneuter Google Suche den Thread hier im Forum:

Beitrag "[ARM] Nützliches newlib-nano float printf"

Und dort steht, daß man den Stackalign auf 8 ändern soll. gesagt, getan. 
Die letzte Zeile in "meinem" File: sam3xaflsch.ld geändert von:
      /* Stack starts at end of ram */
      _estack = ORIGIN(ram) + LENGTH(ram) - 4;

auf:

      /* Stack starts at end of ram */
      _estack = ORIGIN(ram) + LENGTH(ram) - 8;

(Stack wird auf 8 sprich 64 bit aligned. Sie o.a. thread. Ob das nun 
final die Lösung darstellt, wird sich zeigen.

[Dr. Sommer (Gast)]

Hanns-Jürgen M. schrieb:
> Ich fand bei erneuter Google Suche den Thread hier im Forum:
>
> Beitrag "[ARM] Nützliches newlib-nano float printf"

Wurde dir doch hier schon gesagt:

Johannes S. schrieb:
> da gabs auch schon mal so ein Problem, vielleicht sind da passende
> Hinweise bei: Beitrag "[ARM] Nützliches newlib-nano float printf"

Und warum nicht einfach:

_estack = ORIGIN(ram) + LENGTH(ram);

Dann ist es auch 8-Byte aligned und du verschwendest keine 8 Bytes. ARM 
hat einen Pre-Dekrement, Post-Inkrement-Stack.

[guest (Gast)]

Dr. Sommer schrieb:
> Ach. Entfern das "-Wl,-u _printf_float" mal aus dem  Eingabefeld da
> oben, und füge bei "Other Options" einfach nur "-u _printf_float" hinzu.
> Offensichtlich (Fehlermeldungen lesen!) kann man mit "-Wl," nicht so
> direkt Leerzeichen übergeben. -Xlinker ist ein Alias für "-Wl".

So einfach gehts dann doch nicht, -XLinker kann auch keine Leerzeichen. 
Das muß dann zweimal angegeben werden "-Xlinker -u -Xlinker 
_printf_float", also das "-u" und das "_printf_float" müssen einzeln in 
getrennte Zeilen in die "Other Options" eingetragen werden.
Ansonsten sollte bei -Wl dann doch die Variante mit dem Komma die 
richtige sein "-Wl,-u,_printf_float". Die Varianten mit den 
Anführungszeichen scheinen beide zu gehen, egal ob das "-Wl," innerhalb 
oder vor den Anführungszeichen steht.
Jedenfalls kommt beim eigentlichen Linkeraufruf bei allen 4 Varianten 
immer dasselbe raus. Kann man sehen, wenn man zu den "Linker Flags" ein 
"-v" hinzufügt.

[Dr. Sommer (Gast)]

guest schrieb:
> So einfach gehts dann doch nicht, -XLinker kann auch keine Leerzeichen.

Ja, aber ggf. erkennt und verarbeitet das Atmel Studio die Leerzeichen 
korrekt so wie du schreibst, wenn man die Option in dieses -Xlinker Feld 
einträgt.

[W.S. (Gast)]

Hanns-Jürgen M. schrieb:
> Ich glaube, ich schmeiße den ganzen DUE Mist auf den Müll

Merkst du eigentlich noch was? Soweit ich das hier sehe, kämpfst du die 
ganze Zeit gegen deine IDE und gegen den GCC und gegen deine hochnäsige 
Ansicht, daß du ja bei einem Cortex-M3 (was dein µC ja mal auch bloß 
ist) auf platz- und problem-sparende Programmierung zu pfeifen gedenkst 
und stattdessen das printf nicht zum Laufen kriegst.

Nach all der Diskussion in diesem Thread finde ich das ganz schön 
abenteuerlich - und ÜBERFLÜSSIG.

Mein Rat wäre - wie schon so unsäglich oft - dieser:
- lade dir den Keil herunter und benutze diesen erstmal. Wenn du dich 
nicht unsäglich blöd anstellst, dann kannst du damit in den verfügbaren 
32K ne ganze Menge machen. Jedenfalls so viel, daß du damit sattelfest 
in den Cortex-M3 wirst. Das Ganze setzt natürlich voraus, daß du deine 
Toolchain per .bat aufrufst und die beigefügte IDE nicht benutzt.

Nur so lernst du den Umgang mit deinen eigentlichen Tools. Und JA, ich 
weiß, daß der GCC weitaus hakeliger ist als der Keil, ich hatte das bei 
der Lernbetty alles durch.

- wenn du willst, dann lade dir irgendwann auch mal die 
Community-Edition vom ADS herunter - das ist allemal besser als so ein 
vergurktes System aus IDE und normalem GCC.

Kurzum, lerne auf eigenen Beinen zu stehen (bzw. zu programmieren) und 
nicht elleweil nur in einer IDE herumzudaddeln.

Und wenn du mit dem Atmel nicht klar kommst, dann such dir hier im Forum 
eines meiner Klein-Projekte mit nem STM32F103C8T6 heraus, da findest du 
die Eagle-Dateien, die Quellen und ein fertiges Image, so daß du erstmal 
damit anfangen kannst. Also stell dich nicht so an.

W.S.

[Hanns-Jürgen M. (yogy)]

W.S. schrieb:
> Hanns-Jürgen M. schrieb:
>> Ich glaube, ich schmeiße den ganzen DUE Mist auf den Müll
>
> Merkst du eigentlich noch was? Soweit ich das hier sehe, kämpfst du die
> ganze Zeit gegen deine IDE und gegen den GCC und gegen deine hochnäsige
> Ansicht, daß du ja bei einem Cortex-M3 (was dein µC ja mal auch bloß
> ist) auf platz- und problem-sparende Programmierung zu pfeifen gedenkst
> und stattdessen das printf nicht zum Laufen kriegst.


Nun, ich bleibe mal ganz ruhig und versuche Dir zu erklären, um was es 
hier eigentlich geht und wieso ich mit dem SAM3X6 spiele. Ich mache es 
auch ganz laaangsam.

Ich bin keine Profiprogrammierer oder SW Ing, sondern ursprünglich ein 
Analogmensch. Ich habe mein Studium ohne Mikroprozessoren und ohne 
Fortran als Pflichtvorlesung durchgestanden, dafür mit Röhren, HF und 
Hohlleitern.

Erst 1981 habe ich mit mit SW angefangen (Fortran), dann Assembler 
(1802, 6809), ab 1985 Assembler und C auf einem VME-Bus mit 68000. Für 
mich selber habe ich dann 6809 und (1991) 68HC11 Hardware und auch 
Software in Assembler und später C  entwickelt. Alles unter DOS 
natürlich, Windoof war nur etwas für lahme Weicheier.

Auf der Suche nach einer schnelleren HW (Die HC11 waren lamngsam und 
auch alle abgekündigt) stieß ich auf die spottbilligen Arduinos, die ich 
dann mit einer ATMEL IDE programmierte. Das war auch erst zäh (der HC11 
C-Compiler war von IAR und ziemlich alt). Für DOS gab es da leider 
nichts mehr.

Nur jetzt brauche ich wegen der vielen Schnittstellen in einem neuen 
Bastelprojekt, die zeitnah zu bedienen sind, einen schnelleren 
Prozessor, und so kam ich auf die glorreiche ujnd noffenbar dumme Idee, 
mit dem Arduino DUE und Atmel 7 anzufangen. Das muß schon irgendwie 
funzen. Ach ja, mit Keil habe ich früher nicht so tolle Erfahrungen 
gemacht (Emulatoren), das kann heute durchaus anders sein.

Natürlich könnte ich auch mit einen nackten C-Compiler, einem nackten 
Linker und einer Batchdatei arbeiten (Das mache ich ja bei den DOS 
basierten Projekten genauso), aber dann müßte ich wieder einmal bei Null 
anfangen. Und dazu habe ich nun wirklich überhaupt keine Lust, denn mit 
meinen aktuellen Projektplanungen werde ich keine Millionen scheffeln, 
denn die sind nur für mich.

Nun denn, häf e neiss wiekend und prost

[S. R. (svenska)]

Hanns-Jürgen M. schrieb:
> Natürlich könnte ich auch mit einen nackten C-Compiler, einem nackten
> Linker und einer Batchdatei arbeiten (Das mache ich ja bei den DOS
> basierten Projekten genauso), aber dann müßte ich wieder einmal bei Null
> anfangen.

Du kannst in die meisten vernünftigen IDEs auch dein eigenes Makefile 
einbinden. Dann hast du eine vernünftige IDE, die C versteht und hast 
trotzdem die Kontrolle über das Buildsystem.

Make gibt es auch schon etwas länger. :-)

[guest (Gast)]

Dr. Sommer schrieb:
> Ja, aber ggf. erkennt und verarbeitet das Atmel Studio die Leerzeichen
> korrekt so wie du schreibst, wenn man die Option in dieses -Xlinker Feld
> einträgt.

Nein, leider nicht. Zumindest nicht wenn man das "-u _prirtf_float" 
komplett in eine Zeile dieses -Xlinker Feld einträgt. Ich habs extra 
ausprobiert. Teilt man das auf zwei Zeilen in diesem Feld auf geht es.