Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : Jérémy
MPLABX XC8 et CCI Common C Interface
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
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
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..
qui est inefficace !
ou alors je ne la place pas au bon endroit ? ( en tête du main.c et des includes)
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
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)
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
MPLABX XC8 et CCI Common C Interface
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.
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.
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.
MPLABX XC8 et CCI Common C Interface
- Claudius
Passioné- Messages : 260
- Âge : 69
- Enregistré en : septembre 2015
- Localisation : ELANCOURT (78 - YVELINES)
- Contact :
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++ ;-):
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;
Enregistreur de traces GPS & Boussole GPS parlante (PIC & Arduino)
MPLABX XC8 et CCI Common C Interface
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
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 !
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
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
MPLABX XC8 et CCI Common C Interface
- Claudius
Passioné- Messages : 260
- Âge : 69
- Enregistré en : septembre 2015
- Localisation : ELANCOURT (78 - YVELINES)
- Contact :
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
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
Enregistreur de traces GPS & Boussole GPS parlante (PIC & Arduino)
MPLABX XC8 et CCI Common C Interface
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;
MPLABX XC8 et CCI Common C Interface
- Claudius
Passioné- Messages : 260
- Âge : 69
- Enregistré en : septembre 2015
- Localisation : ELANCOURT (78 - YVELINES)
- Contact :
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...
Enregistreur de traces GPS & Boussole GPS parlante (PIC & Arduino)
MPLABX XC8 et CCI Common C Interface
Qui est en ligne
Utilisateurs parcourant ce forum : Bing [Bot] et 28 invités