Nem, azért próbálgattam számokkal. Mindig ezeket a számokat teszi bele.

"%c", 65 -re mit ir ki?

egy r betűt.

Erre egy 'A' betut kellett volna kiirjon. Az 'r' ASCII kodja 114, amit %d eseten is kiirt. De, hogy miert ezt veszi fel az atadott ertek helyett, azt nem tudom. Nem tudsz disassembly listat nezni?

Azt sajnos nem tudom hogy kell az mplabx-ben. Hát szerintem ez egyértelmű, hogy nem az én hibám, szerintem a fordító lehet rossz, vagy tényleg nem tudom már mire gondoljak, több napja keservesen szenvedek vele.

Vagy a fordito vagy a sprintf, de az eleg valoszinu, hogy nem te hibazol. Hacsak nem valami memoria modell beallitas vagy egyeb agyafurt mikrocsip dolog van a hatterben.

A probléma csak az, hogy nekem szükségem van ehhez a projekthez a sprintf függvényre, és nincs sok kedvem a nyákot se újragyártani 16 bites pichez

Ebben az esetben kenytelen leszel jobban beleasni magad a dologba. Csak kellene az a disassembly lista. Vagy megirod a sprintf-et. A sprintf elvileg az vararg-on (stdarg.h) alapul, esetleg azzal lehet valami gaz. Nem tudom, hogy xc8-on van-e valami ezzel kapcsolatos beallitas.

Disassembly list: Windows / Debugging / Output / Disassembly Listing file

Még egy kerdes. Include-olod a szukseges header-t (stdio.h)?

Igen, persze, szerintem anélkül le sem fordulna.

Csak egy tipp. Próbáld beállítani a karakter kódolást a project beállításainál win 1250-re.

Kipróbáltam szimulátorban, nálam jól működik az alábbi program:

18f26k22, XC8 (Free mode) v1.10
Érdemes lenne átnézni a beállításokat.

Szimulatoron persze, hogy jol mukodik, hiszen a program hibatlan. Ezert tette fel a kerdest. Probald ki valos harware-en.

Nem nyilatkozott arról, hogy próbálta-e szimulátorban, és ott jó volt-e, pedig érdemes lenne ott kipróbálnia. Mivel az sprintf függvény semmilyen perifériát nem használ, nem tartom valószínűnek, hogy eltérjen a szimulátor eredménye.

Gondolod? A prototype hianya jo esetben egy Warning-ot jelent, nem tobbet. Mikrocsip kornyezetben a Warningot a legtobben el sem olvassak. Viszont a valtozo paramterszam miatt lehet, hogy maskepp adja at a parametereket, es ezert nem mukodik. Ezert kerdeztem csak az include-ot.

Ebben lehet némi igazság. Ez a szimulátor a lefordított kódot futtatja egy virtuális PIC-en?

Igen, ahogy mondod. A processzormaggal nem szokott gondja lenni a szimulátornak, még a timerek is nagyrészt jól működnek benne. A környezetet leszimulálni azt már viszont csak te tudod, a bonyolultabb perifériákat (USB, ethernet) meg nem is lehet normálisan leszimulálni.

Kipróbáltam, nem fordult le include nélkül. Amúgy korrekt programozók minden warningra is figyelnek, azok sem véletlenül vannak ott. Sok esetben olyan hibát jeleznek, amitől teljesen működésképtelen is lehet akár a program.

Nem próbáltam szimulátorban, megmondom őszintén, nem is tudom hogy kell. Ezer más helyen használtam már ezt a függvényt, és még mindig jó volt mindenhol. Igaz 8 bites mikrokotrolleren nem használtam, csak 16 bitesen. Valószínű a probléma megoldása ezirányban fog történni.

Kuldtem egy PM-et. Viszont az lenne a kerdesem, honnan derul ki az, hogy Te melyik soros porton kuldod ezeket az adatokat? (ketto van a 18F26K22-ben)

sajat hibam, elneztem 2-esen kuldod.

uart2_tx_str(buf); -- küldi ki, tehát a TX2-n megy ki. A soros portra írtam függvényeket. Az uart1_tx_str meg a TX1-en küld adatokat.

Mindjart kuldok egy olyan verziot, ami nalam bevalt. Kivancsi lennek a velemenyedre.

puts2USART(CrNl);
putrs2USART ("Ez a szam:");
puts2USART(buf); // nalam int>>str onverzioval, vagyis: puts1USART(itoa(count_str, count, 10));

ami lemaradt, es fontos:
unsigned char CrNl[] = "\r\n";

Baud rate megfeleoen van beallitva?

Tipp: 54+33=87 vs. buf size 64?

Itt mire gondolsz pontosan? A szöveget és a két számot az sprintf formázva kiírja a buf-ba és ha jól számolom az csak 20 byte (21 a \0-val) bőven elég neki a 64 byte.

Én sokkal inkább az XC-re gyanakszom nekem az 1.40 XC32-vel c++ nem ment se a cout se a printf ha float/double/long double akartam kiírni mindig csak inf-et dobott vissza, ki kell próbálni másik verziójú XC8-at.

Mivel nem vagyok profi C-ben, lehet rosszul ertelmezem? (sprintf fuggvenyt se igazan hasznaltam meg) A ket szam 54 es 33 nem a kiiratando meretet* jelenti?
* méret (a kiírás minimális szélessége):

Ha esetleg egyszer C és printf/sprintf használatra vennéd magad.

Koszi, ez eddig a legertelmesebb sprtintf fgv leiras.