Programmer des microcontrolleurs avec du C/C++

[Flo_in_da_house]

Bonjour,

Je voudrais faire d´une pierre deux coups.
En effet j´aimerai apprendre à utiliser des microcontrolleurs (des pic, c moins cher ). Mais du fait du peu de temps que j´ai, je ne voudrais pas apprendre quelque chose qui ne me sert que comme loisir. Et donc je ne voudrais éviter l´assembleur qui ne me servirai que pour ca (et il faut avouer que c´est pas mal de boulot juste pour un loisir). Mais plutot du C/C++ qui une fois appris pourra me servir dans mes études.

Ainsi j´aimerai avoir l´avis des pros et des infos, des livres, des sites (je voudrais programmer des microcontrolleurs pour commander des servos)

Merci d´être précis.
@+

[Bigonoff]

Salut
-------

De toutes façons, je tiens à te préciser que même si tu veux programmer en C, tu seras forcé d'étudier le pic. L'utilisation du C ne te dispense pas de te servir des modules CAN, CCP et autres interruptions. Pour un programme un tant soi peu complexe, tu devras savoir comment fonctionne le pic.

L'assembleur 16F ne comporte que 35 instructions, et celui du 18F, 75.
C'est bien peu à apprendre, comparé à tout le reste des fonctions des pics.

Le C++, tu peux déjà oublier pour les pics, la programmation objet sur des microcontrôleurs, ce n'est pas pour tout de suite (manque de ressources, particulièrement de RAM et de pile).

Le C, ça peut aller à la limite, mais alors pour les 18F, car, pour les 16F je pense que ce n'est pas adapté. Le C est un langage gros consommateur de pile (passage de variables etc), or les 16F ne permettent pas à l'utilisateur de gérer la pile. Tu as donc un C "amputé" d'une grosse partie de sa puissance.

Enfin, pour les pics récents, il faut acheter le compilateur, alors que l'assembleur est gratuit.

Bon, maintenant, c'est clair que si c'est pour de petites applications pas critiques en temps d'exécution et en taille, le C conviendra.

Mais l'assembleur permet de tout faire, alors que le C ne le permet pas (sauf à écrire des parties de code en assembleur, mais alors tu dois quand même l'étudier).

A+
Bigonoff

[Flo_in_da_house]

Salut,


Pour le C on m´a conseiller cela: http://ccsinfo.com/picc.shtml
C´est vrai ce n´est pas gratuit , mais les exemples de programme on l´air tellement simple est à ma porté, pour peu que je commence le C.
Et comme j´aurais besoin du C pour mes études se sera plus pratique: pour me souvenir des instructions, et pour économiser du temps.
Le problème il y a très peu d´exemples de programme en C (du moins là où j´ai cherché: sur le net), et cela m´inquiète de ne pas m´y retrouver (a moins que j´achete des tutorials sur le site d´avant).

Pour l´assembleur j´ai tout ce qu´il me faut sous la main: tes cours qui sont bien fait et motivant. Mais ils demandent tout de même un travail sérieux, et cela prends pas mal de temps avec en plus le boulot à la fac.
Ce qui m´inquiète aussi c´est le fait d´oublier toutes les instructions, si je ne m´en sert plus pendant un moment (c´est ma plus grande crainte !).
L´avantage c´est qu´il y a plein d´exemples déjà fait pour l´asm.

Mon "rêve" serait de savoir faire des commandes automatiques de servos, c´est tellement pratique, pour mes bricolages.

Donc finallement je sais toujours pas quoi choisir
Je ne voudrais pas en commencer un et le regretter. Sachant que mon utilisation des pic sera tout de même faible et pour des applications que je suppose simple.

Je serais heureux d´avoir ton avis sur mes craintes pour que je puisse enfin me décider.

Merci

[14bds75_cb]

salut !

Franchement, je te conseile de programmer en assembleur !
J'étais moi aussi rétissant, mais tu vas sur le site de Bigonoff, et tu télécharge el cours, et en une petite semaine d'apprentissage c'est bon pour les bases !

Amitiés

[the6mdfr]

Salut,

Si comme moi tu utilise les pic occasionellement tu te fait un petit répertoire des différentes commandes (et registres ils sont tres important)
que tu pourras consulter trés rapidement lors de la création de programme.(tu les apprendras automatiquement à t'en servir)

De plus grace au logiciel MPLAB tu peux facilement simuler ton programme (avec certaines limites).
Et selon mon expérience (biotechnicien en clinique) il n 'y a pas de temps perdu en apprenant un language machine ou autres, tu verras trés vite que dans le monde du travail on demande de plus en plus de polyvalence.

Rien n'est facile, tous s'apprend.

A plus.

[guerrier]

si tu n envisage que le C je te conseille vivement les AVR avec avr-gcc
c est ptet un peu plus cher, mais c est le must

[sly535]

Un kit complet (micro+cable+logiciel) avec un micro AVR de type 90S8535 te couteras environs 45 Euros.

Maintenant à toi de choisir : PIC ou ATMEL

[Jack]

n'oubliez pas motorola

L'assembleur, le simulateur, le debugger et même le compilateur C et C++ sont gratuits (limité à 4k de code pour le C/C++) si tu optes pour le 68HC908.

Les prix sont du même ordre que ceux des PICs à fonctions équivalentes.

Au moins, tu as le choix.

A+

[Flo_in_da_house]

Bonjour,

J´ai regardé ce que vous m´avez conseillez.
Je pense que l´assembleur c´est comme d´apprendre une langue étrangère. Mais après il faut encore savoir faire des phrases avec les mots appris. Le hic c´est que pour le moment ce serait plutôt pour le loisir que pour le boulot, donc au niveau du temps à consacré c´est peut être risqué; a moins que vous ayez encore des arguments pour me convaincre ?

Dans l´état de mes recherches à une solution, je pense au C où au PicBasic avec:
http://ccsinfo.com/picc.shtml pour le C
et
http://www.lextronic.fr/Comfile/PP1.htm pour le PicBasic

Le C me serait utile, comme dit, parce que je vais bientôt devoir l´apprendre en fac. Mais les infos on l´air moins facile à trouver (kit, exemple de prog, montage,...), déjà la page est en anglais (et souvent les notices aussi). Et je ne voudrais pas me retrouver larguer une fois tout acheté.

Pour le PicBasic, il a l´air plus fréquent, plus abordable au niveau prix (du kit) et apprentissage.

Pour revenir à l´assembleur, il a l´air plus compliqué pour faire un programme de commande de servo qu´avec du basic pour le PicBasic.

J´aimerai avoir vos témoignage si vous avez essayé un des deux. Et aussi, avec votre recule, ce que vous feriez à ma place dans ces conditions.
Et si vous avez des liens, ce serait super !


Merci.

[constantin]

Salut,
au début j'ai appris asembleur pour pic ( j'avais déja fait pour 8085,8051 et pour le ST62xx ). L'assembleur était pour moi le must.
depuis 1 ans j'ai essayé le C sur le pic et la je trouve cela plus conviviale.
Par contre cela ne va pas t'éviter de devoir connaitre le pic , registre , etc..

La grosse différence entre le c et asm est que si l'utile peux, tu te souviens plus facilement du C. Un if (in) est plus parlant que BTFSS ...

Par contre l'apprentissage du c pour pic me parrait plus compliquée si on a jamais utilisé un µP en ASM.

Je ne suis pas d'accors sur le faite que le c utilise beaucoup de ressourse.

Perso j'utilise la version CC5X comme compilateur c

[biganos]

Salut à tous,
bon je ne vais pas entrer dans la polémique C contre assembleur pour la programmation des microcontrôleurs, d'autant que je cherche moi-même l'oiseau rare. Simplement quelques remarques, j'ai une formation d'analyste programmeur et j'ai travaillé en C et en assembleur.
Le C est loin d'être ridicule en temps d'exécution (quand un prog est OK, on peut même y inclure quelques lignes d'assembleur pour booster certaines fonctions).
Il est rès facile de construire des programmes structurés en C ce que ne permet pas l'assembleur. Or dans la vie d'un programme, 80% du temps y est consacré à des modifications pour le faire évoluer, et je ne parle pas du temps de débogage. Quand un programme est bien structuré, les mises à jour sont rapides et fiables (on réutilise de nombreuses fonctions). En assembleur, c'est une autre histoire.
Enfin si un jour tu changes de microprocesseur, pratiquement toutes les fonctions que tu aura écrites en C seront portables sur le nouveau matériel. En assembleur on est obligé de tout ré-écrire de A à Z.
En fait le C est un langage de programmation dit de "haut niveau" par opposition aux assembleurs (oui au pluriel) qui eux sont des langages de "bas niveau", ce qui n'est pas péjoratif, puisque ça signifie qu'ils sont capables de dialoguer directement avec les couches logicielles les plus proches du matériel (du hard), donc plus rapides, mais ... qui ne concernent qu'un seul matériel et il faut ré-inventer la roue à chaque fois.

[Bigonoff]

Salut
------

bon je ne vais pas entrer dans la polémique C contre assembleur pour la programmation des microcontrôleurs

Heuu, j'ai pourtant l'impression que c'est ce que tu fais
Donc, pour faire comme toi, je n'entre pas dans la polémique, je me contente de répondre à ton argumentation

j'ai une formation d'analyste programmeur et j'ai travaillé en C et en assembleur.

Moi aussi. Je suis électronicien spécialiste en microprocesseurs et informaticien système. J'ai donc une double spécialisation en la matière.
Je connais le C, et pas mal d'assembleurs, j'ai travaillé sur serveur unix (un peu), sur ordinateurs persos de plusieurs marques (en assembleur, en C, en basic), et sur différents microprocesseurs et microcontrôleurs, je compare donc en toute connaissance de cause.

Le C est loin d'être ridicule en temps d'exécution (quand un prog est OK, on peut même y inclure quelques lignes d'assembleur pour booster certaines fonctions).

Ridicule, je n'irais pas jusque là. Mais moins efficace que l'assembleur, sans aucun doute possible. Mais s'il faut y ajouter quelques lignes d'assembleur, alors il faut apprendre l'assembleur en plus du C. La question précisait "apprendre le C à la place de l'assembleur".

Maintenant, lorsqu'on parle de vitesse et de temps d'exécution, il est clair que tout dépend du projet.

Si le projet réclame la pleine puissance du microcontrôleur, alors le C ne sera pas ridicule, il sera tout simplement inutilisable.
Par contre, s'il s'agit d'afficher "hello" sur un afficheur LCD, l'utilisateur ne verra pas de différence (c'est volontairement caricatural).

Il est rès facile de construire des programmes structurés en C ce que ne permet pas l'assembleur

Ca, c'est un argument que je n'accepte pas. C'est le programmeur qui fait que son programme est structuré ou pas, pas le langage.

Tous mes programmes assembleur sont structurés et parfaitement maintenables. Par contre, je connais des programmeurs qui écrivent des lignes en C parfaitement incompréhensibles. Je ne parle même pas d'un programme complet, je parle d'une simple ligne, style "tableau de fonctions qui retournent des pointeurs sur des tableaux de structures"

je ne parle pas du temps de débogage. Quand un programme est bien structuré, les mises à jour sont rapides et fiables (on réutilise de nombreuses fonctions). En assembleur, c'est une autre histoire.

Le debuggage en assembleur est beaucoup plus simple qu'en C, parce qu'il existe des outils performants qui ne sont pas disponibles pour le C, principalement au niveau des debuggers on-circuit.

Pour le reste, je ne vois pas en quoi l'utilisation de l'assembleur interdit d'utiliser des fonctions et des librairies, on ne doit pas parler de la même chose. On peut écrire un programme C qui ne contienne qu'un "main", et personnellement, mes programmes assembleurs sont composés de sous-routines dont chacune exécute une fonction élémentaire. Ca n'a rien à voir avec le langage.

Autant il est idiot de programmer sur PC en assembleur, à l'heure actuelle, autant le langage le mieux adapté pour les pics 16F est bel et bien l'assembleur.

Enfin si un jour tu changes de microprocesseur, pratiquement toutes les fonctions que tu aura écrites en C seront portables sur le nouveau matériel. En assembleur on est obligé de tout ré-écrire de A à Z.

Heuuu, tu es certain que tu programmmes des microcontrôleurs????
On ne parle pas de microprocesseurs, là, on parle de microcontrôleurs...
Essaye de porter un soft de microcontrôleur d'un micro à l'autre, même écrit en C, et tu m'expliqueras comment tu fais pour ne rien modifier.
Quant aux C (ben oui, au pluriel également, LOL), ils diffèrent suivant les éditeurs, et donc varient également d'un microcontrôleur à l'autre (bonjour la portabilité).

La particularité d'un microcontrôleur, c'est la présence de modules hardwares internes, qui fonctionnent de façon différente sur chaque micro.

Autrement dit, les solutions pour résoudre un problème complexe vont dépendre de ces ressources, et donc seront typiquement adaptées au microcontrôleur choisi. C'est utopique de penser que le C permet la portabilité à ce niveau. S'il y a un argument injustifié, c'est bien celui-là.

Pour ce qui est des simples "fonctions" universelles, il est inutile de chercher à les "porter", elles sont fournies d'office avec chaque microcontrôleur.

En fait le C est un langage de programmation dit de "haut niveau" par opposition aux assembleurs (oui au pluriel) qui eux sont des langages de "bas niveau", ce qui n'est pas péjoratif, puisque ça signifie qu'ils sont capables de dialoguer directement avec les couches logicielles les plus proches du matériel (du hard), donc plus rapides, mais ... qui ne concernent qu'un seul matériel et il faut ré-inventer la roue à chaque fois.

Un langage "haut niveau" ne couvre que la partie logicielle, et non la partie matérielle.

Si tu écris un programme complexe en C sur un PC, il sera complètement différent du même programme écrit pour un Amiga, par exemple.

Sans ça, les logiciels écrits pour une machine seraient utilisables sur n'importe quelle machine après recompilation. Or, ce n'est pas le cas, sans ça les éditeurs ne manqueraient pas de le faire (ils ne sont pas fous).

De nouveau, c'est l'utopie de la portabilité, qui n'existe que pour des fonctions indépendantes du matériel. Autrement dit, ça fonctionne pour un calcul mathématique, mais pas pour une ouverture de fenêtre. Or, 90% d'un logiciel actuel couvre le pilotage de l'interface utilisateur et du matériel.

Tu reconnais que l'assembleur est plus rapide. Or, dans des tas d'applications pratiques réelles des microcontrôleurs, on a besoin de rapidité.

Quant à réinventer la roue, ce n'est pas le cas non plus, plus que pour le C. La seule chose qu'on doive réétudier, ce sont les quelques malheureuses instructions. Le hardware est à étudier quel que soit le langage, et les librairies fournies par le constructeur évitent de devoir "réinventer la roue".

Moi, je ne critique pas le C, je dis simplement que l'assembleur est plus approprié pour un microcontrôleur du style d'un 16Fxxx. Le C est plus adapté à un système pourvu de ressources plus importantes, et notemment d'une pile efficace, ainsi qu'à un système dont les vitesses d'exécution sont moins critiques.

Preuve en est qu'on peut réaliser n'importe quel projet sur PIC sans utiliser une seule ligne de C, mais on ne peut pas réaliser n'importe quel projet en C sans écrire une partie du code en assembleur.
L'assembleur ouvre toutes les portes, pas le C.
Donc, s'il faut choisir entre un OU l'autre, la question ne se pose même pas (à mon avis).
Celui qui prend la voie du C sur les pics doit apprendre le C ET l'assembleur, sans ça, il sera calé sur une ou l'autre application.

En plus, je te passe les bugs des compilateurs (bel et bien présents) qui entraînent l'utilisateur dans des séances de debuggage très compliquées pour un novice (et qui, de nouveau, exigent la comprégension de l'assembleur pour voir ce qu'à construit le compilateur).

Donc, ma réponse à la question intiale est la suivante :

Pour programmer correctement et efficacement un pic, tu dois, soit :

- Utiliser l'assembleur
- Utiliser le C ET l'assembleur

Dans les deux cas, je crains fort que le passage par l'assembleur ne soit obligatoire, excepté bien entendu si tu limites le champs de tes applications pratiques.

C'est mon avis

A+
Bigonoff

[biganos]

Bonsoir à tous.
Tu as raison Bigonoff, on ne parle pas de la même chose et j'aurais du être plus clair.

Flo_in_da_house voulait éviter l'assembleur et se rapprocher du C/C++ qu'il pourrait utiliser pour ses études. J'ai accroché là-dessus vu qu'il y a pas mal de réponses concernant uniquement les microcontrôleurs. Il aurait sans doute été plus clair que je dise que mon propos ne concerne pas la programmation des microcontrôleurs, mais le C qu'il pourrait utiliser pour ses études.

Effectivement Bigonoff, je n'ai pas encore programmé de microcontrôleur, ni prétendu le contraire, mais à lire ta réponse il doit planer un doute que je lève volontiers. Concernant les PIC, j'ai seulement un projet en phase d'étude pour lequel l'oiseau rare sera très probablement un 18F452.

Donc pour ce qui concerne le C, il est certain qu'il permet de se construire assez simplement des outils adaptés, rapides et peu coûteux en ressources, quel que soit le domaine d'étude. Et je peux dire par expérience qu'un outil même personnel aura tendance à évoluer. Or si pour un outil donné il faut par exemple 1000 ou 2000 lignes de code en C, le gain de temps d'exécution sera cher payé comparativement au temps de développement en assembleur.

Si en plus on change de microprocesseur (c'est bien de ça que je parlais), les compilateurs suivant en général assez vite, les outils en question peuvent rapidement bénéficier des particularités du nouveau matériel. Il suffit de recompiler avec le nouveau compilateur.

C'est vrai que je suis un peu hors sujet "microcontrôleur", mais je ne peux que l'encourager à apprendre le C. Par contre, comme l'assembleur incite à jongler avec les sauts, je ne le considère toujours pas comme structuré à ce niveau .

[Flo_in_da_house]

Merci pour toute ces réponses !

Finallement je me suis décider à utiliser des Basicpic de comfile, il y a un mode d´emploi et il n´y a pas besoin de comprendre la structure du composant pour pouvoir s´en servir. De plus le basic n´a pas l´air insurmontable.

Deplus j´ai aussi commencé à apprendre le C .


Pour le picbasic je me pose tout de même une question: est il possible de connecter directement un servo au microcontrolleur (avec alim séparé biensur) ??

[biganos]

Bonne réponse Flo_in_da_house, tu as trouvé une alternative. Pour la peine je vais te raconter une histoire que je tiens d'un vieux prof (de... techno si j'ai bonne mémoire), et je vais abréger.

Un bon charpentier peut parfaitement fixer une charpente avec un marteau de vitrier de 200g.
De même un bon vitrier peut fixer une vitre avec un marteau de charpentier de 2Kg.

Pour réussir, le charpentier devra donner beaucoup plus de coups de marteaux que d'habitude, et le vitrier devra agir très lentement avec d'infinies précautions.

Pourtant ils utilisent tous les deux un outil dont la fonctionnalité est identique (enfoncer des pointes), mais pas forcément le mieux adapté à chaque usage.

Je crains que ton idée de départ (faire d'une pierre deux coup) ne soit pas très réaliste, et je pense que tu as raison de distinguer la programmation des microcontrôleurs de celle de tes outils d'études.

Salut.

[guerrier]

bigonoff, je ne suis pas tout a fait d accord la !!

la portabilite existe, meme sur uC a condition d utiliser des librairies (de les creer pour chaque uC quoi) qui interfacent le materiel de facon standard!!

ex: une UART, qui change (et encore pas enormement) selon les uC peut tres bien etre utilisee si on l interface avec des librairies standardisees (printf() ou putc(), getch() par ex....)
meme remarque pour un LCD ou un clavier, ou d autres peripheriques

Cela existe donc bel et bien (j utilise ca souvent sur des AVR, bien plus puissants)

Bon ok, il faut avoir un peu temps de calcul et de flash en reserve, mais c est tout a fait faisable.

avec de la rigueur et de la methode en asm on obtient des programmes bien structures, avec de la rigueur et de la methode en C on a dess programmes bien structures et des applications portables

[Bigonoff]

Salut
------

Pour Biganos : avec ta rectification, on est d'accord.
A l'heure actuelle, il ne me viendrait pas à l'idée de programmer un microprocesseur style pentium4 dans son environnement en assembleur.
Ca n'a de sens que pour certaines applications très spécifiques.
Par contre, pour les microcontrôleurs, la question prend tout son sens.

Pour guerrier : La portabilité n'existe que de façon sommaire, et n'est pas du tout envisageable pour un logiciel un temps soi peu "pointu".

En effet, les ressources mises à disposition sont complètement différentes d'un contrôleur à l'autre, et si on peut concevoir la "portabilité" pour écrire "hello" sur un afficheur, au contraire un projet complexe nécessite de réaliser logiciel et hardware simultanément, qui sont donc étroitement liés, et donc, par définition, non portables.

Pour prendre un exemple, si j'ai besoin de traiter des signaux en interruption, il est évident que le nombre de signaux à traiter dépend du nombre de pins d'interruptions présentes sur le contrôleur, de sa possibilité ou pas de gérer des priorités d'interruption, et donc le passage du contrôleur X à Y nécessitera probablement de modifier le hardware, et donc les solutions logicielles.

La portabilité se limite aux fonctions de base, et conduisent à un code inefficace si on ne tient pas compte du hardware.

Exemple, si on gère deux liaisons série alors qu'on ne dispose que d'un USART, le temps monopolisé sera complètement différent que si on utilise un hardware externe approprié.

Donc, la portabilité pour des projets "simples" et non gourmands, à la limite, mais pour des applications efficaces, il faut programmer en connaissant les caractéristiques hardware du contrôleur utilisé.

En plus, tu me parles de créer des librairies pour assurer la portabilité.
Si on en arrive à devoir créer pour que le logiciel soit portable, c'est que le langage ne n'est pas réellement au départ.
Sans quoi, je peux créer des librairies assembleur exactement de la même façon, et mes programmes seront aussi "portables" que ceux écrits en C (librairie de gestion de clavier, de moteurs etc). Du reste, il y en a sur mon site.
Donc, en ce sens, l'assembleur est aussi "portable" que le C.

Mais ça nécessite, comme tu le dis, de la réserve de temps (pas mal de réserve) et d'espace, et je programme courament des applications dont le timing est critique, donc portabilité = 0 et utilisation d'un langage évolué impossible.

Le C était initialement prévu pour être "portable" dans le monde des PC. On voit ce qu'il en est aujourd'hui si on tente de changer de plateforme.
Le Java est déjà plus "portable", mais on en voit tout de suite le prix : lenteur et inefficacité.

Mon avis est que plus on tente d'être "portable" et donc "universel", moins on est efficace. Et dans le monde des microcontrôleurs où les ressources sont limitées, on a moins les moyens de les gaspiller.

De plus, lorsqu'on change de microcontrôleur pour une application, il faut recommencer tout le hardware, alors à quoi servirait la "portabilité" du logiciel écrit?

A propos, je ne vois pas en quoi un AVR est prétendument plus puissant qu'un PIC18F. Si c'était le cas, plus personne n'utiliserait de pics, j'ai le sentiment que c'est le contraire qui est en train de se passer.

Chaque famille a ses avantages et ses inconvénients, et, à génération égale, les caractéristiques globales sont similaires.

L'efficacité d'un microcontrôleur dépend de l'application dans lequel on le place, et pour lequel il est plus ou moins bien adapté.



A+
Bigonoff

[sly535]

Je me permet d'intervenir plur plusieurs raisons :

quelques soient les discussions les plus élaborées , il en sortirat inévitablement le fait que le language en assembleur reste le language natif du microcontroleur, donc le plus performant. Une modification de programme reste facile à réaliser (certe moins qu'en C ou basic), si le programme à été écrit de facon riguoureuse.
Le C ou basic sont des languages sans doute moins barbares, mais de toute facon plus lent, preuve les programmes d'acquisition haute performance pour pc sont réaliser en assembleur pour la partie timing.

Concernant la portabilité, celui ci est différent d'une famille à une autre, en ce qui concerne les atmel, le noyau est identique d'un modèle à l'autre et il est aisée de changer de gammes.

Maintenant pour les microcontroleurs que nous utilisons, le temps et l'espace de code sont des paramètres qu'il ne faut pas gacher, conclusions : mieux vaut utiliser l'assembleur si le programme et complexe, paradoxalement, les programmes PC compilé avec tout autre code, sont 'idiot', car il leurs arrive de répeter des centaines de fois des opérations non necessaires, mais comme déja cité, l'informatique ne serait jamais ce quelle est si les éditeurs programmait en assembleur.

Concernant le poins suivant :

A propos, je ne vois pas en quoi un AVR est prétendument plus puissant qu'un PIC18F. Si c'était le cas, plus personne n'utiliserait de pics, j'ai le sentiment que c'est le contraire qui est en train de se passer.

il faut etre réaliste, microchip s'étant attaqué au marché industriel très top avec de petit microcontroleurs, ce qui à changé littéralement la facon de concevoir les systèmes comparé aux mastondontes d'antant, la marque à profiter d'un essort 'amateur' indiscutable, et aider en grande partie par le revue dont je soupconne.... non rien

Maintenant, je crois que à contrario de ce que site Mr bigonoff la tendance semble s'inverser : les atmel on le vent en poupe, on les voies de plus en plus dans les revues, pour cause, les outils de développement sont gratuit, ce qui semble loins d'etre le cas avec les microchip dont les éditeurs logiciels se moque du monde amateurs en leurs vendant des compilateurs hors de prix, sous pretexe que tout deviens facile, il y à 10000 produits dérivés, moi j'aime pas trop ca, l'impression que ca me donne c'est d'etre à la foire à neuneu, corrigé moi si je me trompe (je ne me sert pas de microchip), la facilité de réaliser des interfaces de programmation in situ, la gratuité d' AVR studio : éditeur, assembleur, simulateur, programmeur !

Encore une fois je resterai sans parti pris mais je constate aussi :
Que les pics n'ont qu'un accumulateur (AT = 32)
Le temps d'execution des atmel et meilleurs, ainsi que les tailles de mémoires (ram/eprom)
L'organisation de la mémoire est paginée en 2 blocs
Jeu d'intructions RISC (peut d'instructions)

Voila pourquoi personnelement je n'ai jamais programmé PIC, j'était resté 'à l'époque' au 51.

Je ne crache pas sur les microchip qui reste aussi de très bon controlleurs, mais chacune des familles à une philosophie différente