[Keil/C] printf doet raar

[Verwijderd]

Ik ben in C iets aan het schrijven voor een 80c515a, het is een stuk code om een ds1722 (temperatuursensor) uit te lezen.

ik snap echter niet waarom dit stuk code:

code:

 printf("starting init %u \n",0x10);

mij via hyperterminal het volgende opleverd:

starting init 1000

%u veranderen in %x bij de printf geeft precies hetzelfde.

ben ik nu heel dom bezig of.....

zou dit het gevolg kunnen zijn van een stdio.h en reg515a.h die meerdere keren ge-include worden? (krijg hier geen errors over).

de (misschien verkeerde) opzet:
ik heb een h-file gemaakt voor de protoptypes van de functies en deze ge-#include in een c-file waar de functies in staan. dit ge-compiled en de h-file en de object-file in een nieuwe dir gezet om het met een test-project te testen (in test.c is dus de h-file ge-include waar de functies in staan).

[leuk_he]

Is het een heel domme vraag om te vragen wat de byte order en de groote van een int is op datplatform?

en wat geeft:

printf("starting init %u \n",0x0010);

[Daos]

Als je 1000 bij %x krijgt, dan denk ik dat printf 16 bits verwacht (in BigEndian) terwijl 0x10 maar 8 bits zijn. Probeer die 0x10 eens te casten naar een unsigned int.

%u print een unsigned. Er zou dan 16 uitmoeten komen (of 4096 als het fout gaat).

[Verwijderd]

leuk_he schreef op donderdag 28 juli 2005 @ 14:02:
Is het een heel domme vraag om te vragen wat de byte order en de groote van een int is op datplatform?

en wat geeft:

printf("starting init %u \n",0x0010);

byte order, je bedoeld dit: http://www.keil.com/support/docs/1948.htm ?
en sizeof(int) geeft bij mij 2.

toevallig kwam ik net bij het zoeken naar die sizeof(int) het volgende tegen:
http://www.keil.com/support/docs/655.htm

[VyperX]

Daos schreef op donderdag 28 juli 2005 @ 14:03:
Als je 1000 bij %x krijgt, dan denk ik dat printf 16 bits verwacht (in BigEndian) terwijl 0x10 maar 8 bits zijn. Probeer die 0x10 eens te casten naar een unsigned int.

%u print een unsigned. Er zou dan 16 uitmoeten komen (of 4096 als het fout gaat).

Ehm.. wel even bedenken dat printf die "0x10" interpreteert als een _pointer_ naar een int (in dit geval dan).

Die 0x10 zou de geheugen plek moeten zijn waar ie de waarde uit kan lezen uit z'n sensor. (Memory-mapped I/O.) Omdat ik verder niet zoveel weet over de chip & sensor kan ik verder ook niet veel suggesties geven.

Zowiezo is het vreemd dat ie "1000" als output krijgt, omdat %x een hexadecimaal getal zou moeten printen. (Zie hier.)

[ Voor 3% gewijzigd door VyperX op 28-07-2005 14:16 ]

[Onno]

VyperX schreef op donderdag 28 juli 2005 @ 14:14:
[...]
Ehm.. wel even bedenken dat printf die "0x10" interpreteert als een _pointer_ naar een int (in dit geval dan).

Dat lijkt me zeer onwaarschijnlijk, en bovendien in strijd met elke standaard.

[NMe]

Ik herinner me een vergelijkbaar probleem in Keil met dezelfde microcontroller, dat ik toentertijd op heb gelost door een karakter toe te voegen, volgens mij een b: %bu dus. Ik weet het alleen niet zeker, en ik kan het hier ook niet nakijken, aangezien zowel die code van mij als de help van Keil op school liggen, en niet hier.

[Verwijderd]

het probleem is nu zo te zien opgelost. het ging mij er om dat ik de hex-waarde van unsigned chars kon terug sturen.
dit werkt(ook al is het waarschijnlijk niet helemaal hoe het hoort):

code:

 printf("writing %x to %x \n",(unsigned int) reg_settings, (unsigned int) 0x80);

dit werkt echter niet:

code:

 printf("writing %x to %x \n",(unsigned char) reg_settings, (unsigned char) 0x80);

( met reg_settings is 0xE6) geeft dit:

writing e680 to 0

dus niet iets random maar hij heeft 0xE6 en 0x80 om eenofandere reden samengeplakt en de andere 0 gemaakt

[VyperX]

Onno schreef op donderdag 28 juli 2005 @ 14:24:
[...]

Dat lijkt me zeer onwaarschijnlijk, en bovendien in strijd met elke standaard.

Heh... oeps... Zat even met char* in m'n hoofd... excuus!

(Even om mijn post toch nog wat nuttiger te maken...)
Dat gedoe met die "e680" is redelijk logisch in te zien... Je %x geeft aan dat je een int wilt printen, dus printf leest een int (in jouw geval 16 bits) van de stack. Door de casts worden de waardes als ints op de stack gezet.

[ Voor 37% gewijzigd door VyperX op 28-07-2005 15:26 ]

[MSalters]

0x10 is een int, die hoef je in C verder niet te casten naar int. Het probleem is dat de Keil compiler geen C compiler is, ook al claimen ze van wel. De tekst op http://www.keil.com/support/docs/655.htm is een weggever. Argumenten kleiner dan een int moeten automatisch geconverteerd worden naar een int, als je een vararg functie aanroept. Keil doet dat ten onrechte niet. De oplossing is inderdaad een cast.