Anzeige:
Ergebnis 1 bis 5 von 5

Thema: stdout Umleitung mit GCC

  1. #1
    Registrierter Benutzer
    Registriert seit
    21.06.2003
    Beiträge
    15

    stdout Umleitung mit GCC

    probiere mit einem (hitex) GCC für Cortex M3 die printf Ausgabe auf die serielle Schnittstelle umzulenken. Dazu habe ich einen putchar geschrieben, welcher die serielle anspricht. Wenn ich nun printf ("A") mache, funktioniert das wie erwartet korrekt. Sobalb ein Formatzeichen wie etwa %3d auftaucht wird die Laufzeitbibliothek angesprochen und es kracht mit folgenden Fehlermeldungen:

    GnuToolPackageCortex/bin/../arm-hitex-elf/lib/libc.a(lib_a-printf.o) uses hardware FP, whereas .\objects\out.elf uses software FP

    was ist ein FP bzw. was ist da zu tun ? Ich bin mir auch nicht sicher, ob ich
    ein include stdio.h benötige oder nicht. Mit stdio.h geht gar nichts, ohne bekomme ich natürlich Warnungen:

    arm-hitex-elf-gcc.exe -mcpu=cortex-m3 -c -gdwarf-2 -xc -MD -Wall -O0 -mthumb -mno-thumb-interwork -mno-tpcs-frame -fsigned-char -mlittle-endian -I.\ -o .\objects\main.o .\main.c
    .\main.c:106: warning: conflicting types for built-in function 'putchar'
    .\main.c: In function 'main':
    .\main.c:132: warning: implicit declaration of function 'printf'
    .\main.c:132: warning: incompatible implicit declaration of built-in function 'printf'

    In den Projekteinstellungen kann man auswählen:
    use math lib, libc, libgcc sowie "do not link against shared lib"

    was bedeutet das bzw. wie ist die korrekte Vorgehensweise ?

  2. #2
    Registrierter Benutzer Avatar von jeebee
    Registriert seit
    01.01.2005
    Ort
    Bern || Zürich
    Beiträge
    540
    FP bezieht sich auf die Floating Point Instruktionen, welche bei ARM wahlweise als Software-Emulation oder als "Real" Instruktionen ausgeführt werden können. Offensichtlich muss FP bei allen Teilen des Projekts mit der gleichen Methode realisiert sein.

    Zitat Zitat von [url]http://gcc.gnu.org/onlinedocs/gcc/ARM-options.html[/url]
    -mfpu=name
    -mfpe=number
    -mfp=number
    This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: `fpa', `fpe2', `fpe3', `maverick', `vfp', `vfpv3', `vfpv3-d16', `neon', and `neon-fp16'. -mfp and -mfpe are synonyms for -mfpu=`fpe'number, for compatibility with older versions of GCC.
    HTH

    jeebee
    Geändert von jeebee (28-10-2009 um 23:31 Uhr)
    my very own 128 bit integer
    C4 D3 B8 A8 9E A0 C6 EC 7D EC A8 15 28 D1 92 58
    more information

  3. #3
    Registrierter Benutzer
    Registriert seit
    21.06.2003
    Beiträge
    15
    Au weia, die Runtime Bibliothek scheint von einem Cortex A8 mit Neon und anderem Zeugs zu sein was es bei Cortex M3 nicht gibt. Habe schon andere Versionen der Lib probiert (BE=Big Eindian) aber mein Teil ist auf Little Eindian eingestellt und Float Hardware gibt es nicht. Der Interwork Fehler scheint von einer ARM7/9/11 Lib zu sein und tritt auf weil es im Cortex nur noch Thumb2 Befehlssätze gibt. Leider sind die Quellen der Libs nicht dabei und es ist mir auch unklar, was in libc, libgcc oder newlib drinnen ist, bzw. auf was man am besten aufsetzt wenn man selber machen will. Vielleicht steige ich auf den GCC Buildt von Codesourcery um denn damit scheint der Rest der Welt auch zu arbeiten ...

  4. #4
    Registrierter Benutzer Avatar von panzi
    Registriert seit
    05.05.2001
    Ort
    Kottingbrunn
    Beiträge
    609
    Also eine Ausgabe leitet man anders um. Schließe den Filedescriptor 1 und öffne (nach 1) die serielle Schnittstelle. Siehe:

    Code:
    #include <stdio.h>
    #include <unistd.h>
    #include <stdlib.h>
    #include <fcntl.h>
    
    int main() {
    	if (close(1) != 0) {
    		perror("close(1)");
    		return EXIT_FAILURE;
    	}
    
    	int fd = open("/dev/pts/0", O_WRONLY);
    
    	if (fd == -1) {
    		perror("open(\"/dev/pts/0\", O_WRONLY)");
    		return EXIT_FAILURE;
    	}
    
    	if (fd != 1) {
    		fprintf(stderr, "wasn't opened as 1 (stdout) but as %d\n", fd);
    	}
    
    	// now all output to stdout is in fact written to /dev/pts/0
    	printf("this should be on /dev/pts/%d\n", 0);
    	puts("this as well");
    	write(1, "and this", 8);
    	fputc('\n', stdout);
    
    	return EXIT_SUCCESS;
    }
    Hier habe ich das erste virtuelle Terminal statt der Seriellen Schnittstelle geöffnet (ich hab denk ich gar keine mehr, will nicht hinter den PC kriechen, jedenfalls finde ich nix passendes in /dev und ich könnt so das Prog. auch nicht testen, hab nix das den Output der Schnittstelle ließt).
    Intel Core 2 Duo CPU 2.66GHz; Nvidia GeForce 8 8800 GTS; 4GB RAM; Fedora 12; KDE-testing

  5. #5
    Registrierter Benutzer
    Registriert seit
    21.06.2003
    Beiträge
    15
    Das Linken der Libraries funktioniert jetzt. Neben der Auswahl der korrekten libc und libgcc mit Soft Float und war der zum Compilieren der Anwedung passende Schalter -mfloat-abi=soft bzw. -msoft-float das Zauberwort weil dies bei GCC offensichtlich kein default ist.

    @panzi: das Zielsystem ist kein Linux sondern hat gar nichts drauf. GCC wird also als Crosscompiler genutzt und es gibt kein Filesystem weshalb ich gar nicht auf die Idee gekommen im Verzeichnis /dev nach einer passenden tty zu suchen. Im Endeffekt möchte ich eben die formatierte Ausgabe mit printf nutzen und deshalb war Idee dem Compiler ein eigenes putchar unterzuschieben was weis wie auf die (zuvor initialisierte) Schnittstelle (oder LCD Display) ein Zeichen geschrieben wird.

    Momentan sieht es so aus, dass printf das selbst geschriebene putchar leider nicht aufruft, sondern stattdessen in der Lib bei _isatty auf einen Software Breakpoint Befehl aufläuft. Woher soll die Lib auch wissen, wie tty auf diesem System angesprochen wird?

    Ein anderer Lösungsansatz wäre wohl sprintf um den Speicher dann mit einer ganz anderen selbstgemachten Funktion an die HW rauszuschreiben. Das mit dem übersetzen einer eigenen Lib scheint wohl eine größere Sache. Wenn ich das richtig verstanden habe, enthält libgcc den Teil der Laufzeitbibliothke welcher unbedingt mit der gleichen Version des GCC übersetzt werden muss, während libc auch mit älteren GCC übersetzt sein darf.

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •