De l'Arduino au langage C standard avec AVR Studio

[invitedca01a58]

Hello, les amis

Le programme du LCD par liaison série progresse doucement. J'espère que je pourrai le proposer sur le forum dans quelques jours.

J'ai essayé d'installer Studio4 sur un autre PC vierge de toute version de Studio. J'ai refait toute la procédure et les téléchargements renseignés par Mourad dans ce message

L'installation s'est très bien passée. La compilation se déroule sans problème. Par contre, dès que je clique sur "debug", le programme se plante.



Le message d'erreur est différent de celui d'il y a quelques jours, peut-être en raison du fait que cette machine-ci n'a pas Studio6.

C'est quand même très bizarre ! Jusqu'il y a quelques jours, je pouvais au moins faire du debug avec Studio4 et le simulateur. Maintenant, le debug est devenu inaccessible.

Mes deux PC tournent sous Win XP SP3. De temps en temps, Microsoft continue à envoyer une mise-à-jour de l'agent anti-virus. Ne serait-ce pas par hasard l'une de ces dernière mise-à-jour qui empêcherait le debug avec Studio4.

Y aurait-il quelqu'un avec Win XP qui pourrait tester le debug sous Studio4 SP3 ?
-----

[laveplusblanc]

Bonsoir, Jean Marie

A mon avis il y a un problème avec avr-gdb
J'ai regardé le post de Mourad. Peux-tu essayer :
- en n'installant pas les "GNU coreutils" (à mon avis, ils ne pas nécessaires).
- avec la version WinAVR qui se trouve sur sourceforge.net (et en laissant l'option "use winavr toolchain")
- Si cela ne fonctionne toujours pas, en essayant ATMEGA32 à la place d'ATMEGA8

LVPBL

[invitedca01a58]

Hello Laveplusblanc,

Sacrebleu, tu avais raison. J'ai installé WinAVR et j'ai modifié la ToolChain en conséquence : ça marche !!! La fonction debug ne provoque plus d'erreur !!!

C'est quand même bien d'avoir l'aide de gens plus expérimentés. Merci, merci, merci.

Donc, si on veut utiliser la dernière version de la ToolChain renseignée par Mourad, il y a certainement encore quelque chose à faire pour que ça marche.
Allez, Mourad, à toi de bosser.

J'ai une idée. En installant Studio6, on installe également la dernière version de la ToolChain. On pourrait essayer de pointer vers cette version.

[laveplusblanc]

Bonjour, Jean Marie

Bon, j'ai compris. Je viens d'installer la dernière toolchain de Mourad et voici l'explication de ton problème.
C'est du au fait qu'il y a des programmes supplémentaires qui sont dans le package winavr, à savoir (si tu regardes dans le répertoire "bin" de winavr : avarice et simulavr. Les "core utils" sont das le répertoire "utils" de winavr et ne sont pas inclus dans la dernière toolchain d'Atmel. Avrdude (que tu connais) est aussi compris dans winavr.
Avarice est ce qu'on appelle un "serveur" gdb, qui fait l'interface entre le uC et le programme debugger (avr-gdb).
Simulavr est un programme qui "remplace" le uC "hard" en simulation.

En conclusion:
Si tu copies ces programmes dans le répertoire "bin" de la dernière toolchain, cela devrait (peut être) marcher. Il faudra peut être aussi copier les différents "scripts" (fichiers sans extension) et éventuellement les fichiers de configuration : ".conf" associés.
Les dernières versions plus récentes de ces programmes peuvent aussi être trouvés sur le net.

J'essaierai mais je n'ai pas trop le temps ce WE.

LVPBL

[invitedca01a58]

Hello Laveplusblanc

On approche probablement de la solution mais on n'y est pas encore.

J'ai d'abord essayé d'ajouter avarice et simulavr dans la ToolChain. Ça ne fonctionne pas. Studio4 plante toujours au moment du debug.

Alors, j'ai procédé autrement. J'ai fait une copie du répertoire bin de WinAVR. J'ai ajouté à cette copie le contenu du répertoire bin de la ToolChain en écrasant les fichiers et j'ai remis ce répertoire à la place du bin original de la ToolChain ==> Studio4 plante !

J'ai encore fait un autre essai. J'ai recopié tous les répertoires de la ToolChain sur les répertoires de WinAVR en écrasant les fichiers de même nom. Puis j'ai lancé Studio4 debug après y avoir resélectionné WinAVR ==> toujours le plantage :

335.jpg
334.jpg

Donc, pour le moment, seul WinAVR original marche pour le debug.

[invitedca01a58]

Ce que je dis ci-dessus est à prendre avec réserve car ces constatations ont été faites sur mon PC habituel. Or, je viens d'y réinstaller cet après-midi WinAVR et d'essayer le debug avec ce WinAVR et il plante de la même manière, alors que la même configuration sur mon vieux PC ne plante pas (cfr le message #393, retesté cet après-midi).

[gegel62]

bonjour le forum,

c'est trop facile de se taire quand on n'a rien à dire....

[invitedca01a58]

Hello Gégé

C'est vrai que c'est le silence pour le moment.

Mardi est arrivé mon nouveau portable
J'ai passé pas mal de temps à le configurer pour qu'il fonctionne à peu près comme Widows XP, et à y installer les logiciels dont je me sers. En particulier, j'ai installé Studio6 qui est beaucoup plus fluide qu'avant.

Ceci a bien sûr retardé la mise au point de mon programme de LCD-moniteur. Mais ça avance quand même (un peu).

En attendant, je te propose de quoi occuper ton temps libre.
D'abord, tu étudies un peu comment travailler avec un string en C. Google offre de multiples possibilités.
Lorsque tu en auras assez, reviens à la recherche Google et clique sur "images", une manière radicalement différente mais tout aussi plaisante de voir les choses, de quoi devenir accro de la fonction printf().

[invitedca01a58]

Hello les amis,

Pas d'inquiétude si je ne dis pas grand-chose. Je suis en mode lézardage sous le soleil de Provence jusque dimanche.

[gegel62]

Hello Jean-Marie, il est temps de revenir, il parait qu'il fait plus beau par ici cette semaine, et sans doute aussi en Belgique....

Sinon je regarde -à mon rythme...- les fonctions printf et string du langage C. Mon problème est que j'ai l'impression d'avoir compris, printf qui sort sur écran, plus riche que le SerialPrint d'Arduino puisqu'on peut lui faire faire des calculs en même temps, et string qui est une chaine de caractères, mais ton message semble indiquer que je n'ai vu que la partie visible de l'iceberg....sauf en ce qui concerne "images" de google, où là je pense avoir tout compris !

le chemin est encore long....

bonne soirée à tous
gégé62

[invitedca01a58]

Hello les amis. Les vacances sont finies. Retour au string sous toutes ses coutures.

J'ai une bonne et une mauvaise nouvelle.

La bonne nouvelle, c'est que le programme du LCD comme terminal série est écrit.

La mauvaise nouvelle, c'est qu'il ne fonctionne pas !

Mais avez-vous déjà vu un programme qui fonctionne du premier coup ?
Donc, encore un peu de patience pour le débugging.

[mkh.mourad]

salut tout le monde, pardonner mon absence, j’étais en congé. et je viens de reprendre le travail; je suis vraiment trop occupé ces jours la, et ça ne m’empêcherai pas de suivre le thread.
bonne journée.

[invite145419a0]

Bonjour à tous,

Depuis hier, j'ai lu les 27 pages de ce sujet, car j'ai fait l'acquisition d'une carte Arduino et je me suis senti un peu frustré.

Je suis guère plus jeune que Jean Marie45 et depuis 1978 je "bricole" sur tout ce qui peut être programmé.

Pour rappel, 1978 c'est l'année où la revue Elektor a publié son premier numéro décrivant un automate, programmable le SCAMP ...

J'ai toujours pris beaucoup de plaisir à programmer en assembleur, des petites applications.

D'un autre coté la lecture des forums pousse à utiliser un langage de "Haut Niveau", le C.

Je me suis donc lancé dans l'Arduino et je dois reconnaitre que le premier bilan n'est pas très positif ...

Dès la première compilation un détail m'a frappé : 1600 octets pour faire clignoter une led (!)

Deuxième chose, l'écart de niveau entre les programmes débutants qui fleurissent sur Youtube, et les programmes écris par des 'bons' totalement incompréhensibles pour un profane comme moi.

Alors je me permet de poser la question, est ce que un amateur ne fait pas fausse route en essayant d'apprendre à utiliser les microcontrôleurs via un langage dit, de haut niveau ?

Car à un moment s'il veut sortir des exemples et petits "sketch" d'initiation, il faudra bien qu'il rentre dans la "datasheet".

Alors est ce plus difficile d'apprendre les 160 instructions de l'ATmega ou la syntaxe du langage C ?

Car le but est tout de même de se faire plaisir en réalisant des petites applications muent par un "firmware" que l'on a écris soi même.

Bonne journée à tous.

[Jack]

Alors je me permet de poser la question, est ce que un amateur ne fait pas fausse route en essayant d'apprendre à utiliser les microcontrôleurs via un langage dit, de haut niveau ?

Ta vision des choses est biaisée par le fait que tu sais déjà programmer en assembleur. En partant du cas d'un débutant total, il me semble que l'apprentissage du langage C sera plus rapide que l'assembleur. De plus, apprendre le langage C est un investissement rentable: il va permettre de programmer TOUS les processeurs. C'est d'ailleurs pour cela qu'il a été créé: concevoir un système d'exploitation indépendant du processeur.

Dès la première compilation un détail m'a frappé : 1600 octets pour faire clignoter une led (!)

Il faudrait voir de quoi est composé ce code, mais à mon avis la partie écrite pour faire clignoter la led doit être très courte. Le reste doit correspondre à l'initialisation de la partie matérielle: PLL, I/O, etc.
Essaie d'ajouter la gestion d'une ou deux I/O et tu verras que la taille du code ne va guère augmenter.

Pour ma part, j'ai commencé par programmer en assembleur sur 6502, Z80, 68000 et je ne regrette vraiment pas le passage au langage C.

[invite145419a0]

Bonjour Jack,

Disons que en prenant un Arduino, je voulais passer à un langage qui me permette d'utiliser de nouveaux processeurs sans pour cela se focaliser sur un modèle.
Mais il faut reconnaitre que passé les premiers programmes simples, si on veut aller plus loin, il faut tout de même se pencher sur la structure interne du processeur concerné.
Et il me semble alors plus complexe de réaliser, par exemple des manipulations ou des tests de bits avec un langage de haut niveau.

J'ai été déçu aussi par l'argument premier attribué au C, sa portabilité.
Prenez un programme écrit pour un compilateur x et essayez de le compiler avec un compilateur Y, résultat : xxx ERRORs

Le même problème se retrouve avec l'assembleur, mais là on ne revendique aucune portabilité.

Bref, j'aimerais bien être convaincu que l'effort pour apprendre un langage comme le C peut être payant, mais j'ai des gros doutes.

Pour ce qui est du programme Arduino blink.ino, je ne sais absolument pas de quoi il est constitué pour occuper tant d'espace.
Et je ne vois pas comment je peux le savoir.
En désassemblant le *.hex ? je vais certainement trouver 3000 jumps, vers des librairies pas vraiment utiles.

Ayant été habitué, certainement comme vous, à compter mes cycles machine et à choisir soigneusement mes instructions pour économiser chaque octet de la mémoire, et caser une routine entre deux interruptions, j'ai un peu de mal à accepter cette opacité.

Mais je continue à suivre ce post qui semble ouvrir des perspectives plus vastes que le monde Arduino ....

Bonne après midi à tous.

[Jack]

J'ai été déçu aussi par l'argument premier du C qui est sa portabilité.

C'est vrai pour des programmes assez simples qui ne font que modifier les périphériques du µContrôleur.
Pour des applications un peu plus conséquentes, on peut écrire une couche qui n'est pas portable puisque directement liée au hardware, et par dessus une autre indépendante du hardware: on retrouve régulièrement le terme "HAL" dans la littérature info (HAL = Hardware Abstraction Layer).

Et il me semble alors plus complexe de réaliser des manipulations de bits avec un langage de haut niveau.

on retrouve toutes les opérations logiques en C, mis à part la rotation. Les compilateurs sont aujourd'hui très performants. Il sauront par exemple très bien utiliser une instruction comme bitset si celle-ci est la plus rapide alors que le programme en C aurait fait un ET avec un masque, ou utilisé une structure de type bitfield (oui, en C on peut accéder à un ou plusieurs bits directement).
Il me semble que parmi tout ceux qui ont franchi le pas, peu sont revenus à l'assembleur. Ça vaut peut-être le coup d'insister un peu. Au final, tu continuera avec la solution qui te procure le plus de plaisir.

A+

[PA5CAL]

Bonjour

Disons que en prenant un Arduino, je voulais passer à un langage qui me permette d'utiliser de nouveaux processeurs sans pour cela se focaliser sur un modèle.
Mais il faut reconnaitre que passé les premiers programmes simples, si on veut aller plus loin, il faut tout de même se pencher sur la structure interne du processeur concerné.
Et il me semble alors plus complexe de réaliser, par exemple des manipulations ou des tests de bits avec un langage de haut niveau.

J'ai été déçu aussi par l'argument premier attribué au C, sa portabilité.
Prenez un programme écrit pour un compilateur x et essayez de le compiler avec un compilateur Y, résultat : xxx ERRORs

Il est important de ne pas confondre le langage de programmation et ses applications.

On ne peut raisonnablement pas se plaindre si un programme écrit pour un ascenseur ne fonctionne pas sur une machine à laver. Ce n'est pas le langage qui est en cause, mais les spécificités de l'application en terme d'algorithmes et de d'implémentation. Le principe est le même quand on programme pour des micro-contrôleurs, où les spécificités du matériel apparaissent rapidement dans le code.

Un programme écrit en C ou en C++ est portable dès lors qu'il suit la norme et qu'il concerne des cibles similaires.


Mais il est un fait qu'en changeant de µC, on risque de modifier notablement la cible, et de devoir, sinon réécrire une partie du programme, au moins prévoir des aménagements dans le code pour prévoir les différents cas de figure.

D'autre part, parce que de nombreux compilateurs autorisent à s'écarter de la norme, on croit souvent produit du "bon" code source en C, alors qu'il s'avère qu'il ne serait pas compilable avec d'autre chaîne de développement en C. L'AVR-GCC utilisé dans l'Arduino est particulièrement permissif, et il est probable que les programmes en C/C++ issus de cet outil aient quelque mal à voir d'autres horizons si l'on n'y prend pas garde.

Si tu es curieux, je t'invite à re-compiler tes programmes (soi-disant) en C ou en C++ en activant les options de vérification stricte de ton compilateur. Tu risques d'avoir de grosses surprises.

Bref, j'aimerais bien être convaincu que l'effort pour apprendre un langage comme le C peut être payant, mais j'ai des gros doutes.

J'utilise le C depuis plus d'une trentaine d'années, et je peux t'affirmer que l'effort a été très largement rentabilisé.

Le premier intérêt est d'apprendre à développer, indépendamment du langage. Le second est la portabilité du langage, qui contrairement à ce que tu penses, est bien réelle, mais réclame qu'on s'y attache un minimum si l'on souhaite en tirer effectivement partie.

Pour ce qui est du programme Arduino blink.ino, je ne sais absolument pas de quoi il est constitué pour occuper tant d'espace.
Et je ne vois pas comment je peux le savoir.
En désassemblant le *.hex ? je vais certainement trouver 3000 jumps, vers des librairies pas vraiment utiles.

Pas besoin de désassembler. Arduino est un projet open-source, et tout est disponible en clair, et généralement en langage C.

Ayant été habitué, certainement comme vous, à compter mes cycles machine et à choisir soigneusement mes instructions pour économiser chaque octet de la mémoire, et caser une routine entre deux interruptions, j'ai un peu de mal à accepter cette opacité.

Il n'y a pas d'opacité, juste un manque d'information, voire quelques illusions.

En principe, l'optimisation est réalisée par le compilateur. Les bons compilateurs obtiennent généralement de meilleurs résultats que les bons programmeurs.

Il est toutefois possible de faire des choix astucieux pour favoriser cette optimisation. Pour cela, il faut connaître les rouages du système de développement et de la cible. Mais il n'y a pas de miracle, cela passe forcément par un travail d'investigation préalable.

[invitedca01a58]

Hello Carthorix

Je comprends très bien ce que tu racontes en ce qui concerne l'opacité des langages de "haut niveau". Je crois que c'est particulièrement vrai pour le langage propre de l'Arduino. En assembleur, chaque instruction est limpide et le processeur ne fait rien "sous la table". Ce qui est moins limpide en assembleur, c'est qu'il faut accumuler pas mal d'instructions élémentaires pour assurer une fonction, dont on risque de ne plus comprendre le sens si le programme n'est pas bien commenté.
Le langage C est un peu entre le langage Arduino et l'assembleur. Tout en permettant de rester très proche de l'assembleur, il est plus concis et plus explicite que l'assembleur à la relecture.
Ce qui est pas mal, c'est qu'on peut profiter du support hardware de l'Arduino et programmer le µC en C ou même en assembleur.

Pour ma part, je trouve les mots-clés du C faciles à apprendre. Par contre, j'ai plus de mal avec la syntaxe (p.ex. variables static, variables extern, organisation en multi-fichiers .h et .c , etc...). Dans le temps, j'ai programmé en turbo Pascal et je ne me souviens pas avoir eu autant de difficultés (mais bien sûr, j'avais aussi 30 ans de moins ! C'est peut-être là qu'est le hic. La souplesse d'esprit diminue certainement avec l'âge). Peut-être qu'une part de la difficulté provient aussi du fait que le langage C effectue peu de contrôles (types de variables, dimension d'arrays, etc...)

Pour être plus concret, je suis toujours sur mon petit programme d'utilisation d'un afficheur LCD comme terminal série. Je pense que le programme est presque au point mais depuis 2 jours, je suis coincé sur un comportement anormal dont je ne trouve pas la cause. Je finirai bien par la trouver mais en attendant, c'est le black out.

Carthorix, ce serait chouette que tu te joignes à nous. Si on a dur de se débrouiller en C, au moins entre débutants on se comprend.

[invite145419a0]

Bonjour,

Oh, mais je reste parmi vous même si je ne peux pas apporter grand chose, étant débutant (et un peu réfractaire) aux langages de haut niveaux.

Pour Jean marie45, l'afficheur LCD commandé en I2c, ça fait partie des petits softs que j'ai écris en assembleur 8051 il y a pas mal d'années.
J'avais tendance à écrire de façon très modulaire et à arranger mes routines pour ne pas avoir à tout réécrire.
Mes programmes étaient relativement courts, mais comportaient beaucoup d' "#include".


La je suis un peu bloqué car j'attends une nouvelle (vraie) carte ATmega2560 car j'ai grillé la première.
En fait je l'avais commandée en Chine et je l'ai reçue brute de montage, c'est à dire sans aucun firmware.

Imaginez la galère quand vous débutez avec un Arduino, car comme tout le monde, je mettais en cause le driver USB Windows 7 64bits, j'en ai installé des dizaines ...
J'ai pu enfin communiquer après avoir programmé l'ATmega16U2 mais après ça s'est gâté quand j'ai tenté de programmer le bootloader dans l'ATmega2560, le courant d'alimentation est monté à 800mA pendant ... le temps de tout couper.
Et puis plus rien.
Donc si vous êtes tenté par une carte chinoise ATmega2560 à 9 euros .... attention !

Bonne journée à tous.

[invitedca01a58]

J'ai une carte UNO R3 ordinaire qui vient aussi de Chine et très bon marché, mais je n'ai pas eu de problème.

L'ennui des cartes Arduinos, c'est qu'elles sont limitées à un seul µC.

[PA5CAL]

L'ennui des cartes Arduinos, c'est qu'elles sont limitées à un seul µC.

Si tu parles des différentes architectures de µC disponibles, les cartes Arduinos donnent l'occasion de programmer de l'AVR (Uno, Leonardo et Mega soit trois modèles différents), de l'ARM (Due) et du MIPS (Yún). L'IDE permet de développer directement pour les deux premières.

Si tu parles juste du nombre de µC par carte, la plupart en ont deux.


Je crains que les critiques que tu formules à propos des Arduinos ne tiennent qu'au fait qu'ils ne correspond pas vraiment à tes besoins personnels (tu sembles en attendre beaucoup plus que ce pour quoi ils sont conçus), et que tu n'es pas non plus forcément bien informé à leur sujet (ce qui pourrait être la raison de ce qui précède).

L'intérêt d'Arduino réside dans la possibilité de mettre en œuvre, vite et avec peu de moyens, des éléments logiciels et matériels pour réaliser des maquettes ou des appareils fonctionnels. C'est en quelque sorte un jeu de Légo™ micro-informatique pour le débutant ou l'amateur, sans soudure ni investissement dans des moyens de développement professionnels, et destiné à l'initiation ou au bricolage.

Cette immersion rapide dans le domaine technique a pour but d'atteindre rapidement des résultats tangibles en terme de réalisation, mais certainement pas en terme d'apprentissage académique des métiers de développement, ni de découverte des matériels, méthodes et outils logiciels disponibles pour l'industrie.

Notamment, le système Arduino n'est pas fait pour apprendre les langages C/C++, pas plus que l'électronique numérique. Mais il offre un bon prétexte pour débuter, une motivation pour persévérer et approfondir certaines questions en allant voir ailleurs.


Pour faire un parallèle avec la cuisine rapide, quand j'achète une pizza 4-fromages surgelée à la supérette, je ne m'attends pas à ce que l'étiquette m'apprenne comment en fabriquer une moi-même, ni à trouver également une tarte aux pommes en ouvrant l'emballage. Je ne vois pas pourquoi il en serait autrement avec les Arduinos, qui dans leur domaine sont tout-à-fait assimilables des produits de "cuisine rapide".

Bref, si les Arduinos ne répondent pas à tes attentes, ce n'est peut-être pas à cause de leurs carences supposées, mais plus probablement parce que tu t'es trompé en les choisissant.

[invitedca01a58]

Hello PA5CAL,

Lorsque j'ai écrit "L'ennui des cartes Arduinos, c'est qu'elles sont limitées à un seul µC", je me rend compte que je me suis mal exprimé. En fait, j'ai voulu dire que lorsque tu as une carte UNO par exemple, tu es pratiquement obligé de travailler avec l'Atmega 328. Pas question de tester un Atmega 32 ou un Attiny 2313 par exemple. Mais tu as raison, il existe de nombreuses cartes Arduino.

Pour le reste, je suis tout à fait d'accord avec ta manière de positionner les Arduinos. Ils occupent un créneau valable et permettent d'obtenir un résultat rapide sans trop s'y connaître en informatique ou en électronique.

Les Arduinos ne sont pas faits pour apprendre le C ou le C++ mais ils peuvent quand même servir de support dans ce but à condition de s'éloigner de l'IDE et du dialecte dédié, la carte Arduino ne servant alors qu'à fournir l'alimentation, une connexion USB série et des connecteurs de port.

En gros, si je donne un peu l'impression de critiquer l'Arduino, c'est effectivement parce qu'il ne répond pas vraiment à ma demande. J'ai acheté ma carte UNO en prévision du cours d'introduction au langage C que j'ai suivi. La carte a bien rempli son rôle mais je préfère poursuivre avec l'une ou l'autre petite carte de développement générique car plus ouverte.

[PA5CAL]

En fait, j'ai voulu dire que lorsque tu as une carte UNO par exemple, tu es pratiquement obligé de travailler avec l'Atmega 328.

... De même que quand tu fais une paella, tu es "pratiquement" obligé de mettre du riz.

Les cartes Arduino n'ont jamais été des cartes de développement universelles, utilisables avec plusieurs modèles de processeurs. Comme je l'ai rappelé, ce n'est pas leur finalité.

Et puis une carte Uno, c'est juste (par définition) un ATmega328P et une interface série-USB. Les deux sont montés sur un circuit imprimé avec quelques connecteurs, deux régulateurs de tension et trois leds. L'ATmega328P est la pièce maîtresse qui caractérise cette carte. Changer le reste ne modifierait pas grand chose, mais le remplacer, lui, en plus d'imposer de refaire le circuit imprimé, donnerait un résultat qui n'aurait plus aucune raison de s'appeler Uno... ni peut-être même Arduino.

[invitedca01a58]

Il y a +/- 2 ans, j'avais commencé à réfléchir à un projet de construction d'une carte de développement couvrant la plupart des AVR. Entre-temps, un autre projet est venu s'intercaler, reportant la carte de développement à plus tard.

Le principe de la carte de développement était le suivant : une carte de base sans le µC à tester mais comprenant tous les outils accessoires : l'alimentation, des connecteurs de Port I/O avec les 8 bits + l'alimentation, la connexion USB-série, le connecteur USB de programmation (avec usbasp ou ISP mkII intégré), un connecteur JTAG, des connecteurs USART, I2C et SPI, des leds-témoins avec transistor, un speaker piezo, des sorties de puissance.

Pour l'implantation du µC, un grand connecteur de style ISA dans lequel on pourrait enficher une carte comprenant un connecteur ZIF et un soquet pour le quartz avec ses 2 condensateurs. Avec 3 ou 4 cartes à ZIF différent, on peut couvrir toute la gamme des AVR, du moins ceux en soquet DIL.

C'est dans le cadre de ce projet que j'avais écrit un programme assembleur d'un afficheur LCD comportant son propre µC et communicant avec la carte principale par USART.

J'essaye actuellement de transposer une partie de ce programme en C et je planche sur le debugging.

[Biname]

Hello,

Le code 100% portable sur une machine au hardware variable est un mythe quoique les OS ... Il y a cette vieille publicité IBM de ?2006 sur le sujet :

https://www.youtube.com/watch?v=AIOqOxI0K_I

Biname

((((((((Ah oui, en C la fonction asm {} permet d'inclure du code assembleur dans C en utilisant les variables et fonctions définies sous C))))))) ce ne sera pas portable

[invite145419a0]

Bonjour,

Ah, la carte µP Universelle !
On s'y est tous essayé .... les industriels aussi, et il y en a encore une grande quantité sur le net.

Personnellement j'ai cessé d'y croire depuis longtemps.

A un moment il faut faire le choix d'un µP sachant très bien qu'il sera obsolète très rapidement.
Autant pour des industriels ce choix est crucial, autant pour un amateur l'importance est moindre, à partir du moment où il maitrise sa structure interne et qu'il obtienne des résultats tout en prenant plaisir à programmer.

Après les 6800, Z80, 6502, les Pics, je m'étais beaucoup investi dans la famille 8051 (en assembleur) et particulièrement sur les 89c4xx de Dallas.
J'ai gravé des dizaines de circuits imprimés sans jamais obtenir "La carte Universelle".

J'utilise Eagle depuis les versions sous Dos, et je ré-utilise les schémas et librairies (comme en Assembleur) pour créer à chaque fois une carte qui corresponde exactement à mon projet.

Aujourd'hui, je fait comme Jean-Marie 45, j'utilise les cartes chinoises car elles sont à des prix imbattables, et je les enfiche sur un circuit imprimé maison, qui comporte les interfaces. (Arduino Nano par exemple)

Au fait je viens de réécrire le programme "blink" en assembleur sur ATMega328P :
[.cseg] 0x000000 0x00023e 66 0 66 32768 0.2%

66 octets !

Je suis très mal parti pour le C

Bonne journée

[PA5CAL]

Au fait je viens de réécrire le programme "blink" en assembleur sur ATMega328P :
[.cseg] 0x000000 0x00023e 66 0 66 32768 0.2%

66 octets !

Je suis très mal parti pour le C

Question performances du résultat, l'assembleur est imbattable, c'est un fait. Mais il n'est absolument pas portable, contrairement au C.

Bien entendu, cette portabilité ne concerne pas les éléments d'architecture du système. Mais tout le reste gagne à être écrit dans un langage comme le C lorsqu'il s'agit de gagner du temps de développement, ou de recherche et de formation dans le domaine du produit visé.

Pour une entreprise ou un amateur début, il est souvent beaucoup plus rentable d'écrire dans un langage de haut niveau, quitte à utiliser un matériel un peu sur-dimensionné par rapport aux besoins.

Arduino en est un bon exemple : le programme blink fonctionne indifféremment sur un Uno (µC AVR) et sur un Due (µC ARM) sans qu'il soit nécessaire d'y changer une virgule, ni de se plonger dans l'étude du hardware de ces microcontrôleurs pour l'adapter comme on le souhaite.

[invite145419a0]

Bonjour,

Une question PA5CAL, le C l'avez vous appris de façon didactique pendant vos études ou tout seul en regardant ce que d'autres avaient écris ?

Il y a une dizaine d'années j'ai acheté le Kernigan&Ritchie et j'avoue que je me suis endormis dessus plusieurs soirs.

J'espère que le système Arduino sera plus motivant.

J'attends ma nouvelle carte ATMega2563 pour m'y remettre, car sur la carte chinoise je crois bien qu'en plus de ne rien avoir programmée dans les deux micros, l'oscillateur du 2560 est HS.
Au programmateur ISP, il est bien reconnu et se programme bien, mais il n'exécute rien, et comme (je suppose) que le programmateur externe n'utilise pas l'horloge du micro ...

[invite1d577638]

Au programmateur ISP, il est bien reconnu et se programme bien, mais il n'exécute rien, et comme (je suppose) que le programmateur externe n'utilise pas l'horloge du micro ...

Tu es sûr de ta configuration de fuses ?

[PA5CAL]

Une question PA5CAL, le C l'avez vous appris de façon didactique pendant vos études ou tout seul en regardant ce que d'autres avaient écris ?

J'ai commencé à apprendre le C tout seul, avec des bouquins et en pratiquant sur de petits systèmes, après avoir fait du BASIC, du COBOL et de l'assembleur (ou plutôt des assembleurs).

Ensuite je l'ai (ré-)appris à l'école, mais d'un point de vue beaucoup plus théorique, ce qui m'a été fort utile. L'enseignement académique m'a permis d'apprendre des choses qu'il m'aurait certainement été impossible de découvrir tout seul, et aussi de confirmer certains points que je soupçonnais mais que je m'interdisais de généraliser.

À l'époque il n'y avait pas Internet, les bouquins étaient chers pour un étudiant, et les magazines ne donnaient pas beaucoup d'exemples. Je n'ai réellement pu commencer à lire du code en C écrit par d'autres que lorsque j'ai commencé à travailler... et c'était plutôt pour le corriger que pour m'en inspirer.

J'espère que le système Arduino sera plus motivant.

Comme je l'indiquais, Arduino n'est pas vraiment fait pour apprendre, mais pour s'initier (note la nuance) et pour aboutir rapidement à des réalisations. Et ça c'est certainement motivant. Toutefois, la motivation ne peut être suscitée que s'il y a déjà des envies à la base, car dans le fond elle doit quand même venir de la personne qui pratique.

Quoi qu'il en soit, ce n'est certainement pas la pratique de l'Arduino qui permettra de faire le tour de la question s'agissant du C et du C++, qui sont des langages habituellement mis en œuvres sur des systèmes plus gros, lesquels n'offrent pas les mêmes possibilités ni n'exposent aux mêmes problématiques qu'une petite carte à µC.