Messwert-Variablen auf LCD 16x2 ausgeben, will nicht per ITOA klappen

[Klebwax]

Halle Freunde !

Vieleicht habe ich mich wieder selbst verrant, aber ich komme einfach nicht weiter.
Ich möchte Messwerte(Intergerwerte) auf einen Kontrolldisplay(Test mit 16x2) ausgeben. Aber das umwandlen der Integerwerte in einen String, den ich auf das LCD schreiben kann klappt nicht.
Vielleicht fasse ich die Sache auch komplett falsch an. zu Testzwecken habe ich den Integer einfach mal mit einem Wert 250 belegt. Hier mein Code:

/**********************************************************************/
//
//  Microchip MPLABX  XC8 Compiler
//
/*********************************************************************/

typedef unsigned char  uChr;

/* ================================================================== */
/*                                                                    */
/*               LCD-Write uChar                                      */
/*                                                                    */
/* ================================================================== */

void Lcd_Write_Char(uChr a)
{
    RS=1;                // => RS = 1
    PDAT=a ;             // => Datenport = a
    EN = 1;              // => E = 1
    __delay_ms(1);
    EN = 0;              // => E = 0
    __delay_ms(1);
}

/* ================================================================== */
/*                                                                    */
/*               LCD-Write String                                     */
/*                                                                    */
/* ================================================================== */

void Lcd_Write_String(uChr *a)
{
     while(*a)  // bis Stringende( = 0)
     {
     Lcd_Write_Char( *a );
     a++;
     }
}

/**********************************************************************/

void main(void)
{   
    Lcd_Init();

    char Buffer[10];
    int i = 250; // Vorgegebener Wert zum Test

    itoa( i, Buffer, 10 );

    Lcd_Write_String(Buffer);

        while(1); // im Testmodus hier Halt
}

/**********************************************************************/

Lcd_Write_String(Buffer) ist was immer bekrittelt wird vom Compiler : mein_lcd_16_2.c:71: warning: (357) illegal conversion of integer to pointer

Nun verstehe ich nicht das es auf einen Integer bezogen ist, wo doch Buffer ein Chararray bzw String ist.

Du bist in eine böse Falle getapt. An deinem Code ist eigentlich alles ok. Dein eigener Typ uChr hat dir zusätzlich die Sicht versperrt, lass ihn einfach weg. Ein String besteht aus chars, das reicht. Und wenn dein Datenport mit 8-Bit unsigned angesprochen werden will, dann caste vor der Ausgabe den char zum Standarddatentyp uint8_t (PDAT = (uint8_t)a;).

Die Funktion itoa ist beim XC8 falsch implementiert. In den üblichen Dokumentationen kommt als Parameter zuerst der Integer und dann der String. Bei XC8 gehts genau anders herum. Daher hat er an erster Stelle bei deinem Aufruf von itoa einen Pointer erwartet, von dir aber einen Integer bekommen. Soweit ist die Fehlermeldung ok. Das Problem geht aber tiefer. Ich hab mal geschaut, ob diese Problem nicht anderswo erkannt worden ist und bin auf follgendes gestoßen XC8 Version 2.xx. Da itoa() in C99 nicht Pflicht ist, kommt das bei V2.00 und neuer von XC8 gar nicht mehr vor. du solltest also sprintf(Buffer, "%d", i); verwenden, das klappt dann auch mit den neuen Compilerversionen (ich bin bei V2.05).

MfG Klebwax

P.S. Noch etwas zu deiner Funktion void Lcd_Write_Char(uChr a). Daß du einfach char nehmen soltest, hab ich schon gesagt. Das Delay von einer Millisekunde ist viel zu groß, eine Mikrosekunde oder ein NOP() reicht da. Und nachdem EN auf low gesetzt wird, braucht man gar kein Delay. Die Zeit, die der Prozessor für das Return und den nächsten Funktionsaufruf braucht reicht da vollkommen. Die Funktion ist also rund zweitausend mal zu langsam.

Und solche Kommentare wie " RS=1; // => RS = 1" sollte man vermeiden. Erstens sagt er das gleiche wie der Code, ist also überflüssig. Schlimmer aber, wenn du den Code mal änderst, wirst du den Kommentar nicht ändern. Dann stehen da zwei sich wiedersprechende Aussagen und machen dir das Leben schwer. Kommentieren sollte man nur, was nicht offensichtlich ist.

[oderlachs]

Hallo Klebwax !

Danke für Deine ausfühlichen Ratschläge.
Leider will der XC8 Compiler nichts mit uint8_t zu tun haben. Das ist auch noch ein weiteres Problem, das gewohnte C-Programmcode hier oft daneben geht.
Auch bin ich , neben früheren "Ein Zwei Mal" Anwendungen, erst ab Ende vergangenen Jahres PIC- und MPLab-Aktiv geworden..da habe ich noch jede menge Lernbedarf
Aber für meine Freizeitbeschäftigungs-Programmierung und Hobby, will ich nicht noch sonst was investieren(Compiler, IDEs usw.).

Gruss und Dank

Gerhard

[Klebwax]

Leider will der XC8 Compiler nichts mit uint8_t zu tun haben.

Das hat mit XC8 nichts zu tun. Kein C-Compiler kennt das, auch wenn man den GCC für einen PC benutzt. Er kennt nur char und int. Um dem Compiler die modernen Bezeichnungen der Datentypen näher zu bringen, muß stdint.h includiert werden. Kipp einfach mal uint8_t in Google. Wenn ich ein ähnliches Problem habe, mach ich das so. Auch wenn ich eine Fehlermeldung nicht wirklich verstehe, ist der erste Versuch sie einfach in Google zu pasten.

In MPLABX muß man das noch nichtmal wirklich schreiben. Einfach "#in" und schon bietet es "#include" an. Dann "<" und schon bekommt man alle Systemincludes angeboten. Mit "std" hat man dann die Standardincludes wie stdio.h, stdbool.h oder auch stdint.h in der Auswahl

Es ist das Prinzip von C, daß der Compiler selbst wenig weiß und kann, außer zu compilieren. Das meiste, das er zum Compilieren braucht, kommt aus Headerfiles, so auch die internen Register des jeweiligen Chips (xc.h plus die Projekteinstellung des Prozessors). Und was das Programm zum funktionieren braucht, kommt aus Libraries, zu allererst aus der libc. Und auch die kennt der Compiler nicht, wenn man sie ihm nicht z.B. stdio.h oder string.h bekannt macht.

MfG Klebwax

P.S. "gewohnter C-Programmcode" ist ein etwas problematischer Begriff. Insbesondere für kleine µC gab und gibt es Compiler, die sich nicht vollständig an die C Standards halten. XC8, ehemals HighTech, wird da gerade aufgefrischt.

[oberallgeier]

.. Leider will der XC8 Compiler nichts mit uint8_t zu tun haben ..

Hmmm, seltsam. Hast Du denn auch die <stdint.h> richtig eingebunden (#include ..) ? Denn

..
2.4.6 Sizes of TypesThe sizes of the basic C types, e.g., char, int and long, are not fully defined by the CCI. These types, by design, reflect the size of registers and other architectural fea-tures in the target device. They allow the device to efficiently access objects of this type. The ANSI C Standard does, however, indicate minimum requirements for these types, as specified in <limits.h>. If you need fixed-size types in your project, use the types defined in <stdint.h>, e.g., uint8_t or int16_t. These types are consistently defined across all XC compilers, even outside of the CCI.
..
2.4.6.3 MIGRATION TO THE CCI If you require a C type that has a fixed size, regardless of the target device, use one of the types defined by <stdint.h>
..

Und auch

..
2.4.1.1EXAMPLEThe following shows a string constant being defined that uses escaped characters.const char myName[] = "Bj\370rk\n";
..

Siehe z.B. diese Dokumentation.

Puhhh - Klebwax war schneller . . .

[HaWe]

viele C libs können mit den stdint Datentypen int8_t oder uint8_t nichts anfangen, selbst wenn stdint #included ist, sie ewarten die "genuinen" Typen char oder int, je nachdem, was halt in den libs steht und verwednet wird.
Selbst unsigned char oder signed char sind auf Lib- und Compilerebene nicht von vornherein mit char kompatibel, sie sind "etwas anderes".
cstring arbeitet ausschließlich mit char, mit nichts anderem.
Wenn ein cstring benutzt wird, muss also ein array of char übergeben werdem.

Haben die eigenen Daten eine andere Struktur, musst du sie vorher oder hinterher entsprechend explizit casten, was oft sehr umständlich ist, besser also, man verwendet von vornherein das, was die Lib erwartet.

char is signed on Intel (edit: and AVR) and unsigned on ARM (the Pi
(edit: ) and ARM Cortex M0 + M3 + M4 e.g., Zero +Due, and ESP)).
You cannot explicitly use "signed char" or "unsigned char" which, though legal types, are both distinct from the "char" type that library functions expect.
The only option if the type of char is important (which it often is) is to use the "-funsigned-char" compiler option. All C compilers have similar options.
"uint8_t" etc will fail when library functions are used.

https://www.raspberrypi.org/forums/v...d0047#p1429279

Das gilt also entsprechend verschärft für int8_t oder uint8_t und erst recht für selber definierte ganz "neue" Datentypen wie das "uChr " bei dir.

[oderlachs]

Hallo und Danke für Eure Hilfe und Erklärungen !!
Wie gesagt mit PIC und MPLab betrete ich für mich noch "Neuland", von einigen "Testseitensprüngen" mal abgesehen. Ich google auch schon wenn was nicht so funzt, sonst wäre ich noch gar nicht so weit.
Habe da solch "altes PIC-Büchlein" : "Programmieren von PIC Mikrocontrollern" - Der leichte Einstieg mit dem 16F84A von Dieter Kothz, das hat mich erst bewogen micht auf die PIC Ebene zu wagen.
Dann bekam ich günstig dieses "EasyPIC-40" Bord und da versuche ich mich nun drann, neben dem AVR-Chips, meine Freizeit "sinnvoll" zu verkürzen.

Gerhard

@Oberall : der Tip mit der "<stdint.h>" war gut , hatte die nicht immer im include , ich Trottel