Je ne comprends pas pourquoi certains s'entêtent à vouloir programmer en langage évolué pour passer vers un compilateur interpreteur... alors même qu'ils travaillent sur un micro à architecture RISC qui ne comprend que quelques instructions... par exemple 35 pour les PICs...
Je crois que nous sommes victimes de la mode... consommer le plus vite possible, sans chercher à s'adapter... il faut que le produit s'adapte à nous...
Vous aurez compris que je ne suis pas d'accord...
Je ne suis pas daccord avec toi.
Microchip à sorti la famille 18F qui possede plus d'instruction et rendant l'execution du code vraiment plus rapide. J'ai pu tester que pour un même programme, les pics 18F executés 4 fois plus vite leur code que les 16F à frequence egales !
deplus, l'utilisation d'un language un peu plus haut niveau que l'assembleur permet une simplicité d'utilisation, donc une diminution du coût de la mise en oeuvre.
En realité, plus beaucoup de gens programment en assembleur.
Bonsoir,
De plus un bon compilateur fait aussi bien et quelque fois mieux qu'un bon programmeur humain en assembleur et bien mieux que le vulgum pecus.
JR
l'électronique c'est pas du vaudou!
Non je ne suis ni Simplet (7 nains) ni demeuré et je programme en Basic.
Proton+, voilà le nom du compilateur.
Et franchement, je me contre fiche de gagner quelques µs voire ms.
C'est toujours assez rapide pour moi.
Je pense que le meilleur langage est celui ... dont on sait se servir.
En poussant le raisonnement un peu plus loin, pourquoi ne pas programmer en hexadécimal directement puisqu'il n'y a que 35 codes à retenir, on gagnerait la phase d'assemblage.Envoyé par CAPLOKI
Sérieusement, le fait que ce soit un risc justement rend les choses encore plus compliquées, puisqu'il faut encore plus d'instructions pour faire la même chose qu'un cisc.
Il ne me viendrait même pas à l'esprit de repasser à l'assembleur, sauf dans 0,01% des cas tellement un langage de haut niveau présente d'avantages.
En tout cas je ne vois vraiment pas l'utilisation du C par exemple comme une mode pour développer des appli sur µC.
A+
Idem, si on n'a pas une application avec un timing hyper précis et un besoin de mémoire minimal, je ne vois pas l'intérêt de faire tout en assembleur. De plus, ces deux critères supposent un bon codeur assembleur (on peut faire pire que mieux si on n'a pas les bons algorithmes).
On y gagne énormément en lisibilité et en rapidité d'écriture.
Pour les phases plus critiques, rien n'empêche de passer en assembleur (je suis sur un projet nécessitant un temps précis + une gestion d'afficheur LCD; le timing est en assembleur, le reste, je ne vois pas l'intérêt de re-coder toute la gestion de l'afficheur alors que des librairies de haut niveau existent). J'ai une fois géré un afficheur en assembleur, je vois bien la différence...
Cela dit, je ne trouve pas ça inutile d'avoir fait un peu d'assembleur pour comprendre une logique de programmation plus bas niveau que l'on peut appliquer à un langage évolué.
Salut,
Il y a des millions d'applications qui n'auraient jamais vu le jour si on n'utilisait pas les langages évolués.
Les améliorations incessantes des composants (taille mémoire, conso, boitiers, vitesse) ont permis d'évoluer de l'assembleur vers des langages évolués indispensables à certaines applications (avionique, voitures,..).
Que ce soit une architecture RISC ne veut pas dire pour autant une "explosion" de la taille du code !
Par exemple la nouvelle famille PIC16F1xxx (enhanced) a permis de réduire la taille du code C généré de 40% vis à vis du coeur standard PIC16 grâce à l'addition intelligente de 14 instructions orientées compilateur C et gestion de banques (donc 49 instructions au lieu de 35 originellement).
La première famille de PIC avait un jeu d'instruction orienté purement assembleur, ce qui explique sont manque de bonne compression du code lors de la compilation C.
a+
En fait, je ne comprends pas bien.
Certains, ici même sur ce forum, disent que la vulgarisation de l'electronique doit passer par la connaissance de tous les composants...
Et je crois avoir lu que tout le monde était d'accord : les microcontroleurs ne doivent pas faire oublier l'existence des autres composants actifs.
En ce qui concerne la programmation, il semblerait qu'on tombe dans l'excès inverse...
Je me rappelle avoir mis au point plusieurs programmes de division en assembleur, en fonction des besoins de mes applications. Ces programmes tournaient plus ou moins vite selon les exigences et selon le code.
Si il suffisait de diviser par 2... no comment...
Si il fallait divisait part un nombre entier sur 8, 16, 24 ou 32 bits...
Et si il y avait des décimales... sur 8, 16, 24 ou 32 bits...
En language évolué je ne pense pas que vous ayez autant de choix de division. Des petits sous programmes faciles à créer seront autant de librairies. En plus, si vous en avez vraiment besoin (mais l'envie se fera plus forte que le besoin) vous apprendrez vite à optimiser votre code...
Je me rappelle avoir optimiser le code d'une division 24.24 par 24.24.
Vous apprendrez à travailler sur un produit, malgré vos connaissances dans tel ou tel domaine... Il faudra vous adapter... ce n'est pas le produit qui ira vers vous... (Je pense que le problème est là)
Ce qui est bon en hardware doit aussi l'être en software.
Amicalement
CAPLOKI
Pour connaitre tous les composants .... tu n'auras pas assez d'une seule vie !
Mon avis sur la programmation :
L'assembleur est nécessaire pour bien comprendre les mécanismes du µC.
Pour certaines routines critiques (j'ai une routine d'interruptions d'horloge) qui est en asm, le reste du prog en Basic.
Une fois que l'on a bien assimilé les tripes du µC, on peut passer au haut niveau, quel qu'il soit, suivant ses affinités. C'est vrai que le C est bien implanté.
Mon Basic, connait les nombres à virgule flottante, les variables 32 bit, I2C, SPI, LCD, RS232 ...
Il y a de quoi faire.
Quand j'ai utilisé pour la 1re fois le bus I2C, ça a marché du 1er coup de même pour la RS232.
En asm, j'aurai mis plus longtemps et pas forcément avec ce résultat.
Un autre truc quand on commence : LA MODESTIE !
1 : faire clignoter une LED, pas basique du tout
2 : tempo avec IRQ de TMR
3 : CAN
4 : LCD
.....
mais toujours commencer par 1.
Question obtimisation : ça me fait doucement sourire, c'est vrai qu'on est à quelques ms près !
Si le code fait 10 lignes de moins, il restera 10 lignes vides en plus dans la flash, pas de quoi fouetter un chat.
Bon assez radoté, tout ceci n'est que mon avis, tu en prends ce que tu veux.
Il n'y a pas vraiment de problème avec un compilateur C.Je me rappelle avoir mis au point plusieurs programmes de division en assembleur, en fonction des besoins de mes applications. Ces programmes tournaient plus ou moins vite selon les exigences et selon le code.
Si il suffisait de diviser par 2... no comment...
Si il fallait divisait part un nombre entier sur 8, 16, 24 ou 32 bits...
Et si il y avait des décimales... sur 8, 16, 24 ou 32 bits...
Pour la division par une puissance de 2, n'importe quel bon compilateur va le traduire par un ou plusieurs décalages à droite, donc aucune perte d'efficacité.
Pour les autres divisions, on peut souvent traiter en division entières et en virgule fixe.
Après, pour les calculs en virgule flottante, le problème est le même en C ou en assembleur. J'avais dû exploiter une ROM qui possédait des routines de calcul en virgule flottante en assembleur. Il m'a fallu des jours pour assimiler les principes, les librairies et mettre le programme au point. En C, il aurait juste fallu le temps d'écrire l'équation.
En conclusion, il est toujours bon de connaitre le fonctionnement d'un système à un niveau de détail plus fin que celui qu'on utilise normalement, mais pour le quotidien je pense qu'il faut aller directement au fait et ne pas à avoir à réinventer la roue tous les jours.
A+
Il y a aussi un autre fait que l'on a pas mentioné.
C'est qu'un micro possede un certain nombre d'instruction par exemple 35. C'est plutôt facile de les memoriser. Mais dés lors que tu va avoir affaire à des micro de 83 instructions, tu va vite en utiliser certaines et pas d'autres.
Le compilateur C lui, utilise toutes ces instructions afin d'optimiser ton code, donc au finale, il est plus performant.
Tout les nouveaux micro sorti par microchip possedent prés de 80 instructions.
Bonsoir,
Ayant la chance d'être un dinosaure j'ai donc eu le privilège de mettre au point du microcode sur des calculateurs entièrement faits au moyen de logique élémentaire, de vrais RISC, il avait une vingtaines d'instructions mais de type CISC, et d'écrire ensuite le code en assembleur (si l'on peut dire) et franchement bien que formatrice l'expérience fut fastidieuse.
On peut faire le // avec les langages de description hardware, les premiers PAL (MMI) étaient programmés en binaire, entièrement à la main, aujourd'hui il y a le VHDL et Verilog et je ne reviendrais pas en arrière.
Ceci dit tel qui programme cochon et inefficace en langage bas niveau fera guère mieux en langage évolué.
Pour un amoureux de l'assembleur je lui conseillerais de se frotter à du Transputer (T800) ou aux premiers DSP (AMD, Texas, Moto) là on pouvait faire mieux que le compilateur mais à quel prix!
JR
l'électronique c'est pas du vaudou!
