Carte programmable en C

[Jack]

Comme le souligne JPL, le sujet est plus orienté électronique. La discussion va être transférée dans le forum adéquat.
-----

[PA5CAL]

Pour les ATmega328P, les règles concernant la configuration des entrées-sorties GPIO sont relativement simples et se limitent à celles que j'ai indiquées au début de mon post #46. Contrairement à certains autres micro-contrôleurs, il n'y a pas de paramétrage du courant de sortie ni d'autres fignolages du même genre.

Il faut néanmoins s'assurer qu'on ne dépasse pas les limites électriques du circuit, qui sont spécifiées au début du chapitre consacré à ce sujet dans la datasheet :

• Pour les entrées, la tension appliquée ne doit pas être inférieure à GND–0,5V ni supérieure à VCC+0,5V.

• Pour les sorties, il existe plusieurs limites concernant le courant qui les traverse, qui sont :
- 40 mA sur chaque sortie individuelle, mais il est conseillé de ne pas dépasser 20 mA lorsque VCC=5V ou 10 mA lorsque VCC=3V afin de ne pas perturber le fonctionnement des circuits internes ;
- 200 mA pour le courant traversant VCC, qui comprend le courant consommé en propre par le micro-contrôleur et les courants débités par les sorties à l'état haut ;
- 200 mA pour le courant traversant GND, qui comprend le courant consommé en propre par le micro-contrôleur et les courants drainés par les sorties à l'état bas ;
- 100 mA pour la somme des courants produits à l'état haut par les sorties C0 à C5, D0 à D4, ADC7 (si présente) et RESET ;
- 100 mA pour la somme des courants produits à l'état haut par les sorties B0 à B5, D5 à D7, ADC6 (si présente), XTAL1 et XTAL2 ;
(NB: bizarrement, sur les datasheets antérieures à 2016, ces deux dernières limites étaient données pour 150 mA)
- 100 mA pour la somme des courants drainée à l'état bas par les sorties C0 à C5, ADC6 et ADC7 (si présentes) ;
- 100 mA pour la somme des courants drainée à l'état bas par les sorties B0 à B5, D5 à D7, XTAL1 et XTAL2 ;
- 100 mA pour la somme des courants drainée à l'état bas par les sorties D0 à D4 et RESET.

Les sorties logiques d'un micro-contrôleur ne sont a priori conçues que pour piloter des entrées de circuits logiques, par nature essentiellement capacitives. On s'autorise néanmoins à leur faire piloter des charges qui consomment du courant de façon permanente, comme par exemple des leds, mais cela reste du bricolage dans la mesure où les spécifications fournies par les constructeurs restent trop limitées pour s'assurer des résultats obtenus (dans le cas présent, on ne dispose que des limites de courant et de courbes caractéristiques tension-courant typiques, c'est-à-dire seulement indicatives et sans aucune garantie).

On remarque qu'avec VCC=5V, il est possible de piloter 4 leds consommant chacune 20 mA sans dépasser les limites fixées quelle que soit la configuration retenue.

[PA5CAL]

Pour en revenir à la programmation, le principe est simple :
- sur l'ATmega328P, au démarrage toutes les broches d'entrée-sortie sont configurées en entrées (afin de présenter une haute impédance pour éviter les courts-circuits avec les composants environnants)
- on détermine quelles broches devront être configurées en entrée avec une résistance de rappel à VCC (typiquement connectées aux boutons sans résistance externe), pour lesquelles on devra positionner à 1 le bit correspondant dans le registre de sortie PORTx (où x est le nom du port)
- on détermine quelles broches devront être configurées en sortie, pour lesquelles on devra positionner à 1 le bit correspondant dans le registre de direction DDRx (où x est le nom du port)
- on détermine quelles sorties devront impérativement présenter un état déterminé avant l'initialisation du système, afin notamment de ne pas créer de dysfonctionnement dans l'appareil (typiquement, les commandes de puissance doivent être éteintes au démarrage). Pour ces sorties, l'état initial devra être écrit dans le registre PORTx correspondant avant que la broche ne soit configurée en sortie au travers du registre DDRx.

Si l'état initial des sorties est impératif, alors le début du programme consiste :
- à écrire d'abord dans les registres PORTx les bits à 1 correspondant aux sorties à l'état haut et aux entrées avec leur résistance de rappel activée,
- à écrire ensuite dans les registres DDRx les bits à 1 correspondant aux sorties.

Si l'état initial des sorties importe peu, alors on peut s'autoriser à inverser l'ordre de ces opérations.


Dans ton dernier exemple de programme (post #56), l'état initial des leds est sans conséquence sur le fonctionnement du système. On peut donc s'autoriser à écrire d'abord les registres DDRx pour configurer les broches en sortie, et laisser à la suite du programme le soin d'écrire les états dans les registres PORTx.

Si l'on branche les leds (avec chacune leur résistance de limitation) sur les broches PD2, PD3, PD4 et PD5, seuls les registres DDRD et PORTD doivent être manipulés. Pour configurer les broches en sortie, il faut mettre à 1 les bits 2, 3, 4 et 5 (ce qui correspond à la valeur 0x3C) dans le registre DDRD :

  DDRD |= 0x3C;

Si l'on souhaite rendre le code plus explicite, on peut exprimer cette valeur sous la forme d'un calcul utilisant les constantes fournies par le constructeur :

  DDRD |= (1<<DDD5) | (1<<DDD4) | (1<<DDD3) | (1<<DDD2);

Ensuite, dans la boucle while(1){...}, on change l'état de sortie des broches PD3, PD4 et PD5 afin de faire clignoter les leds. La led sur la broche PD2 reste allumée en permanence.

Si une led en série avec sa résistance de limitation est connectée entre une sortie et GND (cathode côté GND), alors elle s'allume lorsque la sortie est à l'état haut (bit à 1 dans PORTx) et s'éteint lorsque la sortie est à l'état bas (bit à 0 dans PORTx). Si elle est connectée entre une sortie et VCC (anode côté VCC), alors elle s'allume lorsque la sortie est à l'état bas (bit à 0 dans PORTx) et s'éteint lorsque la sortie est à l'état hauts (bit à 1 dans PORTx).

Dans ton exemple les leds sont connectées entre les sorties et GND. Pour commencer à allumer toutes les leds, on doit donc écrire un 1 dans chaque bit correspondant du registre PORTD :

  PORTD |= 0x3C;

ou :

  PORTD |= (1<<PORTD5) | (1<<PORTD4) | (1<<PORTD3) | (1<<PORTD2);

Puis, pour éteindre la led sur la sortie PD5, on doit passer à 0 le bit 5 du registre PORTD :

  PORTD &= 0xDF;

ou :

  PORTD &= ~(1<<PORTD5);

On fait de même avec la led sur la sortie PD4 :

  PORTD &= 0xEF;

ou :

  PORTD &= ~(1<<PORTD4);

puis avec la led sur la sortie PD3 :

  PORTD &= 0xF7;

ou :

  PORTD &= ~(1<<PORTD3);

En résumé, le code peut s'écrire :

  DDRD |= 0x3C;
  while(1) {
    PORTD |= 0x3C;
    _delay_ms(1000);
    PORTD &= 0xDF;
    _delay_ms(1000);
    PORTD &= 0xEF;
    _delay_ms(1000);
    PORTD &= 0xF7;
    _delay_ms(1000);
  }

ou plus explicitement :

  DDRD |= (1<<DDD5) | (1<<DDD4) | (1<<DDD3) | (1<<DDD2);
  while(1) {
    PORTD |= (1<<PORTD5) | (1<<PORTD4) | (1<<PORTD3) | (1<<PORTD2);
    _delay_ms(1000);
    PORTD &= ~(1<<PORTD5);
    _delay_ms(1000);
    PORTD &= ~(1<<PORTD4);
    _delay_ms(1000);
    PORTD &= ~(1<<PORTD3);
    _delay_ms(1000);
  }

NB : si le programme se limite à ces seules opérations et s'il n'est pas prévu de le faire évoluer par la suite, alors on peut l'optimiser en utilisant l'opérateur « = » à la place de l'opérateur « |= ». En effet, l'écriture directe de tous les bits du registre (y compris ceux restant constants) s'avère plus rapide et concise que l'écriture de deux à sept bits, laquelle impose de commencer par lire le registre avant d'y écrire le contenu modifié. En revanche, dans le cas présent il n'est pas intéressant d'utiliser l'opérateur « = » à la place de l'opérateur « &= » car un seul bit est concerné et le micro-contrôleur sait réaliser cette opération particulière beaucoup plus efficacement.

[PA5CAL]

Un mot concernant l'opération logique pour mettre plusieurs bits à 0 simultanément.

Par exemple, si l'on voulait éteindre en même temps les leds connectées à PD5, PD3 et PD2, on pourrait écrire :

PORTD &= ~( (1<<PORTD5) | (1<<PORTD3) | (1<<PORTD2) );

ou encore :

PORTD &= ~(1<<PORTD5) & ~(1<<PORTD3) & ~(1<<PORTD2);

ce qui, dans les deux cas, est équivalent à :

PORTD &= 0xD3;

[Murayama]

Bonjour!

Rien à dire sur les commentaires parfaitement étayés, mais pour revenir à la carte programmable en C:
pourquoi une Arduino si c'est pour programmer en autre chose que leur langage?
En plus, les cartes Arduino excluent de faire ses propres extension avec du circuit à trous standard parce
qu'elles on des pas complètement bordéliques, non-alignés.
Il existe chez chaque fabricant des cartes d'évaluation.
- TI : les launchpads, très bon marché, avec de la mémoire à ne plus savoir qu'en faire (comparé au UNO).
De mémoire, 12 euros pour un Launchpad 5529.
- ST: les Nucleo, un peu plus chères quand elles ont des écrans TFT, mais d'une puissance phénoménale,
processeur à plus de 200 MHz, etc. Par exemple Nucleo F767ZI. 216 MHZ, 1MB de flash (je crois), et 1 de
RAM... De mémoir aussi, dans les 20 à 25 Euros pour une carte Nucleo F767ZI. Donc moins qu'Arduino,
et 100 fois plus puissante.
Dans les 2 cas, il y a un environnement de développement gratuit. Limité à 16 ou 32k d'exécutable pour TI,
illimité pour ST.
Et il y a un utilitaire de config pour STM32, qui s'appelle STM32 Cube MX, qui est carrément magique pour
démarrer en douceur sans trop se prendre la tête.
Inconvénient, la STM32 Nucleo a des connecteurs... Arduino.

- Tous les autres constructeurs on probablement des solutions à eux.

Pascal

[PA5CAL]

pourquoi une Arduino si c'est pour programmer en autre chose que leur langage?

Parler de « langage Arduino » est abusif.

Il s'agit de langage C++, compatible C, mis en œuvre dans un environnement simplifié proposant des éléments de base et des exemples, en l'occurrence un IDE très dénudé commandant quelques traitements et fixant le fonctionnement de la chaîne de compilation et de programmation, et une bibliothèque de fonctions et d'objets « maison » permettant de traiter les opérations de bas niveau au travers d'un socle commun à toutes les cartes cibles compatibles.

Le but est de mettre des systèmes à micro-contrôleurs à la portée de néophytes, c'est-à-dire de personnes ne disposant pas de toutes les connaissances normalement nécessaires à ce type de développement.

Le projet étant libre et open-source, les cartes compatibles Arduino peuvent être achetées ou produites soi-même à partir des fichiers de conception fournis (NB : seule la marque Arduino est déposée, mais il est parfaitement légal de fabriquer des clones ou des produits dérivés, même commerciaux, à condition qu'on ne prétende pas faire des cartes de marque Arduino, mais seulement compatibles). Le fait de proposer des cartes prêtes à l'emploi met le projet à la portée de personnes qui n'ont pas le savoir-faire, les moyens matériels, le temps ou la volonté d'en fabriquer.


Un collégien est ainsi capable de produire ses propres réalisations fonctionnelles en moins d'une semaine (j'en ai déjà vu plusieurs exemples), au lieu de plusieurs mois à plusieurs années pour acquérir les bases et l'expérience requises pour ce type de métier et être capable de produire des éléments de qualité industrielle.

Cela permet de s'initier, de bricoler et éventuellement de susciter une motivation pour se lancer plus sérieusement dans cette voie.

En plus, les cartes Arduino excluent de faire ses propres extension avec du circuit à trous standard parce
qu'elles on des pas complètement bordéliques, non-alignés.

Ce n'est vrai que pour les cartes au format « Uno » ou « Mega ».

Il existe également des cartes au format DIP (Mini, Nano, Micro, MKR, ...) utilisables sur des cartes plaques d'essai ou sur des cartes électroniques classiques, soudées ou montées sur support standard.

Le format spécifique Arduino a très certainement été le moyen de créer un marché singulier (pour ne pas dire virtuellement captif) qui a permis au projet de se financer, surtout à ses débuts, en dépit du fait qu'il était libre et open-source. Ce genre de pratique est courante, sauf qu'habituellement les formats propriétaires sont soumis à brevets et modèles et ne peuvent être reproduits que contre le versement d'espèces sonnantes et trébuchantes.

Aujourd'hui, les cartes et extensions au format Arduino proviennent de producteurs, très majoritairement asiatiques, qui les vendent souvent à prix cassés (la guerre économique au travers du dumping n'y est pas étrangère) avec une qualité et une fidélité qui laissent parfois à désirer, mais sans reverser un centime au projet. Cela n'empêche pas les produits officiels présentés sous ce format de continuer à se vendre.

Il existe chez chaque fabricant des cartes d'évaluation.
- TI : les launchpads, très bon marché, avec de la mémoire à ne plus savoir qu'en faire (comparé au UNO).
De mémoire, 12 euros pour un Launchpad 5529.
- ST: les Nucleo, un peu plus chères quand elles ont des écrans TFT, mais d'une puissance phénoménale,
processeur à plus de 200 MHz, etc. Par exemple Nucleo F767ZI. 216 MHZ, 1MB de flash (je crois), et 1 de
RAM... De mémoir aussi, dans les 20 à 25 Euros pour une carte Nucleo F767ZI. Donc moins qu'Arduino,
et 100 fois plus puissante.
Dans les 2 cas, il y a un environnement de développement gratuit. Limité à 16 ou 32k d'exécutable pour TI,
illimité pour ST.
Et il y a un utilitaire de config pour STM32, qui s'appelle STM32 Cube MX, qui est carrément magique pour
démarrer en douceur sans trop se prendre la tête.
Inconvénient, la STM32 Nucleo a des connecteurs... Arduino.

- Tous les autres constructeurs on probablement des solutions à eux.

En effet.

Toutefois, à l'inverse d'Arduino, je n'ai jamais trouvé de complet néophyte capable de mettre en œuvre ces cartes aussi rapidement, seul et en partant de zéro. Mais Arduino n'est, selon moi, clairement pas destiné à un public professionnel (même s'il peut être à l'occasion utilisé dans ce milieu sous l'entière responsabilité de son utilisateur -- ce qu'il m'arrive parfois de faire avec profit, en en maîtrisant parfaitement les risques).


Par ailleurs, chaque solution présente des caractéristiques, des avantages et des inconvénients spécifiques.

J'utilise notamment beaucoup les STM32 (ARM Cortex M0 à M7, selon le besoin), et je peux dire que comparés aux AVR 8 bits ils font figure de véritable usine à gaz, et que parfois leur architecture pose des problèmes de déterminisme et induit quelques déficits de performances inattendus. Bref, bien que leur puissance soit apparemment beaucoup plus importante, ils ne sont clairement pas adaptés aux mêmes applications ni aux mêmes conditions de développement que les petits micro-contrôleurs 8 bits classiques.

Il faut de tout pour faire un monde. Le plus important est de choisir la meilleure solution lorsque se présente un besoin particulier avec ses contraintes spécifiques, et donc de connaître avec un niveau de détail suffisant un éventail assez grand de possibilités afin d'éviter d'imposer a priori un choix qui pourrait par la suite s'avérer peu judicieux, voire délétère.

[Vincent PETIT]

Salut,
Moi je raisonne comme ça et je ne pense pas me tromper. Suffit de comparer à la cuisine.

Arduino (l'IDE + UNO par exemple + les shields) = plat préparé à mettre dans un four à micro-ondes pour manger.

Arduino a été pensé exactement dans ce but, comme dit Pascal, pour permettre à n'importe qui de jouer avec de l'électronique et les microcontrôleurs. Les shields permettent de ne pas apprendre l'électronique. Les bibliothèques Arduino permettent de ne pas ouvrir la doc du microcontroleur, on conçoit en modifiant le soft sans ce soucier à quoi sert VREF de l'ADC par exemple etc...

Je n'ai rien contre et je trouve même ça génial pour les bidouilleurs qui ne veulent pas forcément devenir ingénieur pour faire coller quelques relais.

Maintenant, il suffit que Mathieu sache exactement ce qu'il veut. Si il veut devenir électronicien alors l'écosystème Arduino est le plus mauvais des choix, tout comme se serait un mauvais choix d'apprendre la cuisine au travers des plats préparés.

Ou bien comme dit avant, on peut prendre comme je le fais moi même, Arduino et le programmer avec Éclipse + GccAVR + Avrdude + la datasheet du microcontroleur + apprendre l'électronique (à partir de là de Arduino, il ne reste que le nom de la demo board)


Ps: j'ai aussi des Launchpad (et des Nucleo) chez moi et je préfère de loin même la plus petite des Launchpad à Arduino UNO car sur cette dernière on ne peut pas debugguer en pas à pas, autrement il faut une sonde comme Atmel ICE alors que sur Launchpad ceci est possible (point d'arrêt dans le programme, déroulement du programme pas à pas, visualisation de l'état de la RAM et des registres en live etc...)

[Murayama]

Bonjour!

Parler de « langage Arduino » est abusif.

Oui, ça, je suis au courant. Mais beaucoup ont l'impression que le langage Arduino
est spécial. D'ailleurs le message d'orgine nous dit "mais je recherche une carte qui
respecte le code C pure, c'est à dire qui garde par exemple les printf"...
Bon, passons sur le fait que ce n'est pas le hardware qui respecte le C pur, et qu'en
outre printf n'est pas du C, mais seulement une librairie (stdio) linkée avec le C...
Bref, on voit ce qu'il veut dire même si les termes sont inadéquats.

Pour citer quelqu'un de ce site, je ne sais plus qui, il s'agit même de "charabia arduino",
(je n'invente rien), alors que ce n'est que du C++. (J'écris d'ailleurs principalement en
C++, au risque de passer pour un extra-terrestre dans le domaine embarqué.)

Il y a encore beaucoup de préjugés, l'assembleur est plus rapide que le C, le C est
plus rapide que le C++, etc.... Mais en comparant l'assembleur craché par un compilateur
C/C++ décent et de l'assembleur roulé main, il y a finalement peu de différence.

Le juge de paix étant pour moi l'oscillo, on peut s'amuser à mesurer en C ou en assembleur
le temps que prend une certaine action, et on s'aperçoit du même coup que souvent, ça ne
vaut pas la peine de se prendre la tête avec de l'assembleur dans 99.9% des cas. Passer
du temps pour gagner 10 coups d'horloge, non merci. Le tout sujet à polémiques, comme nous
en avons tous vu avec Mac vs PC, Peugeot vs Renault, et pour nos parents ou grands parents,
Vespa vs Lambretta.

Toutefois, à l'inverse d'Arduino, je n'ai jamais trouvé de complet néophyte...

En l'occurrence, même si le posteur d'origine est néophyte, je crois avoir lu qu'il
est en école d'ingénieur et on peut peut-être considérer qu'il est capable de s'adapter
à des systèmes moins "user friendly".
J'ai eu ici un ingénieur de Télécom Bretagne qui à l'origine n'avait fait en gros que
du Java sur Androïd, mais s'est très bien débrouillé en stage avec des systèmes non-Arduino
et des appareils construits par moi (je fais principalement des instruments de mesure).
Épilogue: il est rentré en France avec les honneurs et une Japonaise sous le bras.

Suffit de comparer à la cuisine.
[...]
Je n'ai rien contre et je trouve même ça génial pour les bidouilleurs qui ne veulent pas
forcément devenir ingénieur pour faire coller quelques relais.

L'image de la cuisine est assez bien vue.
Bon, je vois que je ne suis pas le seul, loin de là, apparemment. Je ne suis pas
foncièrement contre Arduino que je considère cela comme une réussite technique suscitant
beaucoup de mépris et de jalousies, à en juger par le nombre de "ardui-machin" qui
sévissent ici. Mais le proverbe avec celui qui montre la lune et celui qui regarde le
doigt doit être applicable à celui qui montrerait le formidable potentiel éducatif
de la plateforme et celui qui compterait les coups d'horloge.

Ps: j'ai aussi des Launchpad (et des Nucleo) chez moi et je préfère de loin même la plus
petite des Launchpad à Arduino UNO car sur cette dernière on ne peut pas debugguer en pas
à pas, autrement il faut une sonde comme Atmel ICE alors que sur Launchpad ceci est
possible (point d'arrêt dans le programme, déroulement du programme pas à pas,
visualisation de l'état de la RAM et des registres en live etc...)

Oui, c'est assez proche de ce que je fais. J'en ai toujours plein en stock pour des
bricolages divers quand je n'ai pas le temps de développer une carte.

Pascal

[Chtulhu]

Ce discours fleuve (inutilement) n'engage que vous, il est bien trop restrictif.

Vous faites de vos choix personnels une généralité, or la généralité et l'état de l'art en matière de programmation sont exactement à l'opposé des principes que vous soutenez.
Qu'un professionnel conseille ainsi de jeunes électroniciens en devenir est juste sidérant...

J'écris d'ailleurs principalement en
C++, au risque de passer pour un extra-terrestre dans le domaine embarqué.

Ca c'est sur! Vous le reconnaissez vous-même.

Ce n'est pas une question de préjugés, ça c'est typiquement une réponse de quelqu'un qui pense avoir fait le tour de la question dans son petit univers, c'est juste qu'il faut faire la distinction entre produits à contraintes fortes et produits sans contraintes du tout.
Quand vous aurez a subir une AEEL (dérivée de l'AMDEC),
http://www-igm.univ-mlv.fr/~dr/XPOSE...thode_AEEL.htm

vous verrez qu'il y a des contraintes, des règles, des méthodes à respecter de nos jours (et depuis un bon moment) et que tout votre discours ne tient plus la route.

[Murayama]

Bonjour!

Je vois que comme moi, vous devez être très occupé et vous n'avez pas toujours le temps
de lire tout ce qui est écrit. Alors je résume:
- J'ai conseillé à un jeune ingénieur de choisir autre chose qu'Arduino pour programmer
en C/C++, et j'ai donné quelques références d'environnements de développement C/C++. Je
ne vois pas bien là ce qu'il y a de sidérant.
- J'ai par ailleurs dit tout le bien que je pense d'Arduino comme outil d'initiation.
Mais je n'oblige personne à être d'accord.

ça c'est typiquement une réponse de quelqu'un qui pense avoir fait le tour de la question
dans son petit univers, c'est juste qu'il faut faire la distinction entre produits à
contraintes fortes et produits sans contraintes du tout.

Nous nous connaissons?
Enfin d'un certain point de vue, vous avez raison. Mon petit univers se limite à la
terre et à sa proche banlieue, avec quelques appareils qui passent au-dessus de nos
têtes toutes les 90 minutes environ.

Quand vous aurez a subir une AEEL (dérivée de l'AMDEC),
http://www-igm.univ-mlv.fr/~dr/XPOSE...thode_AEEL.htm

Vous m'en apprenez, des choses!

Pascal

[Chtulhu]

Je vais peut être vous en apprendre d'autres.
Mélanger C et C++ a quelque chose de dénaturé, parlez de l'un et l'autre ensemble n'a que peu de sens, hormis la consanguinité.
Le premier est un langage procédural, l'autre est orienté objet, ça n'a rien à voir du point de vue développement software.

Le C est portable facilement et se compile sans peine d'un IDE à l'autre moyennant peu d'efforts (si tant est que le code écrit respecte la norme ANSI).
Le C++ oblige à se marier avec un compilateur spécifique à la cible, le code n'est pas pensé pour être portable.
C permet de travailler intimement avec la couche 0, C++ non.

C++ n'apporte strictement rien pour de l'embarqué avec de petits µC 8 ou 16 bits, au contraire il permet surtout que les programmeurs ne s'interrogeront plus sur ce qui se passe à plus bas niveau. C'est là où le bât blesse et que les bugs surgissent en masse.

Programmer en C++ pour de l'embarqué est ne pas avoir compris la nuance fondamentale entre ces 2 langages et leurs objectifs respectifs.

Aujourd'hui les travers logiciels suivent naturellement les travers de l'électronique matériels, le mélange des genres, d'un coté une certaine liberté au niveau loisir et de l'autre les fortes contraintes industrielles (proof of concept), ces 2 mondes sont totalement incompatibles.
Cette illusion du plug and play généralisable, a permis à certains de dévoyer totalement les concepts fondamentaux de développement pour des fins qui n'ont rien à voir avec la technique.
Résultats au bout du bout de cette démarche inappropriée, des start-up se cassent la gueule chaque jour en ayant eu au départ une belle idée mais ayant misé sur des concepts erronés et hors de toute réalité industrielle.

C'est bien plus grave qu'une petite discussion sympathique sur un forum et qui est sans conséquence pour les hobbystes tant qu'ils le resteront et ne feront pas cet amalgame toxique.
Une de mes activités est de tenter de sauver certains projets dont le pas de vis a été foiré dès le début avec de telles pseudo-solutions, dont le seul intérêt fut de montrer un truc qui marchote rapidement au client, mais où ensuite il faut tout jeter à la poubelle et repartir sur une feuille blanche avec plusieurs mois et plusieurs dizaines de kEuros à budgéter, pour que le rêve de départ devienne une réalité économique et que des gens puissent en vivre.
Ce type d'erreur conceptuelle est en constante augmentation à cause de la propagation de propos irresponsables sur bon nombre de forum et des contenus éducatifs exsangues qui accélèrent cette spirale infernale.

Ce n'est que mon point de vue d'observateur et d'expert, chacun est libre d'en penser ce qu'il veut bien entendu.

[PA5CAL]

en outre printf n'est pas du C, mais seulement une librairie (stdio) linkée avec le C...

Non. La fonction printf fait partie intégrante des spécifications du langage C normalisé depuis K&R. Le fait qu'elle soit intégrée à la chaîne de compilation par le biais d'une bibliothèque (tout comme les autres fonctions standards et la plupart des opérateurs de base du langage, d'ailleurs) n'en fait absolument pas un élément étranger.

[Murayama]

Bonjour!

Non. La fonction printf fait partie intégrante des spécifications du langage C normalisé depuis K&R.
Le fait qu'elle soit intégrée à la chaîne de compilation par le biais d'une bibliothèque (tout comme
les autres fonctions standards et la plupart des opérateurs de base du langage, d'ailleurs) n'en fait
absolument pas un élément étranger.

Pas tout à fait. Je sais que nous sommes là en train de faire de vilaines choses à des mouches qui
ne nous ont rien fait, mais la fonction printf (et la librairie stdio plus généralement) fait partie
des spécifications ANSI pour les librairies standard du C.

Je cite Kernighan & Ritchie, C programming language, second edition, 1988.
Chapitre 7 Input and Output (page 151).


Input and output facilities are not part of the C language itself...


Et ils expliquent dans ce chapitre que la norme ANSI a standardisé les libraries
pour qu'elles existent partout de façon homogène, ce qui n'en fait pas une partie
intégrante du C.

Mais bon, le fait est que quand il y a C, il y a en général stdio.


Pascal

[pm42]

Et ils expliquent dans ce chapitre que la norme ANSI a standardisé les libraries
pour qu'elles existent partout de façon homogène, ce qui n'en fait pas une partie
intégrante du C.

En effet. Cela a d'ailleurs été l'objet de débat lors de la normalisation du C entre ceux qui voulaient inclure et ceux qui disaient "on n'a pas besoin de printf quand on code des contrôleurs d'ascenseur".
Ceci dit, de nos jours, toutes les librairies sont disponibles en open-source, beaucoup de compilateurs sont dérivés de gcc... Le coût de fournir un printf et les autres fonctions d'I/O est donc faible ce qui n'a pas toujours été le cas.

[PA5CAL]

Pas tout à fait. Je sais que nous sommes là en train de faire de vilaines choses à des mouches qui
ne nous ont rien fait, mais la fonction printf (et la librairie stdio plus généralement) fait partie
des spécifications ANSI pour les librairies standard du C.

Je cite Kernighan & Ritchie, C programming language, second edition, 1988.
Chapitre 7 Input and Output (page 151).

Input and output facilities are not part of the C language itself...

Et ils expliquent dans ce chapitre que la norme ANSI a standardisé les libraries
pour qu'elles existent partout de façon homogène, ce qui n'en fait pas une partie
intégrante du C.

En effet, au temps pour moi.

Les spécifications de printf proviennent et font partie intégrante de la norme du langage C, tout en ne faisant officiellement pas partie du « langage C » d'après ces mêmes spécifications.

... On frise le dilemme.

Le soucis est que, à la manière d'un vice de procédure qui blanchirait l'auteur d'un crime, cet énoncé officiel balaie d'un revers de main la problématique de Matheux56 alors qu'il ne correspond pas à la réalité vécue : je doute qu'on trouve grand monde pour accepter que quelqu'un qui ignore tout de la fonction printf puisse prétende maîtriser le langage C (qui est avant tout une norme de fait).

[Murayama]

Bonjour!

Les spécifications de printf proviennent et font partie intégrante de la norme du
langage C, tout en ne faisant officiellement pas partie du « langage C » d'après ces
mêmes spécifications.

On ne peut qu'être d'accord avec vous que ça semble un peu ambigu. Mais je
pense qu'il faut le comprendre dans le sens où ANSI a standardisé le C d'une part et
les librairies C d'autre part.
Pour être franc, quand j'ai lu ça il y a très longtemps, ça m'avait surpris qu'un
langage puisse ne pas avoir d'entrées et sortie par lui même. Mais avec le temps,
je pense que c'est une bonne séparation des concepts que d'avoir le "core" (*)
distinct des extensions qui ne sont pas toujours utiles comme dit plus haut par pm42
pour les microcontrôleurs. Si on avait commencé à inclure stdio, d'aucuns probablement
auraient dit qu'il n'y a pas de raison de ne pas inclure string.h, etc... et ça
aurait fait quelque chose d'énorme.
Je pense donc que C est bien comme il est, dans une version ultra-spartiate, sans
fioritures.

(*) Comment dit-on core en Français? Corps?

>>Vous m'en apprenez, des choses!
>Je vais peut être vous en apprendre d'autres.

Votre sens du second degré me bouleverse.

Ce n'est que mon point de vue d'observateur et d'expert,

Bon, ce qui suit ne s'adresse pas à vous puisque vous êtes un expert et je n'aurais
jamais l'outrecuidance ni de contester votre savoir ni de prétendre vous apprendre
quoi que ce soit. Ce qui suit s'adresse aux membres du forum qui seraient intéressés
par un petit survol du C++. Une remise en place de certaines idées reçues.

Ce n'est que mon point de vue de non-expert, mais qui vit tout de même de la programmation.

Le C++ est tout autant portable que le C. Puisque nous parlons d'ANSI C, alors soyons
fair-play et ajoutons qu'il y a aussi un ANSI C++. Depuis quand, je ne saurais le dire
avec précision, mais je me souviens que j'en parlais avec un collègue bien avant de monter
ma boîte, donc bien avant 2003. À vue de nez, une petite 20aine d'années. Je me souviens
d'ailleurs qu'il y a eu un C++03. Nous en somme, je crois, au C++17, il en sort un en gros
tous les 3 ans, et le prochain est censé être le C++20.

Comme c'est un standard, chaque éditeur sérieux de compilateur se fait un point d'honneur
d'être parmi les premiers à implémenter le standard à chaque fois qu'il change.
Le standard C++ évolue. Le C aussi, d'ailleurs, non? Mais chaque version a une
compatibilité ascendante: un programme écrit en C++14 pourra donc être compilé avec un
C++17, mais l'inverse, pas forcément si des fonctionalités nouvelles ont été utilisées.

D'autre part, le C++ est tout aussi capable que le C de parler directement au hardware.
En bref, je ne vois aucune opération qui serait possible en C et pas en C++. Par contre,
si quelqu'un voit une opération faisable en C et pas en C++, je suis prêt à essayer
sur le champ et bien sûr à reconnaître mon erreur si je faillis à la tâche de montrer
que c'est possible. À tout hasard, je ne peux vérifier que sur MSP430 et sur STM32F7x.

Bon, maintenant, C++ n'apporte strictement rien? Pour moi, si. C'est un style de
programmation qui apporte de la rigueur (à mon avis, hein!!) rend le code propre,
soigné, plus facilement réutilisable (toujours à mon avis).

Mais ça, évidemment, c'est une question de goût, de choix, etc. Le C++ force à être
ordonné, et pour moi qui suis bordélique, c'est une bénédiction. Moins de chance d'oublier
des initialisations, etc... Ceci dit il y a des gens très rigoureux en assembleur,
de l'assembleur bien fait est certainement mieux que du C fait par un branque et
réciproquement, et même chose avec C et C++ ou toute autre paire de langages.

Et finalement, je ne voudrais pas vous filer le traczir, mais il existe une pompe á
intraveineuse dont j'ai fait le soft... En C++. Apparemment, ce n'est pas encore
l'hécatombe.
Il y a (heureusement) aussi en C++ des méthodes rigoureuses d'évaluation
du software. Bref, ce n'est pas parce que c'est du C++ que c'est n'importe quoi.

Pascal

[gienas]

Bonsoir à tous

... (*) Comment dit-on core en Français? Corps? ...

Je pense qu'il s'agit du noyau.

Puisque le demandeur à reçu, je pense, la réponse qu'il attendait, et même bien au delà, il me semble qu'il est souhaitable de ranger les fusils aux vestiaires. Il y a bien assez de conflits comme ça sur la planète qui se réchauffe, inutile d'accélérer le processus.

[invitecd74172e]

C'est parti loin o.O

Ouaip j'ai été comblé pour la plupart des choses. Je n'ai toujours pas fait l'effort encore de regarder pourquoi il fallait inversé ma logique de 0 et 1 logique lors de ma configuration des entrées/sorties. Mais je vais m'y mettre !

[Murayama]

Bonjour!

Je pense qu'il s'agit du noyau.

Noyau, ça peut s'utiliser aussi pour un programme ordinaire? J'avais l'impression que
c'était réservé aux OS. Noyau Linux, noyau Darwin, etc...



Bon, ceci dit, je viens d'avoir une idée (si, si, je suis équipé pour ça...).
Il semble que le C++ soit très méconnu même des experts. Alors je propose d'écrire une
introduction qui montrerait le profit que l'on peut tirer de C++ dans un montage
embarqué. Mais par contre, si je le mets dans le forum, au bout d'une semaine, plus
personne ne le verra. Serait-il possible de mettre cela dans les projets?


Pour que ceci devienne réellement un projet, je propose de passer par un montage
que tout le monde peut reproduire, en utilisant une ébauche (la girouette) écrite il y
a quelques semaines.
- Utilisation d'une carte TI très bon marché (Un Launchpad 5529, dans les 10 ~ 15 euros).
- Utilisation d'un LCD très commun dans le genre 16 chars x 2 lignes.


Donc question aux modérateurs: est-il possible que je publie un développement dans
la rubrique "projets"? Si oui, je vais faire un petit morceau de hard qui permet
d'illustrer un genre de tutorial C++. On appellera ça "Girouette pour bateau" puisque
c'était le sujet.


NB: ça ne va pas progresser au pas de charge, parce qu'il faut non seulement que je
construise le hard (ouais, bon, en 1 heure, ça devrait être possible), mais il faut
aussi que j'écrive une explication des concepts C++, et vous savez comme moi que pour
faire un texte bien ficelé, il faut du temps. Il faut aussi que je fasse des
schémas, que je teste le code, etc... Et puis j'ai aussi un travail...


À bientôt, peut-être pour la suite.


Pascal

[pm42]

Noyau, ça peut s'utiliser aussi pour un programme ordinaire? J'avais l'impression que
c'était réservé aux OS. Noyau Linux, noyau Darwin, etc...

Oui, c'est un concept. Si ton programme ordinaire est basé sur un outil technique et que ses fonctions visibles sont construites au dessus, on va l'appeler le noyau.
Par exemple, on peut dire "le noyau d'Emacs est un interpréteur LISP".

[Jack]

Concernant la proposition de Murayama, mes petits camarades modérateurs et moi-même y sommes favorables.

Dans un premier temps, la discussion devra figurer dans le forum électronique "classique" avant de migrer dans le forum projet lorsque l'état de finalisation sera suffisant.

Bon courage!

[Chtulhu]

"Core"-> noyau, s'utilise dans plein de domaine, magnetic core (noyau magnétique), core group, steel core, etc.

J'ai peine à croire que quelqu'un qui écrit bien en français connaisse le sens de core en anglais mais pas en français...

Quitte à faire une démo de la portabilité et des avantages du C++, faite donc une appli avec un simple PIC 8 bits pour voir genre un PIC16F872.
Bon courage

[Murayama]

Bonjour!

Merci à pm42 pour l'explication.

J'ai peine à croire que quelqu'un qui écrit bien en français connaisse le sens de core
en anglais mais pas en français...

Il y a donc au moins une chose que je fais bien, vous me rassurez.
Vous avez peine à croire? Vous avez bien raison, c'est une attitude scientifique. La
science ne se satisfait pas de croyances, mais au contraire s'attache aux faits.
Vous avez aussi peine à croire que C++ est portable et vous avez là encore bien raison.
C'est la bonne attitude à avoir quand on n'a jamais essayé quelque chose. Pour ma part,
comme je n'ai jamais vu la terre de loin, je considère qu'elle est plate.

Pour info, si ça dérange quelqu'un d'autre que je pose des questions pareilles (sur
le vocabulaire, core, etc...), et bien que ceci ne soit pas le lieu idoine pour raconter
ma vie: je n'ai jamais travaillé dans un environnement francophone (*). Ma langue de
travail a toujours été le japonais si l'on excepte quelques incartades en Europe,
dans des équipes assez hétérogènes où la langue de travail était l'anglais.
Et comme je ne parlerais jamais de kernel (noyau) pour un programme autre qu'un OS,
j'ai simplement pensé qu'il y avait une autre traduction que noyau pour core. Bon,
apparemment non, donc en français, il n'y a pas de nuance core / kernel
comme il y en a une en anglais. J'aurai tout de même appris quelque chose.
J'ai des lacunes en français technique ou peut-être même en français tout court,
c'est vrai, et je remercie ceux qui me corrigent mes erreurs ou me répondent avec tact.

(*) Si l'ambiance de ce forum reflète celle des bureaux d'études en France, j'ai
l'impression de ne pas perdre grand chose. Mais il faut toutefois admettre que
cette ambiance n'est le fait que d'une poignée, la plupart étant tout-à fait correcte
du point de vue politesse.

Quitte à faire une démo de la portabilité et des avantages du C++, faite donc une appli
avec un simple PIC 8 bits pour voir genre un PIC16F872.

Je n'ai pas d'environnement PIC. De plus, en l'occurrence, c'est moi qui fais le boulot
sur mon temps libre et à mes frais. Vous n'êtes donc pas en position de m'imposer un
processeur. Comme dit plus haut, ce sera donc un MSP430.

Bon, pour terminer, merci à l'équipe de modération. Je vais donc commencer le hard dès
maintenant.

À suivre... dans un autre fil de discussion, plus serein, j'espère.

Pascal

[gienas]

Bonjour à tous, sans exception!

... À suivre... dans un autre fil de discussion, plus serein, j'espère ...

C’est à souhaiter car ici, la dérive n’est pas acceptable. La question initiale ne demandait pas des développements aussi pointus que les lances échangées.

Puisqu’ici tout ou presque est dit, et pour éviter toutes les tentations, je préfère fermer.