itoa in C18 Compiler will nicht so wie sie soll

[Paul K. (paul-cgn)]

Hi zusammen,

ich scheitere gerade an einem scheinbar recht simplen Problem.
Für einen pic18F13K50 (ist aber auch unerheblich denke ich) schreibe ich 
ein Program welches schlichtweg den Wert eines Timers per USART ausgeben 
soll.

Dabei will ich den 16bit unsigned int wert des Timers1 also per 
putsUSART() ausgeben (ich nutze die standard usart.h die beim Compiler 
dabei ist: void putsUSART ( char *data); )
Damit das geht versuche ich also den Wert des int in ein char[] 
umzuwandeln mittels der itoa function aus der stdlib.h: char *itoa (auto 
int value, auto char *s);

Aktuell bin ich nu im Simulator von MPLAB X unterwegs und lese da auch 
die Werte beim debuggen aus und lasse mit den UART Output anzeigen, wenn 
ich nur einfach texte rüber schicke klappt das alles, man kann also 
davon ausgehen das es nicht am USART und dessen konfoguration liegt.

Hier nun der relvante code:

            unsigned int numberToPrint = 12345;
            char str[5];
            itoa(numberToPrint, (char*) str);
            putsUSART((char*) str);

Was jedoch ausgegeben wird ist in der Output console:

24880h

Ich habe beim debuggen gesehen das bereits der Wert von "str" auch eben 
dieses "24880h" ist, somit ist recht eingegrenzt das in dem itoa aufruf 
irgendwas schief läuft. Aber was. Ich habe nun stundenlang rumgegoogelt 
und bisher nur verweise auf "sprintf" gefunden, damit klappt es 
grundsätzlich auch....aber nur EINMAl. Die Zahl wird richtig ausgegeben 
per UART, jedoch hängt sich dabei der Simulator scheinbar immer ziemlich 
auf (er pausiert dann duaernd obwohl es keine breakpoints gibt und der 
PC scheint immer nur im Kreis zu laufen jedoch kann ich an die 
entsprechende Stelle im Code springen....kein plan) da ich aber eh 
gelesen habe das sprintf sehr ressourcenfressend sein soll würde ich 
gerne itoa nutzen das ja eigentlich genau da machen sollte was ich will.

Jemand eine Idee was ich falsch mache? Ich werd bekloppt.

Sofern es wichtig ist hier nur die includes:

#include <p18F13K50.h>
#include <stdio.h>
#include <stdlib.h>
#include <timers.h>
#include <capture.h>
#include <usart.h>
#include <delays.h>

[Peter II (Gast)]

>  unsigned int numberToPrint = 12345;
>  char str[5];
passt ja auch nicht zusammen, ein string braucht am ende ein \0. Also 
brauchst du für 12345 mindestens 6 zeichen.

[Paul K. (paul-cgn)]

Hoppala, danke dir für die schnelle Antwort, das war aber nicht das 
Problem, nur st der Wert der ausgebeben wird halt:

24880

Code also jetzt:

            unsigned int numberToPrint = 12345;
            char str[6];
            itoa(numberToPrint, (char*) str);
            putsUSART((char*) str);

[jibi (Gast)]

C-Buch!

Langsam nervt ihr...

Gruß Jonas

[jibi (Gast)]

Und weil eh gleich die Frage kommt, bin ich mal so nett:

http://openbook.galileocomputing.de/c_von_a_bis_z/

Gruß jibi

[Karl H. (kbuchegg)]

Paul K. schrieb:
> Hoppala, danke dir für die schnelle Antwort, das war aber nicht das
> Problem, nur st der Wert der ausgebeben wird halt:
>
> 24880

Spätestens jetzt ist ein Blick ins Compiler-Handbuch angebracht bzw. in 
sonstige Doku.

Denn auch wenn itoa keine C-Standardfunktion ist, so sind doch die 
Paramter bei so gut wie allen Implementierungen gleich. Nämlich

char *  itoa ( int value, char * str, int base );

die dritte Angabe, die Zahlenbasis fehlt bei deinem itoa. Damit ist 
klar, dass das irgendeine compilerspezifische Spezialversion deines 
Compilers ist. Und da hilft dann nur noch ein Blick in die Doku.

[Rufus Τ. F. (rufus)]

Paul K. schrieb:
> unsigned int numberToPrint = 12345;
> char str[5];

Das ist zu wenig.

Wie lang ist ein String, in den 5 Zeichen passen?

Richtig: 6 Zeichen. Nie die abschließende \0 vergessen.

Also muss es (mindestens) heißen:

> char str[6];

itoa erwartet einen int, kein unsigned int. Also wird, sofern der Wert 
größer ist als 32767, der Wert als negativer Wert interpretiert und noch 
ein Minuszeichen davor ausgegeben. Damit muss Dein Puffer noch Platz für 
ein weiteres Zeichen bieten.

> char str[7];

Dieses Puffergrößenproblem wird die Ursache dafür sein, daß Dein 
printf-Versuch nur einmal glückt -- danach ist irgendwelcher Speicher 
überschrieben und es können merkwürdige Dinge geschehen.


Initialisiere Deinen Puffer, bevor Du itoa aufrufst, dann kannst Du 
überprüfen, ob diese Funktion überhaupt irgendwas macht.




> itoa(numberToPrint, (char*) str);
> putsUSART((char*) str);

Was soll hier der Typecast nach char*?

[Karl H. (kbuchegg)]

Im übrigen ist itoa sowieso die falsche Funktion. itoa will einen int - 
also signed. Du hast keinen int. Du hast einen unsigned int. Die 
korrekte Funktion dafür ist utoa und nicht itoa. Das erklärt allerdings 
nicht die Diskrepanz bei diesem Zahlenwert.

[Paul K. (paul-cgn)]

Karl Heinz Buchegger schrieb:
> Paul K. schrieb:
>> Hoppala, danke dir für die schnelle Antwort, das war aber nicht das
>> Problem, nur st der Wert der ausgebeben wird halt:
>>
>> 24880
>
> Spätestens jetzt ist ein Blick ins Compiler-Handbuch angebracht bzw. in
> sonstige Doku.
>
> Denn auch wenn itoa keine C-Standardfunktion ist, so sind doch die
> Paramter bei so gut wie allen Implementierungen gleich. Nämlich
>

> char *  itoa ( int value, char * str, int base );
>

> die dritte Angabe, die Zahlenbasis fehlt bei deinem itoa. Damit ist
> klar, dass das irgendeine compilerspezifische Spezialversion deines
> Compilers ist. Und da hilft dann nur noch ein Blick in die Doku.

Das das keine C-Standardfunktion ist war mir bekannt, daher hilft mir 
der Galileo link nicht so recht weiter.

Bei dem C18 Compiler (v3.41) den ich verwende ist die Signatur jedoch 
abweichend zu deinem Beispiel nur mit zwei Parametern (wie ich oben 
bereits geschrieben habe, da war der Auszug aus der stdlib.h die zum 
Lieferumfang des C18 gehört). Ausserdem ware die Signatur abweichend 
würde das ganze ja nicht mal kompilieren, das tut es aber ohne murren.

Die Doku der Funktion selbst hilft mir nicht so recht weiter:

char *itoa (auto int value, auto char *s);
/** @name ltoa
 * The {\bf ltoa} function converts the {\bf long} value {\bf value} to 
 * a radix 10 string representation, storing the resultant string into
 * the location pointed to by {\bf s}.
 *
 * The {\bf ltoa} function is an MPLAB-Cxx extension to the ANSI required
 * libraries and may not be present in other implementations.
 * @param value value to convert
 * @param s pointer to destination string object
 * @return The {\bf ltoa} function returns the value of {\bf s}.
 */

Leider auch im Handbuch keine weiteren Hinweise oder Beispiele.

[Paul K. (paul-cgn)]

Karl Heinz Buchegger schrieb:
> Im übrigen ist itoa sowieso die falsche Funktion. itoa will einen int -
> also signed. Du hast keinen int. Du hast einen unsigned int. Die
> korrekte Funktion dafür ist utoa und nicht itoa. Das erklärt allerdings
> nicht die Diskrepanz bei diesem Zahlenwert.

Danke für deine Antwort Karl Heinz, das mit dem "unsigned int" vs "int" 
habe ich auch schon durch, leider absolut gleiches Ergebnis, es macht 
keinen unterschied in dem Fall.

[Dirk (Gast)]

Versuch mal
str = itoa(numberToPrint, (char*) str);

>  * @return The {\bf ltoa} function returns the value of {\bf s}.
>  */[/C]

[Karl H. (kbuchegg)]

Wie oft hast du in deinem restlichen Programm diesen Array_zu_klein 
Fehler noch gemacht?

Auf Deutsch: So ist erst mal kein Problem mehr ersichtlich. Das es 
trotzdem nicht funktioniert kann natürlich auch daran liegen, dass im 
restlichen Programm noch so einiges nicht stimmt und du das System 
zerschossen hast.


----> minimales Beispielprogramm zusammenstellen und posten.
am besten ein Beispielprogramm, welches tatsächlich nur dieses utoa und 
die UART Ausgabe enthält und sonst nichts anderes.

[Peter II (Gast)]

Dirk schrieb:
> Versuch mal
> str = itoa(numberToPrint, (char*) str);

das ist doch unsinn, wie soll man denn str ändern können, wenn es eine 
array auf dem Stack ist.

[Paul K. (paul-cgn)]

Rufus Τ. Firefly schrieb:
> Paul K. schrieb:

> itoa erwartet einen int, kein unsigned int. Also wird, sofern der Wert
> größer ist als 32767, der Wert als negativer Wert interpretiert und noch
> ein Minuszeichen davor ausgegeben. Damit muss Dein Puffer noch Platz für
> ein weiteres Zeichen bieten.
>
>> char str[7];
>
> Dieses Puffergrößenproblem wird die Ursache dafür sein, daß Dein
> printf-Versuch nur einmal glückt -- danach ist irgendwelcher Speicher
> überschrieben und es können merkwürdige Dinge geschehen.

Hallo Rufus, vielen Dank für deine Antwort. Ich habe auch mit einer 
Array-Größe von 7 das gleiche Problem.
Bei dem printf nutze ich übrgens den char[] garnicht, da übergebe ich 
schlicht die int variable und lasse printf die Formatierung machen (%i). 
Somit ist die Lange da vermultich nicht das Problem gewesen
>
>
> Initialisiere Deinen Puffer, bevor Du itoa aufrufst, dann kannst Du
> überprüfen, ob diese Funktion überhaupt irgendwas macht.
>
hab ich gemacht, initialisiert mit "000000" (im debugger verifziert, war 
"000000\u0x0") und dann nach dem itoa nochmal geprüft, steht dann auch 
der neue "24880\u0x0\u0x0"

>
>
>> itoa(numberToPrint, (char*) str);
>> putsUSART((char*) str);
>
> Was soll hier der Typecast nach char*?

Der Typecast ist nur für den Compiler damit er nicht meckert. Er macht 
sonst einen impliziten Cast aber gibt immer eine Warnung aus, mit dem 
cast kommt die halt nicht, hat also rein optische Gründe beim 
kompilieren. Macht keinen unterschied bezüglich der Konvertierung in der 
itoa

[Steel (Gast)]

Versuch mal

static char str[7];

statt

char str[5];

[Paul K. (paul-cgn)]

Steel schrieb:
> Versuch mal
>
> static char str[7];
>
> statt
>
> char str[5];

Leider kein Erfolg.
Hier nun der gesammte Code mit allem anderen Entfernt (naja fast, die 
Config bits sind sicherlich nicht alle nötig) was nicht nötig ist für 
das Beispiel, die Ausgabe ist noch immer die selbe in der Console 
(24880).

#include <p18F13K50.h>
#include <stdlib.h>
#include <usart.h>
#include <delays.h>

// PIC18F13K50 Configuration Bit Settings
// CONFIG1L
#pragma config CPUDIV = NOCLKDIV// CPU System Clock Selection bits (No CPU System Clock divide)
#pragma config USBDIV = OFF     // USB Clock Selection bit (USB clock comes directly from the OSC1/OSC2 oscillator block; no divide)

// CONFIG1H
#pragma config FOSC = IRC       // Oscillator Selection bits (Internal RC oscillator)
#pragma config PLLEN = OFF      // 4 X PLL Enable bit (PLL is under software control)
#pragma config PCLKEN = ON     // Primary Clock Enable bit (Primary clock is under software control)
#pragma config FCMEN = OFF      // Fail-Safe Clock Monitor Enable (Fail-Safe Clock Monitor disabled)
#pragma config IESO = OFF       // Internal/External Oscillator Switchover bit (Oscillator Switchover mode disabled)

// CONFIG2L
#pragma config PWRTEN = ON      // Power-up Timer Enable bit (PWRT enabled)
#pragma config BOREN = OFF      // Brown-out Reset Enable bits (Brown-out Reset disabled in hardware and software)
#pragma config BORV = 19        // Brown-out Reset Voltage bits (VBOR set to 1.9 V nominal)

// CONFIG2H
#pragma config WDTEN = OFF      // Watchdog Timer Enable bit (WDT is controlled by SWDTEN bit of the WDTCON register)
#pragma config WDTPS = 32768    // Watchdog Timer Postscale Select bits (1:32768)

// CONFIG3H
#pragma config HFOFST = OFF      // HFINTOSC Fast Start-up bit (HFINTOSC starts clocking the CPU without waiting for the oscillator to stablize.)
#pragma config MCLRE = ON       // MCLR Pin Enable bit (MCLR pin enabled; RA3 input pin disabled)

// CONFIG4L
#pragma config STVREN = ON      // Stack Full/Underflow Reset Enable bit (Stack full/underflow will cause Reset)
#pragma config LVP = OFF        // Single-Supply ICSP Enable bit (Single-Supply ICSP disabled)
#pragma config BBSIZ = OFF      // Boot Block Size Select bit (512W boot block size)
#pragma config XINST = OFF      // Extended Instruction Set Enable bit (Instruction set extension and Indexed Addressing mode disabled (Legacy mode))

// CONFIG5L
#pragma config CP0 = OFF        // Code Protection bit (Block 0 not code-protected)
#pragma config CP1 = OFF        // Code Protection bit (Block 1 not code-protected)

// CONFIG5H
#pragma config CPB = OFF        // Boot Block Code Protection bit (Boot block not code-protected)
#pragma config CPD = OFF        // Data EEPROM Code Protection bit (Data EEPROM not code-protected)

// CONFIG6L
#pragma config WRT0 = OFF       // Table Write Protection bit (Block 0 not write-protected)
#pragma config WRT1 = OFF       // Table Write Protection bit (Block 1 not write-protected)

// CONFIG6H
#pragma config WRTC = OFF       // Configuration Register Write Protection bit (Configuration registers not write-protected)
#pragma config WRTB = OFF       // Boot Block Write Protection bit (Boot block not write-protected)
#pragma config WRTD = OFF       // Data EEPROM Write Protection bit (Data EEPROM not write-protected)

// CONFIG7L
#pragma config EBTR0 = OFF      // Table Read Protection bit (Block 0 not protected from table reads executed in other blocks)
#pragma config EBTR1 = OFF      // Table Read Protection bit (Block 1 not protected from table reads executed in other blocks)

// CONFIG7H
#pragma config EBTRB = OFF      // Boot Block Table Read Protection bit (Boot block not protected from table reads executed in other blocks)

//----------------------------------------------------------------------------

void main(void);
//----------------------------------------------------------------------------
// Main routine
void main() {
    OSCCONbits.IRCF = 0b101;
    OpenUSART(USART_TX_INT_OFF & // Trasnmit interrupt off
            USART_ASYNCH_MODE & // Use USART in asynchronous mode
            USART_EIGHT_BIT & // Eight bits for data
            USART_CONT_RX &// Enable continous receiving
            USART_BRGH_LOW, // Dont use baud rate multiplier
            12); // SPBRG value for a BR of 9600

    while (1) {
        int numberToPrint = 12345;
        static char str[7] = "000000";
        itoa(numberToPrint, str);
        putsUSART(str);
        Delay10KTCYx(10);
    }
}

[Steel (Gast)]

Kommentier mal das itoa aus.

so:
        static char str[7] = "12345";
   //     itoa(numberToPrint, str);
        putsUSART(str);

btw: Du hattest schon wieder eine '0' zu viel in deinem String!!!

[Karl H. (kbuchegg)]

> Der Typecast ist nur für den Compiler damit er nicht meckert. Er macht sonst 
einen impliziten Cast

Ein Cast von char* auf char*
Und dann verschwindet eine Warnung des Compilers?

Da steckt mehr dahinter, das muss dich stutzig machen.
Wie lautet die Warnung?

[Paul K. (paul-cgn)]

Steel schrieb:
> Kommentier mal das itoa aus.
>
> so:
>         static char str[7] = "12345";
>    //     itoa(numberToPrint, str);
>         putsUSART(str);
>
> btw: Du hattest schon wieder eine '0' zu viel in deinem String!!!

Ausgabe ist korrekt via UART: 00000
wie gesagt text geht ja auch korrekt über UART, U(S)RAT selbst scheint 
also richtig konfiguriert.
(Null habe ich auch entfernt)

[Paul K. (paul-cgn)]

Karl Heinz Buchegger schrieb:
>> Der Typecast ist nur für den Compiler damit er nicht meckert. Er macht sonst
> einen impliziten Cast
>
> Ein Cast von char* auf char*
> Und dann verschwindet eine Warnung des Compilers?
>
> Da steckt mehr dahinter, das muss dich stutzig machen.
> Wie lautet die Warnung?

Hallo Heinz, sorry, da hab ich tatsächlich einen Cast zu viel gemacht, 
wie du oben im Beispiel siehst, ist der Cast nun raus (uns es kommt 
keine Warnung).
Einen Cast musste ich nur bei einem putrsUSART(...) machen:
putrsUSART((const rom far char *)"\r\nNothing to do");
Aber das ist in dem Beispiel nicht mehr drinnen und soll nun auch nicht 
weiter Thema sein.

Das kommt dabei raus wenn man stundenlang nach jedem Zweig greift um das 
Problem zu beheben :-)

[Steel (Gast)]

itoa mal mit anderen Zahlen gefütter? Was passiert bei ner Null? Den 
Wert mal als Konstante direkt beim itoa aufruf reingeschrieben?

[Jürgen S. (Firma: privat) (jschmied)]

Hallo!

Probier doch mal das Minimum im Simulator aus:

void main() {
    int numberToPrint = 12345;
    char str[7] = "000000";
    itoa( numberToPrint, str );
}

Im Schrittmodus steht nach itoa bei mir tatsächlich "12345\\0\\0" im 
String.
Alles andere hätte mich auch gewundert ...

vg

Jürgen

[Karl H. (kbuchegg)]

Paul K. schrieb:

> Das kommt dabei raus wenn man stundenlang nach jedem Zweig greift um das
> Problem zu beheben :-)

OK. mach mal folgendes.
Schreib eine eigene Version von itoa

void myUtoa( unsigned int num, char* str )
{
  unsigned char i;

  for( i = 0; i < 5; ++i )
  {
    str[4-i] = ( num % 10 ) + '0';
    num = num / 10;
  }
  str[5] = '\0';
}

damit man mal feststellen kann, ob es ein Problem mit dem utoa oder mit 
den UART Sachen im Zusammenhang mit char-Arrays gibt, die vom Optimizer 
(wegen dem ihm bekannten konstanten String) bereinigt hat.

[Paul K. (paul-cgn)]

Jürgen Schmied schrieb:
> Hallo!
>
> Probier doch mal das Minimum im Simulator aus:
>
> void main() {
>     int numberToPrint = 12345;
>     char str[7] = "000000";
>     itoa( numberToPrint, str );
> }
>
> Im Schrittmodus steht nach itoa bei mir tatsächlich "12345\\0\\0" im
> String.
> Alles andere hätte mich auch gewundert ...
>
> vg
>
> Jürgen

Hab folgendes super minimal program probiert:

#include <stdlib.h>
#include <delays.h>

//----------------------------------------------------------------------------

void main(void);
//----------------------------------------------------------------------------
// Main routine
void main() {

        int numberToPrint = 12345;
        static char str[7] = "00000";
        itoa(numberToPrint, str);
        Nop();
}

Leider steht nach dem itoa
rommelwirbel
wieder "24880\u0x0\u0x0" als wert drin :-(

[Paul K. (paul-cgn)]

Karl Heinz, danke dir! Mit deiner customer Funktin geht es :-))))))

Wobei mir absolut nicht klar ist warum die itoa vom c18 compiler nicht 
geht :-(

[Jürgen S. (Firma: privat) (jschmied)]

Sehr komisch. Bei mir (MPLABX 1.85 & C18 3.46 & Debugger = Simulator) 
geht es !

[Paul K. (paul-cgn)]

nutze noch MPLAB X v 1.30
Vielleicht sollte ich mal updaten :-)

[Jürgen S. (Firma: privat) (jschmied)]

Prüfe mal den Bibliothekspfad vieleicht hast Du XC8 und C18 Bibliotheken 
gemeinsam auf Deinem Rechner ???
Oder zwei Versionen des C18? MPLAB alt??

[Paul K. (paul-cgn)]

Jürgen Schmied schrieb:
> Prüfe mal den Bibliothekspfad vieleicht hast Du XC8 und C18 Bibliotheken
> gemeinsam auf Deinem Rechner ???
> Oder zwei Versionen des C18? MPLAB alt??

XC8 hab ich nicht drauf, hab noch einen C30 Compiler drauf, aber C18 ist 
auf default und auch nur der ist in dem Projekt angewählt.
Pfade sind alle Standard, da hab ich nix angepast.

Ich werde mal mplab x neu installieren, wollte das eh in eine virtuelle 
Maschine umziehen. Dann ist alles Frisch und dann versuche ich es 
nochmal.

Vielen Dank an alle die konstruktiv geantwortet haben!

[Jürgen S. (Firma: privat) (jschmied)]

>Karl Heinz, danke dir! Mit deiner customer Funktin geht es :-))))))

Ich würde dem Frieden nicht trauen. itoa läuft nicht erst seit der 
letzten Version des Compilers. Wenn Du die jetzt selbst realisierst 
wette ich, dass es bei einer der nächsten Bibliotheksfunktionen 
knallt...
Das ist irgendetwas Grundlegendes falsch.
Schau mal ins Disassembly-listing, welche itoa überhaupt reingelinkt 
wird - da stehen Dateinamen der Quellen drin.

vg

Jürgen

[Paul K. (paul-cgn)]

Jürgen Schmied schrieb:
>>Karl Heinz, danke dir! Mit deiner customer Funktin geht es :-))))))
>
> Ich würde dem Frieden nicht trauen. itoa läuft nicht erst seit der
> letzten Version des Compilers. Wenn Du die jetzt selbst realisierst
> wette ich, dass es bei einer der nächsten Bibliotheksfunktionen
> knallt...
> Das ist irgendetwas Grundlegendes falsch.
> Schau mal ins Disassembly-listing, welche itoa überhaupt reingelinkt
> wird - da stehen Dateinamen der Quellen drin.
>
> vg
>
> Jürgen

Danke dir Jürgen das du der Sache noch auf den Grund gehen willst.
Im Disassembly-Listing steht tatsächlich ein Pfad drin 
"C:/MCC18/src/traditional/stdclib/itoa.asm" den es garnicht gibt(!). [Da 
ist auch kein unsichtbarer Systemordner oder sowas] Aber woher kommt 
dann der assembler code dazu her? Wie dem auch sei, ich habe eingesehen 
das mit meiner Installation wohl was im Eimer ist. Ich werde euch 
nochmal berichten wenn es Frisch aufgesetzt ist.

[Karl H. (kbuchegg)]

Paul K. schrieb:

> Im Disassembly-Listing steht tatsächlich ein Pfad drin
> "C:/MCC18/src/traditional/stdclib/itoa.asm" den es garnicht gibt(!). [Da
> ist auch kein unsichtbarer Systemordner oder sowas] Aber woher kommt
> dann der assembler code dazu her?

langsam.
Der Originalcode stand mal auf diesem Verzeichnis.
Irgendwer hat dann mal alle Einzelteile, die zusammen die 
Standard-Library bilden hergenommen und eine echte Library gebaut, die 
vom Linker dann als Ganzes mit dazugelinkt wird.

Jetzt erhebt sich die Frage, ob jemand anderer, der dasselbe System hat, 
dasselbe ausprobiert und dort die gleichen Pfade sieht oder nicht.

[Jürgen S. (Firma: privat) (jschmied)]

Habe im Angebot:

E:/c18v3.46/pic18-lt/cxx-framework/src/traditional/stdclib/itoa.asm

Die Verzeichnisnamen sehen nach einer Umorganisation aus. Hole Dir doch 
mal den neusten C18 Compiler.

vg

Jürgen

[Paul K. (paul-cgn)]

So, kurzes update: Nach Neuinstallation von MPLAB X (v1.90) und C18 
Compiler klappt nun alles. Naja, zumindest mit dem itoa.
Beim Versuch den pic zu programmieren hat mir MPLAB X dann beim Download 
einer neuen Firmware mit neuem 'AP' und 'RS' den Pickit3 gebricked, 
jetzt steht ich erst mal wieder ohne da und er wird nicht mehr erkannt 
unter windows :-(
Aber das andere Problem ist gelöst.