www.mikrocontroller.net

Forum: Compiler & IDEs long ausgabe mit printf


Autor: Christopher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte gerne eine long Variable mit printf am Terminal ausgeben.
Ich hab schon gesucht aber %li, %lu, %ld funktionieren nicht. Ich 
benutze Codevision zum Programmieren. Mit %i funktioniert es aber dann 
hab ich immer einen Überlauf.

Danke

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, im AVR-GCC geht das (und es geht genau so), und in dessen Forum
befindest du dich hier...

Was sagt denn die Dokumentation deines Compilers?

Autor: Christopher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Dokumentation von Codevision sagt leider nur etwas zu
float, int, char, hex, usw. leider nichts zu long.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
%ld ist schon voll o.k. so für konforme C-Compiler.

In der Codesammlung hat jemand nur für Codevision %ald gepostet, keine 
Ahnung, was das bedeutet.


Peter

Autor: Christopher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oje, sonst hatte ich mit Codevision nie Sorgen. Muss mich vielleicht 
doch mal umgewöhnen. %ald funktioniert auch nicht.

Autor: Karl Zeilhofer (griffin27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite mit dem arm-elf-gcc, und hab gerade das gleiche Problem.
Ich hab einen 64-bit integer, den ich per printf mit %ld an das Terminal 
senden möchte. Leider kommen nur kryptische Zeichen an.

%ld erwartet aber auch einen long int, aber int64_t ist mit long long 
definiert. gibts dafür eine einfache Lösung?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn deine Bibliothek es kann: %lld.

Autor: Karl Zeilhofer (griffin27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anscheinend kann sies nicht.

Hier das Programm:
#include <board.h>
#include <pio/pio.h>
#include <dbgu/dbgu.h>

#include <stdio.h>
#include <stdint.h>

/// Pio pins to configure.
static const Pin pins[] = {PINS_DBGU};

int main(void)
{
    int32_t l1,l2;
    int64_t l3;


    PIO_Configure(pins, PIO_LISTSIZE(pins));
    DBGU_Configure(DBGU_STANDARD, 115200, BOARD_MCK);
    printf("\n-- ATMEL ARM7 Dummy Project 1.4 --\n\n");

    l1=2000000000; // 2 Mrd
    l2=0x77359400; // 2 Mrd
    l3=(int64_t)l1*l2;
    printf("2Mrd * 2Mrd = %lld\n",l3);

    return 0;
}

der GDB zeicht in Eclipse für l3 das richtige Ergebnis an.
Als Ausgabe erhelte ich im GtkTerm
-- ATMEL ARM7 Dummy Project 1.4 --
2Mrd * 2Mrd = ®ÊÀ؇˜&ÈúːSÒ°KÜeý^Á
ºŸ2äů‘WªD—1U/êîvkÕáꦂ @€6$ 

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du es nur als Debug brauchst, nimm Hex ausgabe und mach aus dem
int64_t einen int32_t mittels cast im Printf sowie dasselbe nochmals
inkl vorigem shift. Mußt die Reihenfolge usw halt ausprobieren, daß
es klappt (big endian/little endian).

Sonst, unter Unix/Linux funktioniert es mit ll L oder q prefix, gcc
kann alle, die Windows Version von GCC scheitert an long long, das
ist ein bekannter Fehler von GCC, hängt aber nicht direkt von den 
Sourcen ab, eher vom verwendeten Windows-Compiler, um die GCC sourcen zu 
erstellen.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich meinte natürlich immer den cross-compiler, nicht nativen Unix 
Compiler.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> hängt aber nicht direkt von den Sourcen ab, eher vom verwendeten
> Windows-Compiler, um die GCC sourcen zu erstellen.

Das ist aus zweierlei Gründen zu bezweifeln, einerseits wird kein 
Compiler verwendet, um "die GCC sourcen zu erstellen", andererseits wird 
gcc auch unter Windows mit sich selbst übersetzt.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist aber leider so. Windows Ports werden meistens mit MING 
compiliert,
eine GCC Portierung auf Windows, welche die Newlib benutzt.
Bei dieser Lib existiert kein printf für ll und L ist da ein Synonym für
long double. Bei ll: behavior is undefined, laut doc.
Da GCC selbst kein long long printf hat, hat er Probleme damit, so eines
zu generieren. Warscheinlich testet er das printf selbst oder so, weiß 
ich
nicht, aber ich kenne mehrere Mailing-Lists, welche das Problem 
aufgeworfen hatten, und da es teilweise Unix Portierung waren, wie *BSD
usw kam dann auch eine Antwort von einem GCC Entwickler, der das 
natürlich besser begründet hat, aber im Prinzip ist es eine Limitierung 
der Runtime
des Compilers, mit dem GCC selbst compiliert wurde.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, sogenannte tippfehler, nicht erstellen, sondern compilieren.
habs jetzt erst gecheckt, sorry

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris wrote:
> Das ist aber leider so. Windows Ports werden meistens mit MING
> compiliert,
> eine GCC Portierung auf Windows, welche die Newlib benutzt.

Der Haken dabei ist wohl, dass newlib halt kein richtiges Projekt
ist, sondern lieblos und wenig gepflegt von irgendwoher zusammen
gezogener Sourcecode für eine (einigermaßen) Standardbibliothek,
die nicht den Limitierungen der (L)GPL unterworfen ist.  So findet
sich da offenbar eine uralte (lange vor ISO C99 geschaffene)
Variante der BSD-libc wieder, die damals L als modifier für long
long int benutzt hat.  Wenn die Leute mal ihre Quellen von einem
einigermaßen aktuellen FreeBSD aktualisieren würden, dann wäre das
Dilemma behoben.

Für Karl heißt das aber wohl, dass er sich auch mit %Ld behelfen
kann.

Autor: Karl Zeilhofer (griffin27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alos %Ld funktioniert genausowenig wie %lld... Ich brauch die Funktion 
grad nicht wirklich, aber trotzdem schade.

lg

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann kannst du dir nur mit dem Selbstportieren einer der diversen
BSD-Bibliotheken behelfen, wenn du's mal brauchst.

Autor: Karl Zeilhofer (griffin27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hört sich nach viel arbeit an...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Zeilhofer wrote:
> hört sich nach viel arbeit an...

Ist an einem Abend gemacht.  Man sollte sich unterschiedliche
Versionen vornehmen, aktuelle Versionen sind auf Grund der später
eingebauten C99-Features u. U. etwas komplexer geworden.  Ggf. mit
einem ursprünglichen 4.4BSD beginnen, da bin ich mir nur nicht ganz
sicher, ob's da schon long long gab.

Autor: A. K. (prx)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Für solche Debug-Zwecke hatte ich mir deshalb mal eine eigene 
eingedampfte Version von printf gestrickt. Schon auf Platzgründen wollte 
ich beim ARM auf die newlib verzichten-

Sollte ziemlich universell einsetzbar sein, sofern alloca() existiert 
und "unsigned long long" der maximal verfügbare Integer-Typ ist.

Ist Originalfassung, die Includes müssen angepasst werden, config,h kann 
man streichen.

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.