ABCelectronique : portail d'information dans le domaine de l'électronique

Merci de ne pas poster des messages en relation avec le piratage.


    Forums de Abcelectronique > Electronique Analogique et Numérique
  » Discussion devenue débat sur les microcontroleurs
Identifiant Se souvenir de moi ?
Mot de passe
Fermé     Nouvelle discussion

Page 1 sur 3

Discussion devenue débat sur les microcontroleurs

 

thm
thm 21/01/2011, 22h39 #1  
Cette discussion a été séparée de celle-ci:
http://www.abcelectronique.com/foru...ead.php?t=71467
Tant que le débat portera sur les avantages et inconvénients des différents µC elle durera.
Mais elle sera supprimée si elle devient agressive ou irrespectueuse envers les participants. Maîtisez-vous.
Fas54.






Posté par mpg


Le problème est qu'aujourd'hui, il n'est pas "bien vu" de dire que l'on programme en assembleur. "Espèce de dinosaure"... Et pourtant, quand on connaît les bases, c'est beaucoup plus facile de passer au reste.
Salutations.



Argument invoqué 99 fois sur 100 par des bidouilleurs de pic 12, 16 ou 18 (qui comme je l'ai mentionné sont des µC poussifs et dépassés) ..... Je n'ai jamais (ou très rarement) vu un utilisateur d'AVR ou de 68HC ou d'ARM ou de MSP430 être de cet avis...

Th.

Dernière modification par Fas54 24/02/2011 à 11h48.
mpg
mpg ★★★★★☆☆ 21/01/2011, 23h10 #2  
Posté par thm

Argument invoqué 99 fois sur 100 par des bidouilleurs de pic 12, 16 ou 18 (qui comme je l'ai mentionné sont des µC poussifs et dépassés) ..... Je n'ai jamais (ou très rarement) vu un utilisateur d'AVR ou de 68HC ou d'ARM ou de MSP430 être de cet avis...

Th.

Juste pour préciser ; je serais plutôt de la famille PICophobe. J'ai commencé il y a quelques années maintenant sur 6809, puis continué sur 68HC11, puis sur 80552 puis sur Z8, puis... Enfin bref, lorsque des collègues ont "amené" la famille PIC à la boîte, je n'ai pas plongé, mais j'ai suivi de loin.

En ce qui concerne l'assembleur, ben perso, je suis fort content d'avoir commencé avec (même si ça n'a pas toujours été facile...). Mais ce n'est que ma sensibilité perso...

Et puis surtout, cela dépend de ce que l'on veut faire avec le micro : si c'est pour gérer quelques touches et un afficheur, effectivement, vive le C. Par contre, il m'est arrivé à plusieurs reprises d'être OBLIGE de revenir à l'assembleur pour pouvoir "passer" au niveau du projet (gestion de chip select, de codeurs, de tops de durées très courtes, etc...). Donc en résumé : selon l'utilisation...

Salutations.
__________________
Les pannes les plus complexes sont celles que l'on se fait soi-même...

Dernière modification par mpg 21/01/2011 à 23h17.
peufeu
peufeu ★★★★★☆☆ 22/01/2011, 00h11 #3  
Posté par thm

Argument invoqué 99 fois sur 100 par des bidouilleurs de pic 12, 16 ou 18 (qui comme je l'ai mentionné sont des µC poussifs et dépassés) ..... Je n'ai jamais (ou très rarement) vu un utilisateur d'AVR ou de 68HC ou d'ARM ou de MSP430 être de cet avis...



Au lycée je faisais des démos sur amiga... tout en assembleur bien sûr.

Maintenant, moins j'y touche, mieux je me porte : uniquement pour chercher les bugs du compilateur dans le code généré ! D'ailleurs l'assembleur 68k est le seul qui soit lisible...

J'ai eu besoin de routines de multiplication genre 16b * 8b pour un AVR, j'ai chopé une fonction en asm sur le net ... donc oui j'utilise de l'assembleur, sauf que je l'écris pas XDDD

Pour choisir un uC, le support compilateur C est un facteur très important...
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
Neptune
Neptune ★★★★★☆☆ 22/01/2011, 12h29 #4  
Posté par thm

#20 >> Argument invoqué 99 fois sur 100 par des bidouilleurs de pic 12, 16 ou 18 (qui comme je l'ai mentionné sont des µC poussifs et dépassés)

Bof, l'argument qui sue l'anti-Bigonoff, plein de condescendance et de mépris envers les utilisateurs classés en "bidouilleurs" ...

@+

PS.: Et la sentence du #12 se révèle correcte :-)

Dernière modification par Neptune 22/01/2011 à 12h31. Motif: Ajoute P.S.
carver
carver 22/01/2011, 13h05 #5  
C'etait à prévoir !
Bigonoff c'est quand même une pointure même si on n'aime pas les pics.........
peufeu
peufeu ★★★★★☆☆ 22/01/2011, 13h22 #6  
J'aime pas les PICs, mais je reconnais tout de même le talent du monsieur.

L'avantage des PICs c'est :
- le prix des modèles bas de gamme
- la diversité de la gamme

Mais il y a de nombreux inconvénients (architecture pourrie sur les anciens, silicon errata scabreux sur les nouveaux modèles, etc)

J'attends au tournant le Cortex-M0, ça devrait faire le ménage !
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
ftorama
ftorama ★★★★★★ 22/01/2011, 13h30 #7  
Posté par peufeu

J'attends au tournant le Cortex-M0, ça devrait faire le ménage !



+1000 je vais peut-être m'en prendre 1 ou 2 chez Farnell. à 2-3 euros la pièce, je prends pas un gros risque financier.

Quand tu vois les Cortex-M3, tu peux pas t'empêcher de laisser couler un filet de bave devant ces bijoux ^^

Sans compter les Cortex-M4 qui devraient expliquer ce qu'est un microcontrôleur avec des fonctions DSP
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits
peufeu
peufeu ★★★★★☆☆ 22/01/2011, 16h46 #8  
Mais ... quand j'avais regardé, les périphériques avaient l'air, ma foi, fort standard, rien de bien original...

Le top, ce serait d'avoir une mini-FPGA (toute petite, genre 50 cellules, ou 0.5% d'une Spartan-3) pour virer toute trace de petites portes logiques à la noix du PCB (ou faire des petits bouts de hard qui réagissent vite), ou encore des PWM reliés à des comparateurs analogiques (comme dans le AT90PWM3B)

J'ai essayé le psoc de chez cypress, c'est rigolo mais les performances de la "fpga analogique" sont pas terribles ! (euphémisme) et quand au uC c'est une vieille brouette...
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
ftorama
ftorama ★★★★★★ 22/01/2011, 17h05 #9  
Posté par peufeu

Mais ... quand j'avais regardé, les périphériques avaient l'air, ma foi, fort standard, rien de bien original...

Le top, ce serait d'avoir une mini-FPGA (toute petite, genre 50 cellules, ou 0.5% d'une Spartan-3) pour virer toute trace de petites portes logiques à la noix du PCB (ou faire des petits bouts de hard qui réagissent vite), ou encore des PWM reliés à des comparateurs analogiques (comme dans le AT90PWM3B)

J'ai essayé le psoc de chez cypress, c'est rigolo mais les performances de la "fpga analogique" sont pas terribles ! (euphémisme) et quand au uC c'est une vieille brouette...



Atmel a fait à une époque les FPSLIC. Je n'ai pas testé mais ça intégrait un AVR et une zone FPGA. A priori ils sont rangés dans la catégorie obsolètes.

Concernant les interactions "automatiques" entre les périphériques, les Cortex-M3 ont l'air de faire très fort. Les ADC sont préconfigurés pour des séquences d'acquisition précises, ils sont "chainables" pour doubler la fréquence d'acquisition avec deux ADC, les timers interagissent dans tous les sens. Désolé de ne pas être plus précis, mais j'ai été largué ^^
Je crois que les interactions comparateur-ADC-PWM sont possibles comme dans l'AT90PWM
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits
Bigonoff
Bigonoff ★★★★★☆☆ 23/02/2011, 13h32 #10  
Salut - part1
-------------

Je me permets une réponse parce que j'ai été interpellé par mail sur ce sujet ;)

Désolé, je suis long, mais j'interviens une seule fois depuis le début, et vu qu'on parle de moi...

Je vais reprendre quelques points dans l'ordre :

Seulement le 68 hc11 c'est terminé depuis belle lurette



Ben oui, et ça, c'est un immense avantage pour les PIC : on a beau sortir de nouveaux modèles, les anciens restent en service, vendus, et suivis. On ne se retrouve donc pas avec une ancienne application HS pour raison que le micro est devenu obsolète.

Certains disent "les pic, c'est vieux et ringard" parce qu'ils regardent ces premiers modèles toujours en service, mais oublient de parler des nouveaux modèles au top.
Et évidemment, ils comparent ces vieux modèles avec les derniers atmel ou freescale, parce qu'il leur est impossible de comparer à génération égale puisque les modèles correspondant ont été froidement supprimés des catalogues (quand ce n'est pas carrément la marque qui a été remplacée)

Donc : Avantage net pour Microchip : la pérénité des modèles assurant qu'une carte ne devient jamais obsolète.

Je souhaiterai reprendre du début en préférant éviter les pics plutôt réservé au grand public et dépassé d'après ce que j'ai lu



Ce que tu en as lu, ce sont des idées reçues propagées (par exemple sur ce forum) par des gens qui, en fait, n'y connaissent rien.
Je dirai 2 choses :

1) Tu ne veux pas de micro "grand public", mais toi, tu trouves que tu ne fais pas partie du grand public en question? J'avais cru comprendre que tu parlais d'initiation.

2) S'il existait une marque supérieure en tous points aux autres, seule cette marque subsiterait sur le marché et toute marque obsolète aurait disparu. Sans quoi, c'est prendre amateurs et industriels pour des débiles qui n'y connaissent rien.

Dernièrement j'ai eu l'occasion de feuilleter le livre de tavernier microcontroleur AVR,il n'aborde pas l'assembleur,le c et le c++ d'après ce que j'ai vu,qu'en pensez vous?



Le C++ sur de petits microcontroleurs, j'en arrive à me demander si on n'est pas en train de sortir des termes à la mode plutôt que des réalités sur le terrain.

Le C est un complément éventuel pour des micro 8 bits relativement performants (pas pour les plus modestes), et devient un choix pertinent pour les micro >= 16 bits prévus pour cet usage. Ceci étant que même en utilisant le C, le langage d'assemblage est toujours un atout de plus dans sa poche, atout d'autant plus utile qu'on désire exploiter le maximum de possibilités d'un microcontroleur donné. Tout dépend donc de la cible et de l'application à réaliser.

Oui, enfin l'assembleur, c'est un peu masochiste tout de même !



C'est comme l'alphabet pour ceux qui apprennent à lire : c'est masochiste. Le fait est que ceux qui ne l'apprennent pas semblent éprouver certaines difficultés. Plus une cible est puissante par rapport à l'application, moins on a la nécessité de recourir au langage d'assemblage. N'empêche que c'est toujours un plus de savoir "comment ça marche" et surtout que c'est parfois la seule façon de se sortir d'une situation donnée. Ecrire sur PC en C++ dotnet, c'est super, mais si on a besoin d'un driver hardware, ça commence à poser problème si on ne connait pas un langage plus basique. C'est pareil avec les microcontroleurs.

Donc : se garder des termes génériques pour qualifier langages et processeurs, éviter de tomber dans les termes "à la mode", et surtout raison garder.

encore une fois , je ne crache pas sur les langages structurés, dont je me sers !
mais en cas de problo "délicat" pourvoir reprendre la main sur le code machine reste une voie eficace.



Je plussoie, je fais de même.

Je dirais que c'est utile si on veut comprendre, mais perso, à part pour activer/désactiver les interruptions, ça fait belle lurette que je n'ai pas tapé une ligne d'assembleur....et encore, la dernière fois, c'était par ignorance d'une façon plus simple de faire



De nouveau, tout dépend de l'application.
J'ai encore cette semaine deux mails d'utilisateurs de C qui semblent être fortement perturbés par la cohabitation d'un bootloader particulier avec leur code produit en C. Manifestement leur compilateur semble ne pas trop apprécier de leur laisser certaines adresses spécifiques libres.

Maintenant, c'est clair qu'on peut écrire un programme 100% en C, mais j'ai des applications où je dois maîtriser le timing à la µs près et sans perte de temps, et ça, je me vois mal le faire en C.

Moralité : ce n'est pas parce que quelqu'un n'utilise que le C sur un micro donné qu'un autre réalisant d'autres applications n'aura pas besoin de descendre au bas niveau. C'est pareil avec le PC : ce n'est pas parce qu'on a écrit Word en C# qu'on peut forcément réaliser un jeu vidéo fps en C#. Ce n'est pas qu'un des langages est supérieur ou plus primitif, c'est simplement que l'application détermine parfois le langage.

Or, si on connait le langage de plus bas niveau, on a une corde supplémentaire à son arc.

L'arduino semble être un bon choix dans ton cas.



On ne peut pas donner de conseils généralistes à quelqu'un, surtout s'il ne donne pas le cahier des charges des applications qu'il veut réaliser.

Soit on choisit une famille "générique" suffisante pour la grande majorité de ses applications prévues, et dans ce cas plus c'est universel et varié et plus on trouve de docs et d'exemple, mieux c'est.

Soit on choisit un modèle de micro particulier en fonction d'une application particulière, et dans ce cas il faut partir du cahier des charges.

Selon les derniers chiffres dont je disposais, Microchip est 7ème du marché des micros, loin derrière Renesas (1er), Intel, Motorola, NXP, ST, etc.
Atmel est 8ème.



On peut difficilement mettre dans le même classement Intel et Microchip, ça ne couvre pas les mêmes applications.

Un ARM ne couvre pas les mêmes applications qu'un PIC16F non plus, mais un PIC 32 bits ne rencontre pas d'avantage les mêmes besoins que le PIC16F. C'est inutile de comparer de cette façon, ça n'a aucun sens. Vu la logique "capitaliste" du marché actuel, il suffit de se rendre compte que si une société existe c'est qu'elle répond à un besoin. Et sauf à prétendre que les acheteurs sont débiles, c'est qu'il doit bien y avoir au moins une bonne raison.

Sinon, si on classait comme ça on pourrait en déduire que Linux, avec ses 10% de part de marché est largement "inférieur" à Windows. Je doute que les linuxiens interprètent le classement de cette façon.

Effectivement, si tu as fais du HC11 tu risques d'avoir des nausées quand tu verras de l'assembleur PIC.



Comme d'habitude, tu caricatures de façon grossière. Déjà parler d' "assembleur PIC", ça ne veut rien dire, sauf à mettre un 10F dans le même sac qu'un PIC32 bits.
Ensuite on a eu les mêmes discours dans le passé au niveau des microprocesseurs entre les défenseurs du CISC et du RISC. C'est un choix stratégique, aucun n'est LA référence. Ensuite, lorsqu'on prétend vouloir travailler en C, qu'importe la stratégie du langage d'assemblage, surtout que si on veut occasionnellement écrire un petit bout de code en "assembleur", moins on a à étudier, plus c'est simple.
Donc, un avantage peut devenir un inconvénient, et réciproquement.
De là à parler de nausée, ben il faudrait déjà commencer par démontrer que tu sais utiliser ce que tu critiques, et ça n'a jamais été le cas par le passé.

Je fais aussi partie de ceux qui pensent que l'asm n'est pas nécessaire pour 99 % des projets, sauf si tu choisis un de ces µC dépassés et poussifs que sont les pics 12, 16 et 18.



Je dirais qu'effectivement le langage d'assemblage n'est pas nécessaire pour 99% de TES projets.
Ne généralise pas des cas particuliers, tu n'es pas un exemple type d'utilisateur de PIC.

Pour ce qui est des PIC "dépassés", ben force est de constater qu'un 12F trouve toujours sa place dans un grand nombre d'applications actuelles, ce qui n'empêche pas à celui qui le désire d'utiliser une autre gamme.

Le HC11 est effectivement terminé, mais si le HC11 est obsolète,



Comprenez dans cette phrase insignifiante : Si votre micro n'est plus rentable pour Freescale, il vous sera imposé de changer de modèle (plus ou moins compatible en fonction des cas, voir l'historique de la firme et de Motorola). Pratique pour celui qui propose des réalisations conséquentes sur son site que de recommencer ses applications en fonction du bon vouloir d'une société commerciale.

Chez Microchip, on a la certitude que si on crée une carte et qu'on fournit un logiciel, les utilisateurs pourront continuer à la réaliser telle quelle durant des années et des années (pour ne pas dire : à vie).

De nouveau, c'est un choix stratégique, mais je doute qu'annoncer la fin de fabrication d'un modèle soit une bonne nouvelle pour les utilisateurs (qui cherchent des applications sur le net qui se retrouvent en outre obsolètes)
__________________
Vive l'internet libre
Bigonoff
Bigonoff ★★★★★☆☆ 23/02/2011, 13h33 #11  
Part2
-----

Je pense que ces µC sont au top : performances, debug, ide et outil de debug unique et bon marché pour les µC 8,16 et 32 bits. Une gamme homogène et des outils faciles, homogènes et gratuits. Et une communauté Fr active : www.68hc08.net qui répondra à toutes tes questions



Ils sont probablement au top dans une gamme d'applications donnée, mais ton problème est que tu laisses entendre qu'ils sont les seuls au top et qu'ils conviennent pour tout.

Concernant les outils, les autres marques aussi proposent des outils gratuits, une communauté active (Le picKit Microchip est open-source et géré maintenant par une communauté), et les outils deviennent maintenant chez Microchip utilisables sur Linux et Mac-OS (voir le nouveau MPLAB-X)

Sans compter que niveau exemples et documentations sur le net, c'est dur dur de battre les PIC.

Le problème est qu'aujourd'hui, il n'est pas "bien vu" de dire que l'on programme en assembleur. "Espèce de dinosaure"... Et pourtant, quand on connaît les bases, c'est beaucoup plus facile de passer au reste.
et la suite...



C'est bien dit, et le raisonnement est logique.

Argument invoqué 99 fois sur 100 par des bidouilleurs de pic 12, 16 ou 18



Pour information pour ceux qui lisent : le bidouilleur que je suis t'a déjà mis au défi plusieurs fois concernant des applications à réaliser : tu t'es toujours bien gardé de relever le défi.
Alors, franchement, comparer les utilisateurs de PIC à des "bidouilleurs", c'est te poser en qualité de juge... dont tu n'as pas le niveau.

(qui comme je l'ai mentionné sont des µC poussifs et dépassés) .....



Et j'ai déjà démontré par le passé que des Pic tu ne connaissais (et encore, mal) que les PIC16F. Alors, prétendre que les PIC sont poussifs et dépassés ça ne démontre qu'une seule chose : ton incompétence en la matière.

Je n'ai jamais (ou très rarement) vu un utilisateur d'AVR ou de 68HC ou d'ARM ou de MSP430 être de cet avis...



Je n'ai jamais vu non plus un utilisateur de PIC être de cet avis, cet avis n'étant que celui de quelqu'un qui ne maîtrise pas du tout le sujet (je l'ai déjà démontré publiquement par le passé).

Donc, oui, tu as le droit de trouver les freescale meilleurs que les PIC, mais il faut avoir l'honnêteté de dire qu'il ne s'agit que d'un avis subjectif correspondant à tes propres connaissances et aux applications que tu réalises (ou que tu tentes de réaliser).

Il suffit de chercher sur le net pour se rendre compte que les PIC sont présents dans des applications bien plus complexes que l'allumage d'une LED, même si c'est un excellent moyen didactique de commencer.

Et évidemment c'est pareil avec tous les autres protagonistes présents sur le marché, sans quoi ils auraient disparu.

Alors, donne ton avis, soit, mais ne donne pas cette avis en tant que "réalité", mais simplement en tant qu'avis subjectif d'un utilisateur spécifique.

Et surtout, surtout, surtout, arrête d'accompagner ton avis d'une critique systématique des PIC, parce que d'une part tu n'y connais strictement rien, que d'autre part tu n'as pas suffisamment fait tes preuves pour représenter une quelconque "référence" (moi non plus je ne suis pas une référence, juste un utilisateur aimant ce qu'il fait), et qu'enfin on peut défendre ce qu'on aime sans systématiquement chercher à dévaloriser ce que d'autres aiment (c'est lassant).

Du reste, c'est en grande partie à cause d'arguments comme ça que j'ai cessé de fréquenter ce forum, ça devenait lassant.
J'y reviens juste parce qu'on m'a interpellé sur ce sujet, que je voulais voir ce qu'on y disait, et qu'une fois de plus je retombe sur les mêmes arguments sortis par la même personne.

Au lycée je faisais des démos sur amiga... tout en assembleur bien sûr.
Maintenant, moins j'y touche, mieux je me porte



Moi aussi j'ai fait de "l'assembleur" sur Amiga (mon plus gros programme faisait 30.000 instructions). J'ai aussi programmé sur C64, sur TRS80, sur AIM65 etc.

Aujourd'hui, c'est clair que je préfère écrire un soft PC en C#, ça n'empêche pas de trouver utile le langage d'assemblage lorsque j'y trouve un intérêt.

uniquement pour chercher les bugs du compilateur dans le code généré



Quant on en arrive à devoir désassembler du code produit par son compilateur, je me dis qu'il y a un problème quelque part. Parce que je préfère écrire en langage d'assemblage que de me farcir le code en C, de le désassembler, de le modifier, puis de le réassembler : pour moi, ça, ce n'est pas une méthode de travail efficace (mais ce n'est que mon avis).

D'ailleurs l'assembleur 68k est le seul qui soit lisible



C'est un langage CISC, il a les avantages du CISC à la relecture.
Mais sinon, tu connais tous les autres pour dire que c'est le seul lisible?

J'ai eu besoin de routines de multiplication genre 16b * 8b pour un AVR, j'ai chopé une fonction en asm sur le net ... donc oui j'utilise de l'assembleur, sauf que je l'écris pas XDDD



La méthode copier/coller, ce n'est pas "utiliser". J'ai même un message type sur la première page de mon site concernant cette méthode. Ca m'a valu pas mal de courrier, genre "j'ai récupéré la routine machine et la routine chose et je n'arrive pas à tout mettre ensemble".

En outre, c'est se fier aveuglément à ce qu'un autre a écrit. Parfois c'est réaliste (librairies fournies par le constructeur), mais parfois nettement moins (j'ai vu des routines dispo sur le net ou, par exemple, l'utilisateur imposait des niveaux hauts sur un bus I²C).

Pour choisir un uC, le support compilateur C est un facteur très important



Ben oui.... si on programme en C, LOL.
Celui qui programme en basic n'a pas besoin du support du compilateur C, LOL
Et un support correct, ça veut dire, en passant, qu'on n'a pas à désassembler le code produit par le compilateur pour corriger "manuellement" les bugs.

L'avantage des PICs c'est :
- le prix des modèles bas de gamme
- la diversité de la gamme



Il y en a plein d'autres :

- La diversité des documents et des sources disponibles sur le net
- La qualité des documentations
- La pertinence des errata et la transparence à ce niveau
- Les outils de développement gratuits et maintenant disponibles pour Linux
- Le maintient en service des anciens modèles
- L'écoute des utilisateurs (j'en sais quelque chose)
etc.

Mais il y a de nombreux inconvénients (architecture pourrie sur les anciens,



Un ancien, c'est un ancien. C'est sûr que si on le compare aux dernières générations c'est plus rudimentaire.

N'empêche que de là à dure que l'architecture est pourrie, alors qu'à l'époque ces modèles tenaient le haut du pavé en terme de ventes, il y a une marge.

silicon errata scabreux sur les nouveaux modèles, etc)



Moi, je suis comme tout le monde : je n'aime pas qu'il y aie un problème hardware.
Mais entre me voir fournir un errata qui reconnait le problème (et le corriger dans la série de fabrication suivante) et un constructeur qui dit "tout va bien" et ne propose pas d'errata (du moins, pas de "délicat"), je choisis sans hésitation possible la première solution.

On a eu le cas récemment avec les 18Fxx8. Il y avait un bug très gênant qui est apparu (j'ai participé à le détecter et je l'ai signalé chez Microchip, ils m'ont même proposé un ICE4000 en prêt pour traquer le bug). Ce bug n'avait aucune solution.
Moralité, Microchip a signalé que ces PIC avaient un problème et les ont remplacés par les 18Fxx80 : identiques et compatibles mais sans ce bug et avec des fonctionnalités améliorées optionnelles.

Ce cas reste cependant rare, la plupart du temps il s'agit de bugs mineurs contournables par voie software et auxquels Microchip remédie dès le lancement de la ligne de production suivante (il suffit de suivre les numéros de versions).

Mon conseil en cas de nouveau produit est de toute façon le conseil que j'applique moi-même : lorsque sort un nouveau produit, ne jamais l'utiliser de suite et attendre qu'il passe les premiers tests "grandeur nature" pour ne pas essuyer les plâtres. Si on ne sait pas, ben on travaille avec le nouveau produit et on vérifie les errata. Si un errata nous concerne, alors on en tient compte si nécessaire dans le logiciel, ou alors on commande un nouveau composant dès que celui-ci sort.

Par contre, si une société ne produit pas d'errata "sérieux", alors c'est simplement qu'elle cache les bugs, parce que développer des nouveaux micros à la cadence actuelle et de la puissance actuelle sans créer de bugs, je dis, moi, que c'est tout simplement impossible.

Désolé d'avoir été long, mais bon, une seule intervention en plusieurs mois, ça compense.

Si on ne m'envoie plus de mail sur ce sujet, je n'y reviens plus

A+
Bigonoff
__________________
Vive l'internet libre
Franck-026
Franck-026 23/02/2011, 13h42 #12  
Bonjour Mr Bigonoff enchanté de vous croiser...
ftorama
ftorama ★★★★★★ 23/02/2011, 15h08 #13  
Salut Bigonoff,

je ne vais pas répondre à tous les poncifs que tu viens généreusement d'étaler ici (re-bienvenue à toi tout de même, je préfère des débats argumentés que de basses attaques) mais je tiens tout de même à réagir sur les soit-disants avantages du PIC

- La diversité des documents et des sources disponibles sur le net



Parce que tu as l'habitude de leurs docs. Perso je les trouve mal foutues. Il est vrai que j'ai l'habitude des datasheets Atmel mais si on regarde le User Manual d'un ARM7 chez LPC par exemple, on ne peut qu'être bluffé par la qualité.

Ajoutons les docs incomplètes depuis des années sur Microchip (exemple récent sur un PIC18 dont il manque les courbes caractéristiques) ne sont pas non plus pour plaider en leur faveur.

- La qualité des documentations



Je reprendrai l'exemple des User Manual chez NXP, mais aussi certaines appnotes d'Atmel qui sont des modèles du genre. Voir par exemple celle sur l'implémentation d'un PID sur AVR:
http://www.atmel.com/dyn/resources/...nts/doc2558.pdf

Les autres appnotes sur l'utilisation de tel ou tel périphérique sont tout aussi bien faites, mais c'est surement une question d'habitude.

- La pertinence des errata et la transparence à ce niveau



Mouais....c'est sur que si des infos ne sont pas données, elles risquent moins d'être fausses.

- Les outils de développement gratuits et maintenant disponibles pour Linux



La belle affaire...Il faut quand même relativiser. 99% de la concurrence est déjà compatible Gcc depuis des temps immémoriaux et on peut développer sous Linux depuis des années. Côté programmation même du composant, citons LPC21ISP pour ARM NXP, AvrDude pour AVR....bref rien de neuf

- Le maintient en service des anciens modèles



Quand les différents modèles d'une même famille sont compatibles, l'intérêt est moindre, voire nul. Et combien d'entreprises font encore des développements qui durent 20 ans? Sans compter les sources asiatiques d'approvisionnement.
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits

Dernière modification par ftorama 23/02/2011 à 16h19.
maî
maî ★★★★★☆☆ 23/02/2011, 15h43 #14  
Bonjour

florama tu connais bien les PIC plus je te lis , plus j'ai des doutes( la dernière en date sur flash et EEPROM) .

Sommes-nous associaux parce que nous n'utilisons pas les PIC?



Et toi tu nous fais passer pour des hommes d'un autre temps, et pas que sur ABC.
si on utilise ASM ou les PIC. Cela fait plus de 30 ans que l'on dit que l'ASM c'est fini mais je vois que c'est toujours d'actualité

Bonne journée

Dernière modification par maî 23/02/2011 à 17h13. Motif: ousp rate un mot mille excuses
Tryph
Tryph ★★★☆☆☆☆ 23/02/2011, 15h55 #15  
Salut,

Posté par ftorama

Sommes-nous associaux parce que nous n'utilisons pas les PIC?



je pense que Bigonoff a voulu dire que microchip est à l'écoute des utilisateurs
ftorama
ftorama ★★★★★★ 23/02/2011, 16h19 #16  
Posté par Tryph

Salut,



je pense que Bigonoff a voulu dire que microchip est à l'écoute des utilisateurs



J'avais mal compris effectivement, c'est supprimé
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits
David
David ★★★★★☆☆ 23/02/2011, 16h21 #17  
Posté par ftorama

Ajoutons les docs incomplètes depuis des années sur Microchip (exemple récent sur un PIC18 dont il manque les courbes caractéristiques) ne sont pas non plus pour plaider en leur faveur.



Mouais...

Donne nous l'exemple concret dans ce cas...

C'est bien pire chez Atmel ou à ce jour, il manque toujours les perfs garanties à Fmax (n'importe quel Atiny)...

Comme quoi, cela ne plaide pas en leur faveur non plus!
ftorama
ftorama ★★★★★★ 23/02/2011, 16h24 #18  
Posté par maî

Bonjour

florama tu connais bien les PIC plus je te lis , plus j'ai des doutes( la dernière en date sur flash et EEPROM) .



Je n'ai pas vocation à avoir la science infuse, et je sais reconnaître quand je me plante. Maintenant, utiliser la Flash pour stocker un datalog, c'est quand même assez sale comme méthode, que ce soit sur PIC ou sur un autre micro.

Ce qui me gonfle royalement, c'est la pensée unique, principalement colportée par RISC qui veut qu'il n'y ait que le PIC et Microchip comme solution, quelquesoit le problème. Je suis désolé, mais on l'a vu récemment proposer un DsPIC pour un simple PID, là ou un bête 8 bits aurait fait l'affaire. Le mec voulait certainement piloter une led ou un moteur et il se retrouve avec un discours commercial de 10 lignes sur le calcul du PID en 750ns.

Si RISC veut faire de la pub, qu'il la fasse, mais qu'il précise que c'en est.

Et toi tu nous fais passer pour des hommes d'un autre temps, et pas que sur ABC.
si on utilise ASM ou les PIC. Cela plus de 30 ans que l'on dit que l'ASM c'est fini mais je vois toujours d'actualité



Sur cette remarque, j'ai mal compris la remarque de Bigonoff, et j'ai édité mon message ;-)
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits

Dernière modification par ftorama 23/02/2011 à 16h33.
ftorama
ftorama ★★★★★★ 23/02/2011, 16h32 #19  
Posté par David

Mouais...

Donne nous l'exemple concret dans ce cas...



doc du 18F2550, lien pris sur le site de Microchip sur la page produit:
http://ww1.microchip.com/downloads/...eDoc/39632e.pdf


C'est bien pire chez Atmel ou à ce jour, il manque toujours les perfs garanties à Fmax (n'importe quel Atiny)...

Comme quoi, cela ne plaide pas en leur faveur non plus!



Je viens de vérifier sur un Attiny48, les specs à 12MHz sont données. Donne nous un exemple concret
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits
David
David ★★★★★☆☆ 23/02/2011, 17h34 #20  
Oui, et qu'est ce qui te manque dans le datasheet du 2550???

Ah bon, sur l'atiny la spécification s'arrête à 8MHz, le reste de la pub...

Lien : http://www.atmel.com/dyn/resources/...nts/doc8008.pdf

Page 207, l'ICC s'arrête à 8MHz pour un composant qui est capable de tourner à 12MHz
Macsofy
Macsofy ★★★★★☆☆ 23/02/2011, 18h28 #21  
Moi j'ai pas le BTS,mais la programmation des microcontroleurs,on peut appendre seul,j'ai appris tout seul,moi j'utilise les PIC,et le develloppement j'ai ecrit en langage BASIC,et je fait aussi un peu d'assembleur,j'ai aussi programmer dans les années 90,le 68HC11F1.
surtout qu'aujourd'hui,il y a des excelent ouvrages sur la programmation comme Pascal Mayeux,Alain Reboux,Gerard Samblancat etc, et sans oublier sur le net avec notre cher Claude Bigonoff voir son excelent site sur la programmation des PIC.
@+
__________________
Nadine Me Regarda Oui Je Veux Bien Votre Grosse B... (Aide Mémoire Code de couleur) Bon Baignade.
ftorama
ftorama ★★★★★★ 23/02/2011, 18h39 #22  
Posté par David

Oui, et qu'est ce qui te manque dans le datasheet du 2550???



Le paragraphe sur les courbes ne te choque pas?

Le Voh pour un courant supérieur à 8,5mA, non plus?

Ah bon, sur l'atiny la spécification s'arrête à 8MHz, le reste de la pub...

Lien : http://www.atmel.com/dyn/resources/...nts/doc8008.pdf

Page 207, l'ICC s'arrête à 8MHz pour un composant qui est capable de tourner à 12MHz



Je n'ai jamais dit que seul Microchip était imparfait, mais qu'on arrête de faire croire qu'ils sont irréprochables.
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits

Dernière modification par ftorama 23/02/2011 à 18h56.
peufeu
peufeu ★★★★★☆☆ 23/02/2011, 18h59 #23  
Tiens, j'étais sûr que ça partirait en troll PIC-AVR :D

Posté par Bigonoff

Quand on en arrive à devoir désassembler du code produit par son compilateur, je me dis qu'il y a un problème quelque part. Parce que je préfère écrire en langage d'assemblage que de me farcir le code en C, de le désassembler, de le modifier, puis de le réassembler : pour moi, ça, ce n'est pas une méthode de travail efficace (mais ce n'est que mon avis).



Oui, en l'occurence il y avait un problème : avr-gcc introduisait un bug dans la comparaison des "signed char" (autrement dit une valeur 8 bits était traitée comme non signée même si déclarée comme signée). Le genre de truc qui surprend, quand même. Tu lances, ça marche pas : dans un programme de 4 lignes c'est louche.

Vu que c'était mon premier programme pour AVR, inutile de dire que je ne connaissais rien à l'assembleur de cette famille (et aucune envie d'y toucher sauf obligation).

Il y a une différence entre

- apprendre assez d'assembleur sur une architecture pour pouvoir vaguement comprendre un source et trouver le problème (ce qui a pris 5 minutes dans le cas ci-dessus)
- et apprendre réellement l'asm d'une architecture pour pouvoir écrire un programme avec.

Etant donné qu'apprendre un nouvel asm est long, pour un amateur, il est beaucoup plus rentable au niveau du temps de développement de tout faire en C, et de mettre un uC plus puissant et légèrement plus cher.

Sauf si on veut générer des timings ultra précis, bien sûr.

Posté par Bigonoff

C'est un langage CISC, il a les avantages du CISC à la relecture.
Mais sinon, tu connais tous les autres pour dire que c'est le seul lisible?



Je dirais, dans les asm "lisibles" :
- Le C bien sûr (qui est un assembleur édulcoré et semi-portable)
- Le 68000, PPC, AVR (quoique mon expérience de l'as sur AVR se limite à quelques dizaines de minutes)...

La palme de l'obfuscation revient au Microblaze qui classe les bits à l'envers...
Mais les x86 et divers PIC sont pas mal non plus au niveau difficulté de lecture...

Posté par Bigonoff

La méthode copier/coller, ce n'est pas "utiliser".



R.A.B.

10 minutes avec le jeu d'instruction de la machine sous les yeux, dans une routine de multiplication il suffit de regarder où vont les carry etc, c'est pas bien compliqué.

Ceci dit, c'était surtout pour la culture : le code provenait d'une appnote atmel en asm, et mis dans des fonctions C par un gentil internaute. Mais je voulais m'assurer que le passage de paramètres était bon.

Par contre, pour l'écrire, ça m'aurait pris un moment (nécessité d'apprendre l'asm en question en profondeur, etc).

Le calcul est vite fait. De plus, ça fonctionne très bien.

Posté par Bigonoff

J'ai même un message type sur la première page de mon site concernant cette méthode. Ca m'a valu pas mal de courrier, genre "j'ai récupéré la routine machine et la routine chose et je n'arrive pas à tout mettre ensemble".



Ah bah oui là si tu tombes sur des boulets XDDDD

Posté par Bigonoff

Ben oui.... si on programme en C, LOL.
Celui qui programme en basic n'a pas besoin du support du compilateur C, LOL
Et un support correct, ça veut dire, en passant, qu'on n'a pas à désassembler le code produit par le compilateur pour corriger "manuellement" les bugs.



Pas faux pour les bugs (petite déception du côté de gcc quand même !)

Par contre, là on s'adresse à quelqu'un qui veut attaquer les micros. Le BASIC rend fou, et l'asm, c'est un peu hardcore pour débuter quand même. Le C c'est pas mal.

Posté par Bigonoff

Moi, je suis comme tout le monde : je n'aime pas qu'il y aie un problème hardware.
Mais entre me voir fournir un errata qui reconnait le problème (et le corriger dans la série de fabrication suivante) et un constructeur qui dit "tout va bien" et ne propose pas d'errata (du moins, pas de "délicat"), je choisis sans hésitation possible la première solution.



En l'occurence, sur mon dernier projet perso, un dsPIC aurait été parfait, mais le silicon errata : lol, aucun contournement possible, ça n'aurait pas marché du tout.
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
idm
idm ★★★☆☆☆☆ 23/02/2011, 19h00 #24  
Avant d'arriver aux crocodile , il faut passer par les pyranas .
Bigonoff
Bigonoff ★★★★★☆☆ 23/02/2011, 19h07 #25  
Salut
-----

Bonjour Mr Bigonoff enchanté de vous croiser...



Et moi de même ;)

je ne vais pas répondre à tous les poncifs que tu viens généreusement d'étaler ici (re-bienvenue à toi tout de même, je préfère des débats argumentés que de basses attaques)



Heuu, excuse-moi mais je ne vois pas dans mes arguments de basses attaques (excepté quelques allusions à un internaute particulier, qui n'est pas toi, mais c'est parce que ses propos anti-utilisateurs PIC sont lassants).

Pour résumer, je ne fais que dire en substance :

- Il n'y a pas de mauvais contrôleurs pas plus que de "meilleur" dans l'absolu, sans quoi le marché se serait chargé de ne garder que les "meilleurs" et d'éliminer les mauvais

- Que les PIC ne sont pas plus "moyennageux" que les autres contrôleurs, je vois mal en quoi un PIC32 bits ou un DSPIC33F sont des contrôleurs "dépassés".

- Que les anciens PIC sont toujours en service, que c'est une bonne chose, et qu'ils sont toujours utilisés, et avec pertinence. Mon système domotique tourne avec des 18F, je n'ai aucun besoin de micro 16 bits pour ces applications, juste une bonne cadence de traitement et un bon module ECAN.

Et d'autres arguments parfaitement objectifs, face à des attaques qui ne le sont pas (Je cite : composants obsolètes, controleurs poussifs, assembleur à vômir, et autres joyeusetés).

Je dis, moi, que peu importe le contrôleur, ce sont ceux qui les utilisent qui font les applications. Or, je constate qu'en général ce sont les plus virulents... qui proposent le moins d'applications concrètes (je ne te vise pas, je constate des faits précédents).
Si on veut faire monter son micro sur le podium des choix des internautes, c'est simple : il faut proposer des documentations et des applications publiques : le reste, l'internaute s'en tamponne royalement, et il a bien raison.

Parce que tu as l'habitude de leurs docs.



Avant de commencer avec les PIC, je n'avais pas l'habitude. J'ai lu un datasheet, et après l'avoir lu j'ai pu programmer mes premiers pic. Donc, je me dis qu'avec un minimum de connaissances de base ces datasheets contiennent toutes les informations utiles.

mais si on regarde le User Manual d'un ARM7 chez LPC par exemple, on ne peut qu'être bluffé par la qualité.



On peut toujours mieux faire, c'est clair. Mais quand on voit le nombre de datasheets qui sortent chaque année chez Microchip, il faut quand même rester raisonnable.
Et puis, quand on lit un datasheet par exemple de PIC18Fxxx, et qu'on "oublie" de télécharger d'abord la documentation sur la famille high-end, alors logique qu'il manque des informations.

Ajoutons les docs incomplètes depuis des années sur Microchip



Désolé, je ne vois pas de quoi tu parles.
Il peut manquer un renseignement, tout arrive, mais si tu poses une question pertinente chez Microchip ils te répondent dans les 24 heures. Donc je doute que pour un développeur ce soit un problème. Je n'ai jamais été calé à cause d'une documentation Microchip, au pire en cas d'un doute (sur des cas très particuliers), je pose la question et on me répond.

Mouais....c'est sur que si des infos ne sont pas données, elles risquent moins d'être fausses.



C'est surtout que certains constructeurs ont tendance à ne jamais ou presque sortir d'errata. Non pas parce que leurs composants ne comportent pas de bugs, mais simplement parce que publier un errata demande plus de courage commercial que de nier un problème et de ne pas en parler.

C'est simplement ce que je disais : vu que l'absence de bugs ne peut pas exister, la présence d'errata est plus rassurante qu'inquiétante. Ceci dit, j'aime autant avoir le moins de bugs possibles, c'est vrai, mais un bug inconnu est encore plus vicieux qu'un répertorié (et corrigé par la suite). Mon souhait à moi, c'est donc : Le moins de bugs possibles, SVP, mais s'il y en a, surtout, surtout, surtout, dites-le.

La belle affaire...Il faut quand même relativiser. 99% de la concurrence est déjà compatible Gcc



Mais moi je ne parle pas de la compatibilité Gcc, je dis que maintenant MPLAB "officiel" (tout l'IDE de développement) est maintenant compatible Linux : on travaille avec les mêmes softs quelle que soit la plateforme, et les hardwares propriétaires sont supportés.

Maintenant, que d'autres le fassent, c'est certain qu'il y en a, mais vu que c'était encore il y a peu un argument "anti-pic", j'ai cru bon de le signaler.

Les autres appnotes sur l'utilisation de tel ou tel périphérique sont tout aussi bien faites, mais c'est surement une question d'habitude.



Il y a des milliers d'appnotes chez Microchip, les utilisateurs ne semblent pas avoir trop de difficulté à les mettre en pratique. De nouveau on peut préférer un style ou un autre style, mais l'information s'y trouve. Et cette information est quand même sensée être fournie à des gens ayant un minimum de connaissances de base.

Quand les différents modèles d'une même famille sont compatibles, l'intérêt est moindre, voire nul. Et combien d'entreprises font encore des développements qui durent 20 ans? Sans compter les sources asiatiques d'approvisionnement.



Tu as une vision très limitée de l'intérêt de conserver un produit.
Petit exemple simple et pratique de cet intérêt "nul" (comme tu dis) :

Sur mon site, rubrique "domotique", j'ai réalisé une carte sensitive. Pour des raisons de facilité, cette application comporte 2 microcontroleurs :

- 1 PIC
- 1 micro spécialisé dans les transferts de charge de la gamme Quantum : un QTxxx

AVANT de réaliser l'application, il y a +- 5 ans, j'ai écrit chez Quantum pour demander ce qu'il en serait de la pérénité du QT.
On m'a répondu : aucun problème, lorsqu'on arrêtera la fabrication, on garantira encore l'approvisionnement de ce composant durant 10 ans minimum.

Quantum a stoppé ce QT, et, 5 ans après, force est de constater que les utilisateurs ne peuvent plus s'en procurer (si, par 5000 pièces, mais si ça intéresse quelqu'un qu'il le dise).

Moralité : ma carte est obsolète à cause du composant.
Bilan : je suis obligé de recréer une toute nouvelle carte (avec de nouveaux composants car les nouveaux QT ne sont pas compatibles ni niveau harwdare, ni niveau software).
Or, je n'ai pas le temps.

Donc : plus de carte sensitive pour les utilisateurs de mon système domotique, sauf à attendre que j'aie le temps, ou à développer leur propre carte (ce qui n'est pas à la portée de tout utilisateur de domotique).

SI j'avais utilisé un pic pour piloter les touches sensitives (maintenant, Microchip en fabrique), et bien aujourd'hui ma carte serait toujours fonctionnelle, les utilisateurs pourraient toujours la construire (obsolète ou non), et le jour où j'ai une panne je ne serais pas obligé de me farcir des dizaines d'heures de travail pour remplacer un composant sensé être de stock durant 10 ans.

C'est ça, l'intérêt.

Après, que cet intérêt soit nul pour toi, c'est possible, mais ce forum est consacré non pas aux industriels chinois, mais aux développeurs particuliers (en majorité) : alors va leur expliquer que chaque fois qu'ils trouveront sur le net une carte avec un contrôleur machin-truc ils ne pourront rien en faire à cause que ce composant n'existe plus. Chez Microchip, ça n'arrive JAMAIS : tu peux chercher n'importe quelle carte à pic sur le net, et tu peux toujours te procurer le pic en question.

Pour moi c'est loin d'être d'un intérêt nul. Et, si Microchip n'avait pas cette politique, mon cours-part1 serait obsolète à cause de la disparition du 16F84. Du coup, je n'aurais pas recommencé, les utilisateurs ne liraient plus mes cours, et donc n'auraient pas un argument en faveur des PIC pour commencer leur apprentissage.
Comme quoi, le maintien des produits ça joue largement sur la part de marché de Microchip, et ils l'ont parfaitement compris.
Qui va s'amuser à passer 1 an à écrire gratuitement un cours sur un composant qui n'existera plus dans 5 ans?
Personne, je le crains.
Et si personne n'écrit, alors l'amateur débutant se retrouve gros Jean comme devant...

Et, niveau "compatible", ben ça l'est rarement avec les nouvelles versions de contrôleurs: la preuve ici avec quantum, et je fais impasse sur bien d'autres contrôleurs qui ne sont pas remplaçables "tel quel" sans un minimum d'adaptation.

Pire, lorsqu'on construit un nouveau composant, devoir se traîner la compatibilité avec le modèle précédent est un frein à l'évolution : moi je préfère de loin un composant intégralement neuf avec l'ancien toujours disponible : aucun problème de compatibilité à envisager.

je pense que Bigonoff a voulu dire que microchip est à l'écoute des utilisateurs



Effectivement. Je ne pensais pas qu'on pouvait comprendre ma phrase autrement.
Ceci dit, tout le monde peut se tromper, il n'y a pas de mal ;)

Maintenant, utiliser la Flash pour stocker un datalog, c'est quand même assez sale comme méthode, que ce soit sur PIC ou sur un autre micro.



Je suis bien d'accord que la flash d'un PIC n'est pas le meilleur endroit pour stocker des données à répétition. Mais personne n'oblige personne à faire ça, LOL
Il y a une eeprom interne, si ce n'est pas suffisant on ajoute une externe et le tour est joué. Ou on utilise un contrôleur spécifiquement adapté avec grosse mémoire eeprom, mais alors on aura autant de marques utilisées que de types d'applications (c'est un choix).
__________________
Vive l'internet libre
David
David ★★★★★☆☆ 23/02/2011, 19h07 #26  
Posté par ftorama

Absolute Maximum ratings étant à 25



Oui, c'est bien, cela te dis juste que tu ne peux pas dépasser 25mA, cela ne parle pas du Voh...

Le seul VoH garantis est à max 3mA, donc si tu veux du garantis, tu t'arrêtes à 3mA.

Je te conseil d'examiner aussi bien le datasheet de ton Atiny, tu verras que le Voh à 40mA n'est pas non plus mentionné!(voir page 204 du lien que j'ai déjà donné)


Posté par ftorama

Avant de dire que les courbes sont de la pub, tu les as vérifiées?



Ben non, c'est Atmel qui le dit explicitement, donc, pas besoin de vérifier...

J'arrête là, tu as toujours besoin d'avoir le dernier mot, et je te le laisse avec plaisir!
Bigonoff
Bigonoff ★★★★★☆☆ 23/02/2011, 19h08 #27  
Part 2
------

Ce qui me gonfle royalement, c'est la pensée unique, principalement colportée par RISC qui veut qu'il n'y ait que le PIC et Microchip comme solution



Personne n'a jamais dit ça.
Ce qu'il y a, c'est que beaucoup d'amateurs trouvent leur compte dans les PIC, déjà pour la bonne raison qu'on trouve beaucoup d'informations sur le net à leur sujet.

Ce qui est dérangeant, par contre, c'est qu'à chaque fois qu'on parle de ce sujet, plutôt que d'expliquer qu'il faut choisir en fonction de ses critères, on retrouve systématiquement les mêmes dénigrements :

1 : des PIC (composants lents, obsolètes, moyennageux, pour amateurs etc)
2 : du langage d'assemblage (pour les primitifs, ceux qui n'ont rien compris, c'est pénible, archaïque etc)

Je pense qu'il y a la place pour les PIC et pour les autres marques, de même qu'il y a la place pour tous les langages.

Je ne programme pas un logiciel de facturation en langage d'assemblage, le C# est mieux.

Mon site internet tourne en HTML et en PHP, pas en C#

Un serveur Web sur un mini-linux pourra être développé en Java plutôt qu'en PHP

Un logiciel au timing critique sur micro 8 bits tirera avantageusement parti du langage d'assemblage plutôt qu'en PHP

Pour un logiciel non critique mais complexe sur un micro aux ressources suffisantes, le C pourra apporter bien des avantages.

etc.

Et je ne parle pas de ruby, Python, Basic, qui ont chacun leur créneau.

Moi, je dois utiliser une série de langages, et jamais au grand jamais il ne me vient à l'idée de prétendre lequel est le meilleur. Ils sont différents et adaptés à des réalités différentes, alors arrêtons de donner dans l'élitisme primaire, surtout lorsque ceux qui se prétendent donneurs de leçons sont en fait des gens qui ne développent souvent rien de concret (et, de nouveau, et avec sincérité, je ne te vise pas).

Moi, j'en ai un peu marre de devoir répondre à des émails de gens qui me disent : je voulais apprendre les PIC en langage d'assemblage, mais sur le forum de www.abcelectronique.com, on m'a dit que c'était ringard.

A chaque fois je dois recommencer mes explications, alors je préfère profiter de ce post pour répondre à tout le monde en même temps sur ce sujet :

1) Il n'y a PAS de meilleur microcontroleur
2) Il n'y a PAS de meilleur langage.

Je suis désolé, mais on l'a vu récemment proposer un DsPIC pour un simple PID, là ou un bête 8 bits aurait fait l'affaire. Le mec voulait certainement piloter une led ou un moteur et il se retrouve avec un discours commercial de 10 lignes sur le calcul du PID en 750ns.



C'est clair que conseiller une bonne solution à quelqu'un (pas la meilleure, juste une solution adaptée), ça commence par prendre en compte le cahier des charges de l'utilisateur (encore faut-il qu'il en aie écrit un).

Or le fait de dire "il voulait certainement" implique qu'il n'a pas donné le cahier des charges.

Alors autant on ne peut pas conseiller un DSPIC, autant on ne peut pas dire qu'un micro 8 bits aurait suffit : en fait, on l'ignore, personne n'a raison ni tort.

Proposer un DS-PIC n'est peut-être pas une solution adaptée dans un cas précis, mais dire à quelqu'un "ne développe pas sur PIC, c'est pour le grand public et c'est ringard", ce n'est pas mieux.

Si RISC veut faire de la pub, qu'il la fasse, mais qu'il précise que c'en est.



Heuu, tu sais, j'ai beau relire aucun RISC n'a posté dans ce fil.
Sinon, je doute qu'il fasse de la pub, il est probablement simplement passionné par ce qu'il fait et il cherche à partager sa passion.
Par contre, je doute qu'il aie dénigré Atmel ou Freescale.

Par contre, les utilisateurs de pic ont directement été agressés ainsi que les utilisateurs du langage d'assemblage. Si je suis tous les propos, je suis une espèce de primitif moyennageux, ça ne fait pas particulièrement plaisir. Si c'était une seule fois, ce ne serait pas grave, mais ces propos reviennent à répétition.

doc du 18F2550, lien pris sur le site de Microchip sur la page produit:



Oui, au chapitre 29 il est indiqué que ce n'est pas encore présent.
MAIS tu as lu le chapitre 28? Il te manque quoi comme informations électriques, concrètement, pour réaliser un montage?

Sinon, il peut y avoir une erreur ou un oubli dans une doc : suffit d'écrire chez Microchip et si c'est pertinent ils vont corriger ou compléter : tu leur as demandé?
Si Windows et Linux n'avaient pas de retour d'erreurs venant des utilisateurs, ces OS seraient aujourd'hui tout simplement inutilisables : il faut jouer le jeu.

Ca ne sert à rien de "chercher l'erreur" dans des composants ou dans des docs, il y en a pour toutes les marques, c'est sûr et certain.

Mieux vaut expliquer ce qu'on a aimé dans un produit, partager ses applications (ça,c'est du concret utile), et donner ses coups de coeur, sans pour cela systématiquement dénigrer les choix d'autrui.

Pour ma part, je suis en train de concevoir un nouveau domocan centralisé.
La centrale tournera probablement avec un ARM, le logiciel de la centrale sera écrit en C, le serveur web en Java. Le logiciel propriétaire (dans un premier temps) tournera sous Linux et Windows et sera écrit en C#. Les plugins utilisateurs pourront être écrits dans n'importe quel langage dotnet (C#, C++.net, Java.net, basic.net, Python.net, etc). Les premières cartes proposées seront des cartes à PIC18F avec logiciels en langage d'assemblage, mais tout est prévu dès le départ pour qu'avec un simple plugin on puisse placer des cartes avec n'importe quel microcontroleur (Atmel, freescale etc) avec maintien de toutes les fonctionnalités, même le bootloader.

Comme quoi il y a moyen de rester ouvert.

A+
Bigonoff
__________________
Vive l'internet libre
ftorama
ftorama ★★★★★★ 23/02/2011, 19h12 #28  
C'est bien ce que je disais, je préfère discuter avec Bigonoff, que je ne visais pas en parlant de basses attaques....1 partout pour la mauvaise compréhension
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits
Bigonoff
Bigonoff ★★★★★☆☆ 23/02/2011, 19h25 #29  
Aie, autre message:

Etant donné qu'apprendre un nouvel asm est long, pour un amateur, il est beaucoup plus rentable au niveau du temps de développement de tout faire en C, et de mettre un uC plus puissant et légèrement plus cher.



C'est un argument subjectif qui dépend de chaque utilisateur.
D'autant plus que tous les compilateurs ne sont pas gratuits.
Sans compter qu'étudier le langage d'assemblage est beaucoup plus rapide et court que d'étudier le C (spécifique) sur micro.
Sauf si on confond étude du langage (10 pages dans le datasheet) avec étude des fonctionnalités (qui, si on fait l'impasse, ne permet jamais de comprendre comment fonctionne réellement les modules qu'on utilise, avec tous les risques que cela comporte).

Sauf si on veut générer des timings ultra précis, bien sûr.



Ben oui : sauf si.
Et justement, ce "sauf si" dépend de l'application et ruine ta précédente argumentation.
En commençant par le langage d'assemblage, on est à l'abri du "sauf si", mais, de nouveau, c'est un choix.

Je dirais, dans les asm "lisibles" :
- Le C bien sûr (qui est un assembleur édulcoré et semi-portable)
- Le 68000, PPC, AVR (quoique mon expérience de l'as sur AVR se limite à quelques dizaines de minutes)...



Et moi je dirais que la lisibilité d'un code source dépend du programmeur et non du langage utilisé. J'ai vu des choses innommables en C et parfaitement illisibles : le C est loin d'être un langage "clair" par défaut, il y a même des concours de l'instruction la plus illisible.

La seule chose, c'est si on désassemble, le code d'un CISC est plus simple à recommenter qu'un RISC, tout simplement parce qu'il y a moins d'instructions et donc c'est moins décomposé.
Mais, inversément, si on est réduit à devoir désassembler, c'est qu'il y a un problème quelque part.

10 minutes avec le jeu d'instruction de la machine sous les yeux, dans une routine de multiplication il suffit de regarder où vont les carry etc, c'est pas bien compliqué.



C'est ta méthode, c'est toi qui voit.
Moi, je vois où ça mène les copier/coller de routines qu'on ne comprends pas: nulle part.

Ceci dit, c'était surtout pour la culture : le code provenait d'une appnote atmel en asm, et mis dans des fonctions C par un gentil internaute.



Moi je m'interroge surtout sur l'opportunité de devoir intégrer une multiplication en langage d'assemblage dans un programme écrit en C. C'est le boulot du compilateur de réaliser la multiplication, ou alors on a du soucis à ce faire concernant le compilateur en question. Ca ne me viendrait jamais à l'idée d'utiliser un compilateur qui ne sait pas coder une multiplication, LOL.

Par contre, pour l'écrire, ça m'aurait pris un moment (nécessité d'apprendre l'asm en question en profondeur, etc).



Ben, pour un utilisateur de C, j'aurais dit : A = B * C
Non ?
Ca me semblait justement l'intérêt principal du C, les routines mathématiques. Si maintenant on doit les écrire en "assembleur", où va le monde? LOL.

Par contre, là on s'adresse à quelqu'un qui veut attaquer les micros. Le BASIC rend fou, et l'asm, c'est un peu hardcore pour débuter quand même. Le C c'est pas mal.



C'est ça que je n'aime pas comme argumentation :

Le basic, c'est débile (trop évolué? Trop simple?)
Le langage d'assembleur aussi (trop primitif?)

Ne reste QUE le C : LE vrai choix.

Ca me semble beaucoup trop caricatural.

Sinon, le langage d'assemblage, c'est "hardcore" pour débuter? Tu sais combien d'utilisateurs ont démarré les PIC avec mes petits cours en "assembleur"?
Et ça va jusque des utilisateurs de plus de 70 ans qui n'ont jamais touché un micro.

En l'occurence, sur mon dernier projet perso, un dsPIC aurait été parfait, mais le silicon errata : lol, aucun contournement possible, ça n'aurait pas marché du tout.



Alors tu es tombé sur la seule application où tous les Dspic rencontrent un problème insurmontable. Franchement, tu n'as pas de bol. Moi, je suis toujours arrivé à m'en sortir, mais bon j'ai plus de chance.

A+
Bigonoff
__________________
Vive l'internet libre
aurelienr
aurelienr ★★★★★★ 23/02/2011, 19h27 #30  
Posté par Bigonoff

Heuu, tu sais, j'ai beau relire aucun RISC n'a posté dans ce fil.
Par contre, je doute qu'il aie dénigré Atmel ou Freescale.


+1
Les anti pic auront beau dire ce qu'ils veulent, RISC ne fait qu'exposer une solution qui vaut ce qu'elle vaut. Jamais il ne va tourner en dérision quoique ce soit, jamais il ne va mépriser les choix des autres.

Alors que les discours à la thm ne cessent de rabaisser ceux qui osent utiliser les PIC.
Un 12F poussif et depassé ? Je viens de faire le choix d'en intégrer sur mes cartes !
- 3h pour le code assembleur
- le sentiment d'avoir une solution qui convienne parfaitement à l'appli, si petite et peu demandeuse en performance soit-elle
- possibilité d'acheter des pièces préprogrammées pour un prix dérisoire chez microchip ! Et oui en prod c'est un gros avantage sur une carte à quelques euros...

Etant utilisateur PIC(12F/16F/18F/24F) et AVR (mega et Xmega) à 50/50 selon mes applis, chaque famille a ses défauts et avantages, mais jamais je ne trancherai en disant que l'un est bien mieux que l'autre.
Chaque a ses tares.
Quand bigonoff dit que les PIC restent toujours en vente, c'est un gros avantage. Chez ATMEL, le nombre de pross qui ont disparu, ou qui ont brievement apparu, qui sont restés en "preliminary" toute leur vie, ou qui ont été sur le site alors que chez ATMEL on savait qu'ils allaient etre abandonné (j'en sais quelque chose...) sans forcement avoir d'avis public d'obscolescence (je parle des C51SNDx, et des pross 32 bits série AP7), ce sont des pratiques pas tres cool...
Quant aux errata AVR, c'est de la gnognotte par rapport à ceux des PIC. Mais j'observe en général plus de bug sur les PIC (forcement, ils doivent en produire plus et plus vite), exception faite des Xmega, qui sont une reference en terme de bugs et modules HS par rapport à ce qui est annoncé :)

En tout cas ravi de relire l'argumentation de bigo, ça change un peu, et j'aimerais avoir le temps et la patience de faire de meme...

Aurélien
peufeu
peufeu ★★★★★☆☆ 23/02/2011, 20h19 #31  
> C'est un argument subjectif qui dépend de chaque utilisateur.

Pas faux. A l'époque, je trouvais l'assembleur amusant (faut dire que sur les machines en question, les compilateurs C étaient des embryons de mollusques) mais maintenant je préfère quelque chose de plus ... productif ! (Raison pour laquelle j'aime beaucoup le Python sur PC)...

> D'autant plus que tous les compilateurs ne sont pas gratuits.

Certes, mais pour des projets perso, on peut difficilement justifier un achat souvent onéreux.

> Sans compter qu'étudier le langage d'assemblage est beaucoup plus rapide et court
> que d'étudier le C (spécifique) sur micro.

Mais l'asm n'est pas recyclable, le C s'applique partout.

> Sauf si on confond étude du langage (10 pages dans le datasheet) avec étude des
> fonctionnalités (qui, si on fait l'impasse, ne permet jamais de comprendre comment
> fonctionne réellement les modules qu'on utilise, avec tous les risques que cela comporte).

C'est en grande partie sur les périphériques qu'on choisit le uC (sauf si on n'a pas de besoins particuliers)... donc faire l'impasse dessus, hum...

> En commençant par le langage d'assemblage, on est à l'abri du "sauf si", mais, de
> nouveau, c'est un choix.

Je m'y mettrai quand j'en aurai besoin...

> Moi, je vois où ça mène les copier/coller de routines qu'on ne comprends pas: nulle part.

J'ai pas dit qu'il ne fallait pas comprendre le code en question. Au minimum, il faut comprendre l'API (si elle existe) ou sinon, lire et comprendre le code.

Inutile par contre d'être capable de l'écrire.

Sinon, il n'y aurait pas de libraries, et on serait bien avancé.

> Moi je m'interroge surtout sur l'opportunité de devoir intégrer une multiplication en langage
> d'assemblage dans un programme écrit en C.

N'est-ce pas !

C'est une grosse faiblesse du C et aussi des compilateurs, qui fait que quand tu as un petit 8 bits (avec instruction MUL) et que tu veux faire de la virgule fixe, mettons :

S16 a = un_capteur_analogique_quelconque();
U8 coeff = lis_ta_table_de_coeff( ... );

S16 b = (a*coeff) >> 8;

Eh ben, cet idiot de AVR-GCC instancie une multiplication 32x32 donc, ça rame atrocement. Alors qu'on peut virer une bonne partie des MUL.

D'autre part, le C n'a pas de type entier 24 bits, or quand tu multiplies 2 nombres de 10-12 bits comme on trouve dans les ADC standard, tu obtiens 24 bits, pas 32, etc...

Evidemment sur un uC 32 bits qui fait ça en 1 cycle, osef...

Certes, le compilateur (avr-gcc) n'est pas à la hauteur.

Mais, est-ce que je mets 150€ dans CodeVision AVR ou je passe 15 minutes à choper une routine de multiplication adaptée ?...

> Le basic, c'est débile (trop évolué? Trop simple?)

C'est tout simplement débile.

> Le langage d'assembleur aussi (trop primitif?)

Pas assez productif à mon goût, mais indispensable dans certaines situations, donc un outil utile mais relativement lourd à utiliser.

> Ne reste QUE le C : LE vrai choix.

C'est un langage qui a beaucoup de défauts, mais il reste tout de même fort pratique. A défaut de mieux.

> Sinon, le langage d'assemblage, c'est "hardcore" pour débuter?
> Tu sais combien d'utilisateurs ont démarré les PIC
> avec mes petits cours en "assembleur"?
> Et ça va jusque des utilisateurs de plus de 70 ans qui n'ont jamais touché un micro.

Ben... tant mieux pour eux !

Mais quand on voit des étudiants en arts qui prennent un arduino avec son C customisé à la Processing et qui font des trucs qui marchent...

> Alors tu es tombé sur la seule application où tous les Dspic rencontrent un problème
> insurmontable. Franchement, tu n'as pas de bol. Moi, je suis toujours arrivé à m'en sortir,
> mais bon j'ai plus de chance.

Peut-être que c'eut été possible que ça marche, au prix d'une énorme prise de boule inutile.
J'ai pris un chip plus vieux où d'autres ont essuyé les plâtres (AT90PWM3B) -- succès total.
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
Xavier35
Xavier35 ★★★★★☆☆ 23/02/2011, 20h28 #32  
Je vais tous vous mettre d'accord. Les meilleurs µC sont les 80c166 de siemens (infinéon) et leur descendants...

Y a t'il des utilisateurs dans la salle?
Neptune
Neptune ★★★★★☆☆ 23/02/2011, 21h07 #33  
Posté par Xavier35

#51 >> Les meilleurs µC sont les 80c166 de siemens (infinéon) et leur descendants...

Ah oui ?

Mais, par contre, la meilleure phrase de tous les posts, c'est la dernière en #12.

Elle, au moins, s'est vérifiée avec certitude dans ce fil :-)

Bon, je sors ...

@+
XF75
XF75 ★★★★★☆☆ 23/02/2011, 21h57 #34  
Le problème avec ces discussions sans fin c'est que

- chacun parle de son expérience mais pas des bases des architecture des machines: mathématiques, contraintes ....

- ce qui conditionne le choix est bien évidement les critères du projet:
hier le cout de l'intégration dans le silicium, aujourd'hui la portabilité, la validation, le commercial....

Le meilleur c'est toujours le dernier sorti pour les criteres du projet car il beneficie de l'experience des predecesseurs...

XF
maî
maî ★★★★★☆☆ 24/02/2011, 08h01 #35  
Bonjour

Encore une fois les détracteurs de ASM sont des gens qui ne pratiquent pas, ne veulent surtout pas y toucher,ne le connaissent pas,Très étroit comme vision.

Ici je pratique le C++ pour mes IDE avec QT4 et ASM sur mes PIC (Pas facile le C++ notamment la programmation objet).Mais je fais au moins l'effort de le faire,et ne critique surement pas tel type d'écriture,chaque chose et utile pour tel type de situation.

Allons messieurs un petit effort, pour apprendre ASM et la je serai à l'écoute de vos critiques sinon point crédible vous êtes à mes yeux.

Bonne journée.

Dernière modification par maî 24/02/2011 à 09h15.
Bigonoff
Bigonoff ★★★★★☆☆ 24/02/2011, 08h55 #36  
Salut
-----

En tout cas ravi de relire l'argumentation de bigo, ça change un peu, et j'aimerais avoir le temps et la patience de faire de meme...



Je te remercie beaucoup. Après cette discussion je retournerai dans mon petit monde, sinon les discussions prennent trop de temps et je finis par ne plus faire que ça, LOL.

Et puis, c'est à cause de ce genre de discussion que j'ai délaissé un peu ce forum, parce que les mêmes arguments reviennent toujours inlassablement.

Mais bon, une fois de temps en temps, il me semble important, pour les nouveaux de ce forum, de clarifier le fait qu'ils ne sont pas débiles parce qu'ils utilisent tel ou tel langage, ni parce qu'ils utilisent tel ou tel micro, et que ceux qui leur donnent un conseil sans connaître le contexte sont des gens qu'il vaut mieux ne pas trop écouter.

Pas faux. A l'époque, je trouvais l'assembleur amusant (faut dire que sur les machines en question, les compilateurs C étaient des embryons de mollusques) mais maintenant je préfère quelque chose de plus ... productif ! (Raison pour laquelle j'aime beaucoup le Python sur PC)...



Une nouvelle fois, c'est sous-entendre que le C est plus "productif". Or, de nouveau, ça dépend de l'application, du programmeur, de la cible.... et du compilateur.
Quand je vois qu'on doit debugger du code produit par un compilateur et insérer une routine de multiplication en langage d'assemblage dans un source C, je doute que ce soit vraiment une approche "productive".

Certes, mais pour des projets perso, on peut difficilement justifier un achat souvent onéreux.



Justement, c'est ce que je disais : en langage d'assemblage on a toujours une solution gratuite fournie par le constructeur. Pour les compilateurs C, c'est loin d'être toujours le cas.

Mais l'asm n'est pas recyclable, le C s'applique partout.



Le C standard ce n'est que la partie émergée de l'iceberg lorsqu'on programme un microcontroleur : toutes les librairies sont propriétaires.
Le C s'applique partout, mais un programme C d'un micro n'est pas "applicable" partout.

Pire, j'ai plein d'exemples de programmes écrits pour un PIC bien défini avec un compilateur X et dont le source n'est même pas compatible avec le compilateur Y POUR LE MEME PIC. Donc, le source n'est même pas "portable" d'un compilateur à l'autre sur la même cible. Au moins, avec le langage d'assemblage, ça n'existe pas.
Certes, les routines "génériques" sont réutilisables, mais franchement, dans un petit microcontroleur, les routines ne faisant aucun appel aux modules internes sont... rares?

Mais de nouveau, je ne critique pas le C, je montre juste que si on peut "trouver" des arguments favorisant un langage, on peut tout aussi aisément en trouver qui le mettent à mal. Tout ça, c'est dépendant de la cible, du compilateur, de l'application, du programmeur, etc. On ne peut pas opérer de jugement "généraliste", or c'est ce qu'on constate dans ce sujet, une fois de plus.

C'est en grande partie sur les périphériques qu'on choisit le uC (sauf si on n'a pas de besoins particuliers)... donc faire l'impasse dessus, hum...



Ben justement : ceux qui prétendent que le langage d'assembleur c'est compliqué à apprendre, c'est parce qu'ils assimilent automatiquement tout ce qui est dans le datasheet avec "assembleur". Du coup, ils passent au C en pensant s'épargner le datasheet (ou mes cours, LOL).
Mais le langage d'assemblage d'un PIC, ça s'apprend en moins d'une heure, tout le reste c'est l'étude des modules internes.

Et ça, qu'on travaille en langage d'assemblage ou en C, on n'y coupe pas (sauf, comme je le disais, à utiliser des fonctions pré-écrites utilisant le module sans comprendre comment le dit module fonctionne, ce qui génère des problèmes de compréhension du résultat obtenu).

Moyennant quoi, affirmer qu'étudier le langage d'assemblage est compliqué ou long, et que le C permet de gagner du temps, c'est archi-faux, car il y a plus de choses à étudier en utilisant le C (déjà toutes les librairies) qu'en utilisant le langage d'assemblage, SAUF, comme je l'ai dit, à faire impasse sur l'apprentissage du PIC en lui-même, et mon courrier me montre suffisamment où ça mène ce genre d'utilisateurs.

Je m'y mettrai quand j'en aurai besoin...



Alors le temps d'apprentissage que tu auras économisé sera nul, et si tu avais commencé par le langage d'assemblage tu aurais compris plus vite bien des points.
Le C peut faire gagner du temps à l'écriture de code (sur une cible convenable et pour une application compatible) mais nécessite un temps d'apprentissage supplémentaire et non plus court, comme on essaye de le faire croire. Du moins si on veut programmer correctement.

J'ai pas dit qu'il ne fallait pas comprendre le code en question. Au minimum, il faut comprendre l'API (si elle existe) ou sinon, lire et comprendre le code.



Aller expliquer à un utilisateur qu'il n'a pas besoin de connaître le langage d'assemblage pour écrire du code mais qu'il a besoin de le connaître pour comprendre le code écrit par quelqu'un d'autre, ça me semble curieux comme argument pour économiser l'apprentissage du langage d'assemblage.

Inutile par contre d'être capable de l'écrire.



35 instructions basiques (RISC) pour un PIC16F : je vois mal comment on peut connaître ces instructions suffisamment pour relire le code d'autrui sans être capable d'écrire soi-même un bout de code. C'est de ça dont on parle : le "gain" de temps en "sautant" l'apprentissage de 35 instructions élémentaires, par rapport aux centaines de pages du datasheet d'un 16F. Franchement, ça ne vaut même pas la peine d'en parler, surtout si suite à cette économie on se farcit l'étude du C et du compilateur utilisé (le manuel pour un DSPIC du compilateur Microchip fait 700 pages si ma mémoire est bonne).

Sinon, il n'y aurait pas de libraries, et on serait bien avancé.



Les librairies existent en C comme en langage d'assemblage.

N'est-ce pas !
C'est une grosse faiblesse du C et aussi des compilateurs, qui fait que quand tu as un petit 8 bits (avec instruction MUL) et que tu veux faire de la virgule fixe, mettons :
...
Certes, le compilateur (avr-gcc) n'est pas à la hauteur.



Ou la cible n'est pas adaptée à ce langage, LOL.
J'ai quand même furieusement l'impression que c'est ce que je dis depuis des années au sujet du C sur certains types de micro.

Sinon, à t'entendre, le C fait gagner du temps et de l'apprentissage, MAIS il faut que l'utilisateur sache que le code produit peut se retrouver inutilement lourd, et que dans ce cas il doit prendre l'initiative d'insérer des routines en langage d'assemblage (il fait quoi, il désassemble systématiquement le code produit?)
Excuse-moi de trouver la méthode peu "rentable", peu "intuitive", et plus difficile à comprendre pour un novice que de "bêtement" écrire son code en langage d'assemblage. Excuse-moi de penser que si la cible n'est pas adaptée au langage on produit manifestement du code tellement peu efficace que ça se ressent de façon visible sur la vitesse d'exécution du programme.

Dit autrement : il y a des cas où le langage d'assemblage est plus approprié que le C, et donc on en revient à mon affirmation selon laquelle il n'y a pas de meilleur langage, mais un plus ou moins bon choix en fonction du contexte.

Mais, est-ce que je mets 150€ dans CodeVision AVR ou je passe 15 minutes à choper une routine de multiplication adaptée ?...



Ou est-ce que tu utilises le C lorsque tu es certain que le code produit par ton compilateur est bien adapté aux ressources de la cible que tu utilises? Chacun sa façon de poser la question.

C'est tout simplement débile.



Donc, si le basic est débile, leurs utilisateurs sont débiles aussi.
Je trouve que ta vision des choses se résume à : tout qui ne fait pas les mêmes choix que moi est soit débile soit primitif.

Ca ne te viens pas à l'idée que d'autres arguments tout aussi objectifs que les tiens puissent exister? Que tous les utilisateurs n'ont pas le même parcours ni les mêmes connaissances? Que chacun a son propre cahier des charges?

Je ne me permettrai jamais de dire d'un langage qu'il est débile (du reste, j'ai utilisé par mal le basic, même si ce n'est pas sur microcontroleur).

Je dis simplement, par exemple, à un internaute qui désire utiliser C sur PIC : Si tu veux utiliser le C, prends un PIC qui soit adapté, soit :

- De préférence un PIC 16 ou 32 bits
- Dans les PIC 8 bits si tu ne peux pas faire autrement, un 18F (pas la cible parfaite, mais déjà mieux supporté)
- Si vraiment tu veux faire du 16F, prends un 16Fxxxx (4 chiffres), mais bon, ce n'est pas la panacée en terme d'efficacité mais au moins c'est supporté par le compilateur officiel de Microchip
__________________
Vive l'internet libre
Bigonoff
Bigonoff ★★★★★☆☆ 24/02/2011, 08h56 #37  
Part2
-----

Pas assez productif à mon goût,



Sauf dans de grosses boîtes où on travaille en équipe sur un même gros programme, la productivité dépend plus du programmeur que du langage, surtout sur ce genre de cibles.

En outre, on parle ici d'un sujet relatif aux amateurs démarrant sur micro (les autres ont déjà leurs langages et leurs micros), alors pour ce qui est de la productivité, je doute que ce soit la préoccupation première des intervenants.

Enfin, si on commence à devoir désassembler un code produit par un compilateur (souvent illisible) pour remplacer des instructions C par des routines en langage d'assemblage, j'y vois mal un élément en faveur de la productivité.

mais indispensable dans certaines situations, donc un outil utile mais relativement lourd à utiliser.



Ben justement, dans mes applications à moi il se retrouve pratiquement chaque fois indispensable, LOL. Alors si je ne dois utiliser C que de façon anecdotique dans ces applications, ça me fait perdre du temps plutôt que d'en gagner, et, surtout, ça oblige les internautes à disposer du même compilateur que moi (alors que mes sources en langage d'assemblage sont utilisables par tous).

De nouveau, tu vois, selon le point de vue on trouve des avantages et des inconvénients. Tu penses que j'utilise le langage d'assemblage sur les 18F parce que je ne connais pas le C, ou parce que j'ai fait un choix justifié pour moi?

C'est un langage qui a beaucoup de défauts, mais il reste tout de même fort pratique.



Mais je suis tout à fait d'accord. Mieux : j'adore le C et ses dérivés "objet".
C'est simplement que je ne le trouve pas adapté dans tous les cas, et, pour ma part, pas aux PIC 8 bits. Quand j'écrirai mon cours sur les DS-PIC, le C aura la part belle, c'est un choix qui devient très pertinent pour une grande partie des applications.
Du reste, beaucoup d'entreprises (comme Miele par exemple) sont passées au C sur micro lorsqu'elles ont basculé des micros 8 bits vers les micros 16 bits.

A défaut de mieux.



Ben non, justement, pas à défaut de mieux.
Mieux, meilleur etc, c'est de nouveau une notion de jugement, qui n'a pas sa place dans une argumentation généraliste.

Mais quand on voit des étudiants en arts qui prennent un arduino avec son C customisé à la Processing et qui font des trucs qui marchent...



Ben oui, mais ton raisonnement est à géométrie variable parce quand on voit des gens sans aucune connaissance qui achètent un PIC-Basic pour programmer des applications qui "marchent", c'est la même chose. Et pourtant, là, le basic est débile.

Le résultat est pourtant le même.

Peut-être que c'eut été possible que ça marche, au prix d'une énorme prise de boule inutile.



Ou peut-être que ta prise de tête aurait trouvé une solution évidente avec un autre utilisateur, va savoir si la faute incombe au composant?

J'ai pris un chip plus vieux où d'autres ont essuyé les plâtres (AT90PWM3B) -- succès total.



Ben, tant mieux, l'important c'est que tu sois arrivé au résultat que tu voulais, et non de tenter de démontrer qu'il n'y a qu'un seul bon choix.

chacun parle de son expérience mais pas des bases des architecture des machines: mathématiques, contraintes ....



Ben justement, moi je tente d'expliquer que tous les choix sont pertinents s'ils sont argumentés correctement et le fruit d'une saine réflexion. J'explique que les choix dépendent du contexte et que donc on ne peut pas parler d'un "meilleur" choix dans l'absolu. Je ne tente pas d'imposer un micro ni un langage, au contraire je dis que tous les choix doivent rester ouverts, surtout sur un forum comme celui-ci.
Moyennant quoi il n'est pas "correct" d'influencer un utilisateur sans disposer de données concrètes ni encore moins de dénigrer une partie des internautes qui ont fait un choix différent du nôtre (Pic primitifs et poussifs, assembleur hardcore et pénible, basic débile, et j'en passe).

Le meilleur c'est toujours le dernier sorti pour les criteres du projet car il beneficie de l'experience des predecesseurs...



C'est une façon de voir les choses.
On pourrait aussi dire que le meilleur c'est l'avant-dernier parce qu'il dispose d'un meilleur rapport performances/prix et qu'il est déjà grandement debuggé, LOL
Comme quoi il faut éviter de généraliser.

A+
Bigonoff
__________________
Vive l'internet libre
ftorama
ftorama ★★★★★★ 24/02/2011, 09h31 #38  
Posté par peufeu

>
C'est une grosse faiblesse du C et aussi des compilateurs, qui fait que quand tu as un petit 8 bits (avec instruction MUL) et que tu veux faire de la virgule fixe, mettons :

S16 a = un_capteur_analogique_quelconque();
U8 coeff = lis_ta_table_de_coeff( ... );

S16 b = (a*coeff) >> 8;

Eh ben, cet idiot de AVR-GCC instancie une multiplication 32x32 donc, ça rame atrocement. Alors qu'on peut virer une bonne partie des MUL.



Euh je viens de faire le test:
Code:
uint8_t a; uint16_t b; a=20; b=5234; c=a*b;


Afin que Gcc ne précalcule pas le résultat, j'ai désactivé l'optimisation (-O0) et l'opération ne fait bien appel qu'à 3 multiplications 8 bits et non 16.

Voilà le code généré:

Code:
a=20; 5e: 84 e1 ldi r24, 0x14 ; 20 60: 80 93 06 01 sts 0x0106, r24 b=5234; 64: 82 e7 ldi r24, 0x72 ; 114 66: 94 e1 ldi r25, 0x14 ; 20 68: 90 93 01 01 sts 0x0101, r25 6c: 80 93 00 01 sts 0x0100, r24 c=a*b; 70: 80 91 06 01 lds r24, 0x0106 74: 28 2f mov r18, r24 76: 30 e0 ldi r19, 0x00 ; 0 78: 80 91 00 01 lds r24, 0x0100 7c: 90 91 01 01 lds r25, 0x0101 80: ac 01 movw r20, r24 82: 24 9f mul r18, r20 84: c0 01 movw r24, r0 86: 25 9f mul r18, r21 88: 90 0d add r25, r0 8a: 34 9f mul r19, r20 8c: 90 0d add r25, r0 8e: 11 24 eor r1, r1 90: cc 01 movw r24, r24 92: a0 e0 ldi r26, 0x00 ; 0 94: b0 e0 ldi r27, 0x00 ; 0 96: 80 93 02 01 sts 0x0102, r24 9a: 90 93 03 01 sts 0x0103, r25 9e: a0 93 04 01 sts 0x0104, r26 a2: b0 93 05 01 sts 0x0105, r27
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits
peufeu
peufeu ★★★★★☆☆ 24/02/2011, 10h01 #39  
Hey dis donc t'as raison, j'ai l'impression qu'entre le gcc d'il y a 6 mois qui m'avait surpris avec ce bug et la dernière version, il a été corrigé...
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
aurelienr
aurelienr ★★★★★★ 24/02/2011, 11h21 #40  
Posté par Bigonoff

Et puis, c'est à cause de ce genre de discussion que j'ai délaissé un peu ce forum, parce que les mêmes arguments reviennent toujours inlassablement.


De plus ce sont souvent les memes qui commencent les hostilités en dénigrant subjectivement microchip...

Posté par Bigonoff

Mais bon, une fois de temps en temps, il me semble important, pour les nouveaux de ce forum, de clarifier le fait qu'ils ne sont pas débiles parce qu'ils utilisent tel ou tel langage, ni parce qu'ils utilisent tel ou tel micro


Ce fut deja mon impression il y a quelques jours sur le forum futura quand je parlais de mon avis sur la programmation ASM sur PIC. J'ai eu droit aux classiques remarques des classiques anti-pic sur le sujet...Le probleme étant qu'ils ne sont que deux ou trois...

Un condensé des deux :
http://forums.futura-sciences.com/e...pic-16f876.html
> Lancement de missile en #12, explosion en #14
> Critique subjective en #20
Désolé ftorama, tu est visé...à te lire parfois, il ne faudrait jurer que par les Cortex....ce qui me rapelle cette phrase qui tombe bien "Oui Minus, Bientot nous dominerons le monde", tiré des dessins animés Minus et Cortex...

C'est vraiment fatiguant...
peufeu
peufeu ★★★★★☆☆ 24/02/2011, 11h26 #41  
Posté par Bigonoff

Ben justement : ceux qui prétendent que le langage d'assembleur c'est compliqué à apprendre, c'est parce qu'ils assimilent automatiquement tout ce qui est dans le datasheet avec "assembleur".



Dans tous les cas il faut étudier les périphériques et registres, mais ce n'est pas bien compliqué si la datasheet est bien écrite.

Posté par Bigonoff

il y a plus de choses à étudier en utilisant le C (déjà toutes les librairies) qu'en utilisant le langage d'assemblage



L'OP connaît déjà le C et a déjà patouillé des micros...

Je ne me place pas dans l'optique d'un pur débutant qui ne connaît aucun langage, et n'a aucune notion de uC. Dans ce cas oui, commencer par les bases (ie, l'asm) pour comprendre le concept de registre, de périphérique, etc, c'est utile. D'ailleurs c'est par là que j'ai commencé (Z80 il y a des lustres, puis 68000).

Dans mon cas à moi où le but est de finir le projet, si je peux éviter, j'évite.

Posté par Bigonoff

Alors le temps d'apprentissage que tu auras économisé sera nul, et si tu avais commencé par le langage d'assemblage tu aurais compris plus vite bien des points.



Et je n'aurai toujours pas fini le projet XD

Si je voulais faire un gradateur 16 sorties sur bus CAN, je prendrais probablement un PIC programmé en assembleur. Mais en fait non, je prendrais directement ta réalisation, car je suis une feignasse !

Posté par Bigonoff

Sinon, à t'entendre, le C fait gagner du temps et de l'apprentissage,



J'aurais dû dire : quand on connaît déjà le C, alors le C fait gagner du temps et de l'apprentissage...

Posté par Bigonoff

Excuse-moi de penser que si la cible n'est pas adaptée au langage on produit manifestement du code tellement peu efficace que ça se ressent de façon visible sur la vitesse d'exécution du programme.



La cible "uC 8 bits" est moyennement adaptée au C, càd par exemple, le C marche très bien pour tout sauf la petite partie (petite, mais essentelle) DSP temps réel de mon appli, celle où j'ai inséré une routine de MUL en assembleur.

J'ai d'abord écrit tout le code en C, puis exécuté avec des signaux à vitesse faible ; ensuite mesure du temps de réaction : ça passe pas. Optimisation du code, mesure : ça passe. Tout écrire en asm aurait probablement permis d'aller un peu plus vite que ce qui est nécessaire, ce qui ne présente pas un grand intérêt...

Posté par Bigonoff

Donc, si le basic est débile, leurs utilisateurs sont débiles aussi.



Non, mais le BASIC incruste des habitudes néfastes (programmation non structurée, code spaghetti, etc).

Posté par Bigonoff

Ou peut-être que ta prise de tête aurait trouvé une solution évidente avec un autre utilisateur, va savoir si la faute incombe au composant?



Hm, va savoir... pour te faire plaisir, j'ai retrouvé l'errata en question XDDD

Dans les 35 bugs de l'errata du dsPIC33FJ06GS101 en question, on trouve :

7. Module: PWM
In PWM Latched Fault mode, the PWM outputs
may be latched on both the rising as well as the
falling edge of the Fault signal, regardless of the
fault input polarity selection (set with the
FCLCONx<FLTPOL> bit setting).
Work around : None.

=> bloquant

10. Module: Comparator
If the slew rate of the Comparator input signal is
lower than 198 mV/μs, the Comparator module
generates erroneous triggers/interrupts.
Work around
The Slew rate of Comparator input signal must be
higher than 198 mV/μs to avoid multiple triggers/
interrupts.

=> bloquant

13. Module: Comparator
The comparator interrupt should be generated on
a rising edge of the comparator output. When
using the inverted polarity setting for the analog
comparator (CMPCONx<CMPPOL> = 1), the
interrupt should be generated when the analog
voltage at the comparator input falls below the
programmable threshold determined by the
CMPDAC register setting. However, with this
setting the interrupts may be generated regardless
of the state of the comparator.
Work around
When using comparator interrupts, configure the
external circuit to use the non-inverted polarity
comparator setting (CMPCONx<CMPPOL> = 0).

=> contournable mais chiant

20. Module: PWM
Cycle-by-cycle current limit operation does not
work when the PWM module is configured for
Center-Aligned mode.
Work around
None.

=> bloquant

34. Module: PWM
The High-Speed PWM provides a feature to
update the PWM duty cycle at any time during the
PWM period. The new duty cycle should take
effect:
• On the next PWM period when immediate duty
cycle updates are disabled
(PWMCONx<IUE> = 0).
• On the same PWM period when immediate
duty cycle updates are enabled
(PWMCONx<IUE> = 1).
However, when the immediate duty cycle updates
are disabled and the duty cycle update coincides
with a PWM period roll-over, the PWM output may
be corrupted and exhibit a 100% duty cycle for one
PWM period. The new duty cycle value will take
effect on the next PWM period.
Work around
Enable immediate duty cycle updates by
configuring PWMCONx<IUE> = 1.

=> bloquant

1. Module: Idle Current (IIDLE)
The typical values for Table 24-6 were stated
incorrectly in the data sheet. The correct values
are shown in bold type in the following table.

(suit une table qui donne des consommations énormes, donc obligé d'utiliser le mode sleep, mais :)

9. Module: PWM
The PWM module fails to wake the CPU from
Sleep mode on a PWM fault event.
Work around
Use the external interrupt pins to wake the CPU
from Sleep mode.

=> très ennuyeux

Ce qui m'intéressait dans ce uC, c'est les périphériques : manque de bol, ils sont estropiés.

Je te l'accorde, c'est une appli un peu particulière, mais en l'occurence, mon opinion de microchip a pas mal baissé sur cet exemple ponctuel (pour avoir autant de bugs aussi énormes, ils ont testé ? ou simulé au moins ? lol).

(la lecture de la datasheet du MCP1630 a fini d'achever le processus).
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
aurelienr
aurelienr ★★★★★★ 24/02/2011, 11h31 #42  
Bon on arrete la comparaison de taille de queue ou je sors l'errata des Xmega :))
XF75
XF75 ★★★★★☆☆ 24/02/2011, 12h07 #43  
peufeu, tu as parfaitement raison!

La vielle équipe de Microchip est parti, ils ont refondu le process, poussé le dev, résultat: une pluie de probleme.
Comme Apple faut attendre la version 2!.

Senior en assembleur, sur un tas de cpu, en commençant par le SC/MP, je déconseille son apprentissage!!, ca donne de mauvaises habitudes.
Ok pour la bidouille, qui peut fonctionner, mais en pro, on cherche avant tout le portage, la fiabilité.

En fait le choix d'un cœur se faisait par tradition!, ainsi en automobile le 8051 tenait la tête (apres motorola), on récuperait les codes assembleur....aujourd'hui c'est le code "C".

Si la méthodologie est meilleur, l'ambiance n'y est plus.... donc le baclé !.

En architecture des machines, avant 1976, la taille optimal pour le codage des instructions était étudié.
De même que l'observation des codes machines interdit, et la découverte d'instructions cachées, rendant certains code non portable d'un coeur a l'autre identique/compatible mais pas de même génération.

Le taux d'utilsation des instructions est aussi un critere, par exemple le 68000 tres parallele, mais avec toujours des registres qui etaient de fait dedié (stack par exemple) avait un rapport pas favorable.

Voila des critères de comparaisons.... en architecture des machines....

XF
peufeu
peufeu ★★★★★☆☆ 24/02/2011, 12h15 #44  
Posté par XF75

La vielle équipe de Microchip est parti, ils ont refondu le process, poussé le dev, résultat: une pluie de probleme.



Non mais c'est dommage quoi, il était très bien ce dsPIC, mais les bugs... toujours pas résolus à la rév. 4, c'est quand même du grand n'importe quoi. C'est LE périphérique pour lequel tu prends CE uC en particulier, et il est véreux.

> ou je sors l'errata des Xmega

ça m'intéresse aussi
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill

Dernière modification par Fas54 24/02/2011 à 14h12.
aurelienr
aurelienr ★★★★★★ 24/02/2011, 12h28 #45  
Allez pour rigoler sur le Xmega256A3 :

En rev A :
========
• Bandgap voltage input for the ACs cannot be changed when used for both ACs simultaneously
• ADC gain stage output range is limited to 2.4V
• Sampled BOD in Active mode will cause noise when bandgap is used as reference
• Flash Power Reduction Mode can not be enabled when entering sleep mode
• JTAG enable does not override Analog Comparator B output
• Bandgap measurement with the ADC is non-functional when VCC is below 2.7V
• DAC refresh may be blocked in S/H mode
• BOD will be enabled after any reset
• Both DFLLs and both oscillators has to be enabled for one to work
• Operating frequency and voltage limitations
• Inverted I/O enable does not affect Analog Comparator Output


En rev B:
=======
• Bandgap voltage input for the ACs cannot be changed when used for both ACs simultaneously
• ADC gain stage output range is limited to 2.4V
• Sampled BOD in Active mode will cause noise when bandgap is used as reference
• Bandgap measurement with the ADC is non-functional when VCC is below 2.7V
• BOD will be enabled after any reset
• Writing EEPROM or Flash while reading any of them will not work
• ADC has increased INL error for some operating conditions
• DAC has increased INL or noise for some operating conditions
• VCC voltage scaler for AC is non-linear
• Maximum operating frequency below 1.76V is 8 MHz
• Inverted I/O enable does not affect Analog Comparator Output


Ce qu'il faut comprendre :
- la rev B est censée améliorer la rev A, au final on se retrouve avec plus de bugs (EEPROM/FLASH).
- l'ADC est au final un ADC plutot banal... A noter que l'ADC est annoncé comme pouvant mesurer la température interne du micro. Défi à quiconque veut faire ça simplement et trouve facilement de la doc à ce sujet
- écrire en EEPROM implique de ne pas lire la FLASH, on perd donc un temps fou à chaque ecriture

Aurélien
peufeu
peufeu ★★★★★☆☆ 24/02/2011, 13h59 #46  
Effectivement c'est très fort...

C'est l'état d'esprit informatique (origine du concept de non-qualité la plus éhontée) qui contamine tout : "release it now, fix it later"... mais chef c'est du hard... hein ?
__________________
Apaiser, c’est nourrir un crocodile en espérant être mangé le dernier
-- Churchill
XF75
XF75 ★★★★★☆☆ 24/02/2011, 14h10 #47  
Au moins vous avez aquis les bons reflexes!

Commencer par lire les errata, et ce méfier des chips qui n'en ont pas.
Tous cela, pour tout les constructeurs (pas seulement de chip) c'est la faute au marketing, vendre pour ferrer le poisson, le reste on s'en arrange...

Ca a coule des PMEs, et finit aux tribunaux!.

Reste ingénieure, la méthodologie.... et l'étude de l'architecture des machines.

La, Turing (mathématicien) a démontrer avec sa machine, le minimum nécessaire.
Qui a programmer en "Turing" s'en souviens!.
Le 12 bits en code est celui qui optimise les transistors.... d'ou le PIC et aujourdhui son cout exobitant ramemer au transistor par puce.
Le choix du 8 bit, le plus près du 7 bits de l'ASCII!.
Le 68000 un parallelisme a l'exces, ...beau...
....

XF
dspix
dspix ★★★★★★★ 24/02/2011, 14h20 #48  
Ce qui est drole dans tout ça, c'est qu'a chaque fois, on laisse de coté les besoins du montage...

C'est sure, on peux s'extasier devant tel micro au vu de ses performances et critiquer tel autre micro comme poussif et dépasser.... Mais tout le monde n'a pas le besoin d'un truc qui turbine... Genre faire une minuterie de cafetiere avec un arduino....

Les pic 12F existent, ils ne sont pas puissant, ils sont dépassés... qu'importe, leur performances convient pour ce dont j'ai besoin.... pourquoi j'irais prendre un truc qui turbine, et aller le coder en C juste pour ne pas faire partie de ceux qui font de l'asm sur des pic ??? A t'on besoin d'un micro 16 ou 32 bit capable de décoder du MP3 pour gerer un afficheur alphanumerique et quelques bouton ? Biensur que non....
__________________
A+
Damien
ftorama
ftorama ★★★★★★ 24/02/2011, 14h45 #49  
Posté par aurelienr

- l'ADC est au final un ADC plutot banal... A noter que l'ADC est annoncé comme pouvant mesurer la température interne du micro. Défi à quiconque veut faire ça simplement et trouve facilement de la doc à ce sujet



Si j'en crois la datasheet (mais je n'ai pas essayé), il suffirait de mettre le bit TEMPREF à 1 dans REFCTRL pour "préparer" le capteur de température (ne me demande pas ce que ça fait)

Ensuite, il faudrait mettre les bits INPUTMODE à 0 CTRL et enfin les bits MUXPOS à 0 dans MUXCTRL

pages 303 et de la doc:
http://www.atmel.com/dyn/resources/...nts/doc8077.pdf

Maintenant, ce sont des suppositions, fais le test ;)
__________________
Les forums ne sont ni des moteurs de recherche, ni des consultants gratuits
RM.TECH
RM.TECH ☆☆☆☆☆☆ 24/02/2011, 14h47 #50  
Posté par dspix

Ce qui est drole dans tout ça, c'est qu'a chaque fois, on laisse de coté les besoins du montage...

C'est sure, on peux s'extasier devant tel micro au vu de ses performances et critiquer tel autre micro comme poussif et dépasser.... Mais tout le monde n'a pas le besoin d'un truc qui turbine... Genre faire une minuterie de cafetiere avec un arduino....

Les pic 12F existent, ils ne sont pas puissant, ils sont dépassés... qu'importe, leur performances convient pour ce dont j'ai besoin.... pourquoi j'irais prendre un truc qui turbine, et aller le coder en C juste pour ne pas faire partie de ceux qui font de l'asm sur des pic ??? A t'on besoin d'un micro 16 ou 32 bit capable de décoder du MP3 pour gerer un afficheur alphanumerique et quelques bouton ? Biensur que non....



Tout à fait. Quand on voit ce que certains sont capables de faire faire à un 16F ou 18F, la ou certains auraient tout de suite placé un ARM7. Si l'application tourne à la perfection sur le petit 8 bit, pourquoi le faire avec un gros machin ?

Personnellement, je vise un marché de niche. Je n'ai pas besoin d'étudier les couts de chaque composants que j'utilise sur une carte. Je vise donc toujours au dessus de ce dont j'ai besoin pour être sur "que ça passe".

Mais honnêtement, je trouve que c'est une mauvaise méthode. Je prends des mauvaises manies, mes programmes ne sont pas optimisés.
Sans cesse coder sur un micro surpuissant, je pense qu'a la longue c'est mauvais pour le programmeur. Le jour ou il aura besoin de toute la puissance du micro le plus puissant....il va galérer comme un taré...

Page 1 sur 3