MPLABX XC8 et CCI Common C Interface

[paulfjujo]

Bonsoir Satinas , et à tous


Utilises-tu le mode CCI= Common C Interface de MPLABX
CCI = Common C Interface
Use the CCI extensions rather than the native language extensions.
The CCI allows enhanced portability by refining implementation-defined behavior and
standardizing the syntax for extensions to the language.
For your project to conform to the CCI, you must do the following things.
• Enable the CCI
Select the MPLAB X IDE widget Use CCI Syntax in your project

A priori , cela remet en cause de multiples syntaxes pour les MCU 8 bits,
mais cette syntaxe sera obligatoire pour les MCU 16,24,32 bits ..
Crois-tu qu'il faille s'y mettre des maintenant ? (meme en restant sur les 8 bits MCU)

doc située dans
file:///C:/Program%20Files%20(x86)/Microchip/xc8/v2.10/docs/MPLAB_XC8_C_Compiler_Legacy_User_Guide.pdf

MPLABX_XC8_Use_CCI_Syntax.jpg

une question :
J'essaie d'eliminer toute une floppée de warning, en l'occurence celui-ci:
warning: (373) implicit signed to unsigned conversion
via cette directive Pragma..

Code : Tout sélectionner

#pragma warning disable 373     

qui est inefficace !
ou alors je ne la place pas au bon endroit ? ( en tête du main.c et des includes)

[satinas]

Bonsoir à tous,

Paul, je travaille avec les options par défaut (C99, CCI non coché, warning level à -3)
Ma politique c'est plutôt de modifier le source (cast explicite) pour supprimer ce type de warning. Le passage signed <=> unsigned est assez rare si le type des différentes variables est déclaré correctement.

Après quelques essais, je n'arrive pas non plus à inhiber le warning 373, que CCI soit coché ou non. En fait le warning s'affiche toujours quelque soit le réglage du compilateur.

Code : Tout sélectionner

  #pragma warning disable 373   
  unsigned int d = -1;
  #pragma warning enable 373   

  lcd.c:15:20: warning: implicit conversion changes signedness: 'int' to 'unsigned int' [-Wsign-conversion]


En ajoutant l'option compilateur -wconversion le warning disparaît par miracle, pas vu dans la doc, mais trouvé là https://www.microchip.com/forums/m1151831.aspx

Le passage à CCI me semble intéressant, il faudra modifier certaines syntaxes, notamment pour les adresses absolues, les lignes config hardware, les inserts asm, les fonctions interrupt.

[Claudius]

Bonjour,

Privilégier avant de piloter le compilateur de l'intérieur ou de l'extérieur (solution qui ne sera pas portable), l'utilisation de la syntaxe du cast avec ici (solution portable car syntaxe spécifiée dans le Langage C et C++ ;-):

Code : Tout sélectionner

unsigned int d = (unsigned int)-1;


[paulfjujo]

bonjour à tous,

Merci à vous deux,pour les infos..

je ne veux pas déclencher de polémique, mais pourquoi vouloir faire
"compliqué quand on peut faire simple"
et utiliser du C++ ou une couche langage HAL ou SDK spécifiques à un MCU ou Carte MikroE, pour de simple MCU 8 bits
c'est un marteau pilon pour enfoncer une punaise
.. en fait la tendance serait de faire du PIC-SIMILI-ARDUINO
voir NECTO STUDIO de MikroE ( qui va remplacer MikroC Pro )

Que ça soit utilisé sur des MCU 32 bits ou DSP , ne me titillerait pas.

Quand je vois la floppée de Warning 373 ... alors que je n'ai pas besoin de byte signés ..
cette histoire de signed par défaut est tres perturbante pour moi,
puisque par defaut sur MikroC , c'est unsigned !

Code : Tout sélectionner


char c3;
signed char c4;
// .... test .....
                 // result
   c3=129;  // 129
    c4=129; // -127
    c3=255;  // 255
    c4=-1;    //  -1
     

et aucun warning !

cette syntaxe
unsigned int d = (unsigned int)-1;
est vraiment lourdingue ! (meme si elle est efficace ,voir preconisée)

car pour moi , c'est plutot l'usage qu'on en fait qui fait le signe !
en asm , c'est bien par le programme qu'on décide si la variable "byte" sera traitée comme signée ou non ?

le compilateur a donc tendance à forcer l'usage de signed int à la place du format 8 bits, pour etre tranquille
exemple : parametres pour I2C !
( peut etre aussi pour le format adresse 10 bits I2C)
mais sur un MCU 8 bits , c'est du gaspillage
Mais pas étonnant, vu que la tendance du compilo va vraiment pour l'usage des 16,24,32 bits MCU ..
si on voit les obligations du passage à CCI .
alors pourquoi XC8

[Claudius]

Une précision importante des spécifications du Langage C:

Par défaut, les types entiers short, int, long sont munis d'un signe (il sont donc par défaut signés)

Par contre, le type par défaut de char est dépendant du compilateur et peut être signed ou unsigned
=> C'est de là que vient tous les problèmes de portabilité, de warning, voire de dysfonctionnements; à savoir: Aucune spécification sur le char ... c'est dépendant du compilateur

[satinas]

Bonjour, en accord avec Claudius

Code : Tout sélectionner

  char c;                 // non signé en xc8 (plain char)
  signed char s;          // signé
  unsigned char u;        // non signé

  c = 130;
  c = -10;                // warning xc8
  s = 130;                // warning xc8
  s = -10;
  u = 130;
  u = -10;                // warning xc8

  s = c;                  // warning xc8
  u = c;


[Claudius]

paulfjujo a écrit:
le compilateur a donc tendance à forcer l'usage de signed int à la place du format 8 bits

Une autre remarque par rapport au "int (signé ou pas signé) à la place du format 8 bits"
=> Cela n'est pas conforme aux spécifications du Langage C

En effet, la taille d'un int est fonction de la capacité du µC à traiter la valeur dans la plage [-32768, +32767] (valeur sur 16 bits) ou [-2147483648, +2147483647] (valeur sur 32 bits) et ce, directement et d'une manière atomique au travers de ses registres
=> Donc un int (signé ou pas signé) est codé sur 2 octets sur les µC 16 bits et sur 4 octets sur les µC 32 bits

Maintenant, paradoxalement et en toute rigueur, même sur un µC 8 bits, un int doit être considéré comme codé sur 2 octets (toujours pour un soucis de portabilité et de respect de la spécification ;-)

Donc, si l'on souhaite manipuler une valeur dont on sait qu'elle est dans la plage [-128, +127] (1 octet), il faut la déclarer en char signé (à préciser suivant le compilateur). Dans la plage [0, 255] (1 octet), il faut la déclarer en char non signé (toujours à préciser suivant le compilateur)

C'est la raison pour laquelle, les types suivants 'byte' (pour le char), 'int8_t', 'uint8_t', 'int16_t', 'uint16_t', 'int32_t', etc. ont été créés (mais que l'on peut créer soit-même) en surcouche des types de base et qui ont l'avantage d'être sans ambiguïté quant à la taille de leur représentation, qui facilitent grandement la lecture du programme et surtout le portage entre plates-formes d'architecture différente 8, 16 ou 32 bits du µC ou même entre langages comme Langage C <-> Java

Cf. Programmation C/Types de base

NB1: @Portage Langage C <-> Java, il est impératif de connaître les spécifications de Java qui a l'avantage d'avoir spécifié tous les types de base quelle que soit la plate-forme 8, 16 ou 32 bits: cf. Programmation Java/Types de base

NB2: Désolé d'avoir été un peu long (≥ 32 bits en Langage C ;-), mais l'appropriation d'un langage passe par la connaissance de ses spécifications, de son modèle mémoire et de son écosystème (compilateurs ouverts et libres type gcc/g++ qui respectent les spécifications, packages, sources de la librairie de base, projets Open Source, communauté active, etc.) ... la syntaxe étant très importante mais secondaire à mon avis (car très proche entre les langages informatiques avec des faux-amis comme avec les langues écrites et parlées). Malheureusement, on a trop tendance à mette la syntaxe en avant plan, ce qui est une grave erreur à mon sens...

[Jérémy]