depuis quelques temps j'envisage de me lancer dans la programmation de PICs en C (l'assembleur étant trop effrayant) du fait des prix très agressifs proposés par Microchip. Je parle des uC à 30 cent l'unité (pour les premiers prix) et 2/3 € pour des modèles plus avancés contre des arduino avoisinant les 20 €. De plus les pics semblent être très divers ce qui permet d'être très flexibles sur leurs performances.
Je m’intéresse du coup au PicKit (2 ou 3) comme programmateur et pour le choix des Pics c'est la que ça devient compliqué...
Les pics se programment-ils tous de la même façon ? si l'on sait programmer le fameux 16F84 pourra-ton programmer tous les autres de la serie (moyennant bien sur quelques ajustements mineurs) ?
Sont-ils directement fonctionnels après programmation ou as t on besoin d'oscillateurs et de composants supplémentaires ?
Pardon pour le flou des questions, j'ai lu beaucoup de choses (sûrement pas assez tout de même) et le tout est comme je l'ai dit : flou.
Oui les PICs se programment tous de la même façon. Que ce soit de manière physique (2 broches de "donneés", et la tension de programmation) comme de manière logicielle. Après certains PIC fournissent des modules que d'autre n'ont pas comme des CAN, la gestion de l'I²C, SPI etc...
Ensuite, une fois programmé le microcontroleur à en effet besoin d'un système d'horloge tu as deux choix :
Utiliser l'horloge interne à 4MHz qui suffit amplement pour des applications ne demandant pas de traitement trop rapides
Utiliser un quartz avec lequel tu pourras monter jusqu'à 20MHz
A savoir tout de même c'est que la fréquence réelle du µC est divisée en interne par 4.
J'avais commencer également avec des PICs et je te conseil le très connu 16F84 pour te faire la main et voir si tu t'y plais et ensuite le 16F873 ou 876 qui disposent de tout ce qui est nécessaire pour balayer un bon pan des systèmes microcontrolés
Comparé un PIC à une Arduino c'est un peu faussé comme raisonnement (je ne dis pas ca pour défendre l'Arduino, j'aime aussi les PIC )
Une Arduino est composé d'une carte électronique, d'une myriade de composant pour que tout fonctionne, de connecteur pour que tu puisses brancher tes fils et compagnie, et le tout doit être assemblé. Effectivement ca coute forcément plus cher qu'un PIC tout seul. Si tu achetais juste le microcontrolleur de l'Arduino tu en aurais aussi juste pour 3€, mais le jour ou tu voudras mettre ton PIC sur une vrai carte avec tout ce qui va autour tu verras que les prix augmente !
Pour ce qui est des "autres" composants en plus du microcontrolleur, il te faudra au moins un condensateur de découplage (100nF plastique), et ensuite si tu veux travailler à 16 ou 20MHz il te faudra aussi un quartz et des petits condos pour la cellule d'oscillation. Pour l'alimentation, un bête chargeur USB suffit.
Et pour les questions, n'hésite pas à les poser, c'est comme ca qu'on fait avancer le schmilblick !
Je ne vais pas répéter ce qui a déjà été dit, mais juste rajouter un petit point sur les microcontroleurs Microchip qu'il est possible de se procurer en sample sur le site officiel. On est limité à 3 ou 5 références et 3 unités par références, et une commande tous les 3 ou 6 mois je crois.
Mais question prix, c'est imbattable puisque c'est gratuit, y compris les frais de ports, il faut juste être un peu patient puisque l'acheminement peut prendre jusqu'à 15 jours.
Il est vrai que pour débuter la programmation de façon rapide et efficace, une carte Arduino est pratique. J'ai personnellement commencé avec les PIC et y suis maintenant habitué. Je ne trouve pas que l'environnement nécessaire à un PIC soit trop cher ou trop conséquent pour être handicapant que ce soit au niveau du budget ou de la mise en place de la carte. Tout ce dont tu as besoin c'est de quelques composants à prix somme toutes modique. Là ou la question peux se poser c'est au niveau du PICKit qui n'est pas donné. A titre personnel je trouve que c'est un bon investissement puisque après tu pourras programmer tout les PIC que tu veux.
A toi de faire le choix ces deux solutions sont tout à fait équivalentes mais chacune présente inconvénients et avantages
Merci beaucoup pour les réponses. A vrai dire je comptais utiliser les pics tels quel sans oscillateurs. Et j'ai parlé d'arduino parce que je m'attendais à une foule de remarques me conseillant de m'orienter vers l'arduino que j'ai pu approcher avec les teensy.
Pour le Pickit je suis pret a investir presque une trentaine d'euro voire un peu plus pour avoir quelque chose de très interessant au final.
Je pense donc que je vais m'acheter un Pickit 2 avec une floppé de Pic 16F84.
Merci beaucoup
ps: programmez vous les pics en C ou bien en assembleur ?
pour ma part c'est du C avec l'IDE MPLABX (bien qu'étant plutôt lent sur un ordi un peu vieux, celui-ci étant codé en Java, donc assez gourmand).
Tu peux également utiliser MPLAB 8, plus rapide, mais beaucoup moins convivial que le premier, l'auto-complétion n'étant pas présente sur ce dernier (et disponible que sur du Windows si je ne m'abuse).
Bsr à tous. J'ai un petit problème pour avoir le kit Arduino. En effet je suis au Bénin( Afrique de l'ousest) et je ne sais pas où se vend le kit arduino dans mon pays. J'aimerais bien que qelqu'un m'aide à l'acheter. Merci!
Bsr à tous. J'ai un petit problème pour avoir le kit Arduino. En effet je suis au Bénin( Afrique de l'ousest) et je ne sais pas où se vend le kit arduino dans mon pays. J'aimerais bien que qelqu'un m'aide à l'acheter. Merci!
Quels sont tes besoins Nicolas (quels genre de programme veux-tu faire ?) ?
=> si tu veux faire du langage C, je partirai sur des PIC32MX (si tu restes chez Microhip). Et là tu n'auras pas le choix : tu seras obligé d'acheter une carte d'eval (ce qui te reviendra au moins aussi chère que l'Arduino).
Pourquoi partir sur du PIC32MX ? ... parce qu'il y a beaucoup plus de RAM/ROM que les autres produits Microchip (et en plus il est plus rapide mais ce n'est pas forcement indispensable) et il a des interfaces Ethernet et USB.
Cette carte d'eval est pas mal : http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en545713
=> pas besoin de PICKit : il y a une interface de programmation via USB (le cable est même fournis). C'est un peu plus lent a programmer que si tu passais par un PICKit mais ça t'évite d'en acheter un.
=> inconvenant de cette carte : pas de connecteur de port série et de programmation pour PICKit
Il y a d'autres fabricants : ATMEL, NXP (ARM)...
PS : le PICKit 2 est abosolète, si tu en achètes un, il faut du PICKit 3
Pourquoi forcément du PIC en fait. Il y a de bien meilleurs microcontrolleurs sur le marché et à des prix qui ne devrait pas rebuter un particulier.
Je pense en particulier aux LPC de NXP (anciennement Phillips semiconductors). Ils sont basés sur des Cortex donc de l'ARM, de plus il existe de bons environnements de dev pour ces chips, notamment mbed ou LPCeXpresso.
NXP ne sont pas les seuls a proposer de tels solutions a base de Cortex, STMicroelectronics (cocorico !) fait exactement la même chose avec ses STM32. Ont retrouve les même minicartes de dev a la arduino avec Leaflabs Maple ou des cartes d'évaluations (ST Discovery boards).
Le gros avantage de ces solutions par rapports au PIC c'est que les cartes contiennent justement tout ce qu'il faut pour fonctionner 'out-of-the-box'. Si tu débute vraiment en système embarqué, ça me parait beaucoup plus adapté. Après si tu veux juste faire clignoter une LED, les PIC ferons bien l'affaire.
Regarde bien le lien que j'ai mis, le PIC32MX est une architecture MIPS32 donc a peu prêt équivalente au CORTEX et on peut dire que la carte d'éval est de type 'out-of-the-box' (tu installes l'IDE, tu te connectes en USB et c'est parti pour programmer).
De plus la pile IP de Microchip est l'une des plus fournie (c'est essentiellement pour ça que je suis parti sur Microchip) : pour avoir l'équivalent chez les concurrents, c'est en générale payant.
Par contre le gros avantage des ARM, c'est qu'il y a plein de fabricants et donc plein de modèle de Microcontrolleur différents : donc si tu as un jour besoin d'un Microcontrolleur avec certains périphériques bien spécifiques, tu auras plus de chance d'en trouver du coté des ARM. Aussi ça permet plus facilement de faire jouer la concurrence.
=> Aussi, tu trouveras plus d'exemple de code et d'aide pour les ARM que pour PIC32
Re bonjour, Pardon pour le retard (c'est que les cours ça prend du temps).
Je m'interesse au PIC car je pensais que c'était plus répandu pour les petites applications je parle d'applications du type controler l'allumage de plusieurs leds enfin je crois. Pour la programmation de "pointe" l'arduino est tout a fait interessant bien que limitant dans une certaine mesure ...
En gros dans ma tête c'est PIC pas chère et efficace pour petites applications genre jouet interactif, horloge, réveil etc ... PIC=prog de masse
Pour de gros projets qui necessite de traiter beaucoup de données genre une imprimante quoique c'est même un peu limite peu être (je suis pas expert) ou plus simplement console portable interactive (ipod lecteur mp3 ...) donc pour ce genre d'applications ARM est le plus adapté Il me semble que c'est de l'arm qu'il y a dans la ds
Moi je veux plutot apprendre le plus polyvalent et moins cher (oui je sais on peut pas tout avoir). Donc le pic ayant une gamme larde de produit a des prix restreint j'y ai pensé naturellement ....
De plus les cartes toute faite moi ça me dit rien étant donné que je veux faire des montages définitifs autant avoir une seule carte qui a toutes les résistances et tout et tout ... donc le petit PIC qu'on integre dans un circuit moi ça me branche plus (dsl) enfin je me dit qu'industriellement on fait pareil .... dans une certaine mesure bien sur) cad On teste on fait un montage final sur un SEUL circuit imprimé.
Voila pourquoi PIC donc maintenant question ... Pourquoi PICkit 3 et pas 2 ? (c'est cher quand même) et ensuite starter kit ou debugger kit ?
Merci beaucoup pour les réponses et pardon pour les modos de rouvrir un vieu post
- Edité par Nicolas97220 13 février 2013 à 17:21:21
Le Cortex M, c'est sympa, mais l'architecture est quand même beaucoup plus complexe qu'un PIC. Pour commencer, chez Microchip, je partirais plutôt sur du 18F, 30F ou 33F. Oui, les processeurs 32 bits sont plus performants, mais ils sont aussi plus complexes, surtout les plus modernes. Le vieil ARM7 est bien plus simple à utiliser que l'ARM Cortex M qui lui succède, par exemple.
Bon, en plus, les 18F existent en boitier DIP, c'est plus facile à manipuler pour un néophyte qu'un QFP, QFN, voir BGA.
Bon ben là on va rentrer dans des questions existentielles : µControlleur 8bits ou 32bits ?
--------------
On utilise en général des µControlleur 8bits pour leur faible prix/encombrement/consommation et leur robustesse. Vu la faible quantité de mémoire que possède ce type de produit, il est souvent nécessaire de devoir passer par de l’assembleur afin d'optimiser le code : une bonne connaissance du hardware est donc nécessaire (l'architecture de ce genre de produit reste simple).
On peut quand même programmer en langage C les PIC18 (ce sont les plus gros PIC 8bits) car ils ont plus de mémoire. Par contre la mémoire est paginée ce qui pose des problèmes quand tu veux faire de gros tableau (mais c'est faisable).
Aussi l'avantage des µControlleur 8bits est qu'ils sont plus tolérants au parasites : on n'est pas obligé de les monter sur un PCB 4 couches+
=> il n'y a pas que Microchip qui fait ce type de produit (ex : ATMEL, Motorola, Zilog, ...) mais les PIC on l'avantage d’être très documentés sur le net (montage + programme)
---------------
Avec des µControlleur 32bits, l’architecture hardware est plus compliquée : ce n'est pas un problème quand on programme en C car en général il existe pour ce type de µControlleur des bibliothèques qui te permettent de faire abstraction du matériel (tu peux installer dessus un OS allégé : Free RTOS, ucLinux..).
=> plus simple à utiliser (moins besoin de connaissance en électronique mais plus besoin de connaissances en programmation)
=> beaucoup plus puissants
Les µControlleur 16 et 24 bits sont des µControlleurs intermédiaires entre le 8bits et le 32bits : je ne sais pas trop si de nos jour il y a encore des interets à les utiliser (quand on part de zéro)
--------
Aussi quand je parle de µControlleur 32bits, je parle de µControlleur avec RAM et ROM embarquée : il existe des µControlleur plus puissants avec la RAM/ROM a monter en externe et avec MMU (ex : ARM9) => là on se rapproche de l'architecture d'un PC (donc beaucoup plus de composants externes) => en général, c'est carrément un linux complet qui est dessus
---------
Donc c'est à toi de voir (à court et long terme) ce que tu veux faire.
Remarque : il y a beaucoup plus de µControlleur 8bits de vendu que de 32bits pour la simple raison qu'il en y a de partout (réveil, cafetière, ...)
Bon bah je vais peut être m'interesser à l'assembleur du coup, je tiens vraiment à faire l'économie des moyens dans la mesure du possible mais je réitère la question ....
Je veux utiliser les PICs pour de petites applications. En l'occurence mesurer une vitesse a partir d'un signal éléctrique et l'afficher sur un 4 digit. ça m'a pas l'air trop complexe donc PIC ou devrais je dire ucontroleur 8bit !
Pourquoi PICkit 3 et pas 2 ? (c'est cher quand même) et ensuite starter kit ou debugger kit ?
edit merci beaucoup beaucoup pour la réponse détaillé emcy
Le Pickit 2 est devenu obsolète. C'est à dire que tu ne pourra pas programmer les PIC les plus récents (A voir : cette page là, surtout le tableau à la fin).
Donc à toi de voir. Soit tu met 20€ de plus et tu pourra programmer toute sorte de PIC jusqu'aux plus récents(PIC32, dsPIC,etc...), soit tu prends un Pickit 2, et tu sera plutôt limiter au niveau du choix du PIC (mais si tu veux débuter, ça passe, mais je le redis, fais attention au PIC que tu choisis).
Je vois pas trop la différence entre le starter kit et le debugger kit mis à part la board de test qu'ils vont te filer, où le PIC ne sera pas le même. Pour moi l'important c'est d'avoir le Pickit et un PIC que tu relieras grâce aux pins ICSP.
Bon ben là on va rentrer dans des questions existentielles : µControlleur 8bits ou 32bits ?
--------------
On utilise en général des µControlleur 8bits pour leur faible prix/encombrement/consommation et leur robustesse. Vu la faible quantité de mémoire que possède ce type de produit, il est souvent nécessaire de devoir passer par de l’assembleur afin d'optimiser le code : une bonne connaissance du hardware est donc nécessaire (l'architecture de ce genre de produit reste simple).
On peut quand même programmer en langage C les PIC18 (ce sont les plus gros PIC 8bits) car ils ont plus de mémoire. Par contre la mémoire est paginée ce qui pose des problèmes quand tu veux faire de gros tableau (mais c'est faisable).
Aussi l'avantage des µControlleur 8bits est qu'ils sont plus tolérants au parasites : on n'est pas obligé de les monter sur un PCB 4 couches+
=> il n'y a pas que Microchip qui fait ce type de produit (ex : ATMEL, Motorola, Zilog, ...) mais les PIC on l'avantage d’être très documentés sur le net (montage + programme)
---------------
Avec des µControlleur 32bits, l’architecture hardware est plus compliquée : ce n'est pas un problème quand on programme en C car en général il existe pour ce type de µControlleur des bibliothèques qui te permettent de faire abstraction du matériel (tu peux installer dessus un OS allégé : Free RTOS, ucLinux..).
=> plus simple à utiliser (moins besoin de connaissance en électronique mais plus besoin de connaissances en programmation)
=> beaucoup plus puissants
Les µControlleur 16 et 24 bits sont des µControlleurs intermédiaires entre le 8bits et le 32bits : je ne sais pas trop si de nos jour il y a encore des interets à les utiliser (quand on part de zéro)
--------
Aussi quand je parle de µControlleur 32bits, je parle de µControlleur avec RAM et ROM embarquée : il existe des µControlleur plus puissants avec la RAM/ROM a monter en externe et avec MMU (ex : ARM9) => là on se rapproche de l'architecture d'un PC (donc beaucoup plus de composants externes) => en général, c'est carrément un linux complet qui est dessus
---------
Donc c'est à toi de voir (à court et long terme) ce que tu veux faire.
Remarque : il y a beaucoup plus de µControlleur 8bits de vendu que de 32bits pour la simple raison qu'il en y a de partout (réveil, cafetière, ...)
- Edité par emcy hier à 12:03
L'assembleur n'est quasiment plus utilisé même sur les µC 8 bits, les compilateurs C sont largement plus "optimisants" qu'un développeur lambda qui développerait en assembleur. Comme je le dit souvent au niveau de l'assembleur, les optimisations possibles qui sont difficiles à faire par un compilateurs ce sont des optimisations de haut niveau, qui sont souvent des optimisations de l'algorithme en lui même pour s'adapter aux spécificités de la plateforme.
Pour les optimisations basiques les compilateurs sont largement plus performants qu'un développeur. Néanmoins cela n'empêche pas d'intégrer des routines en assembleur dans son code C s'il y a besoin
La tolérance aux parasites n'a rien à voir avec l'architecture en soi. C'est juste qu'avec une architecture 8 bits, la mémoire est limitée de même que les applications possibles. Donc, par exemple avoir un processeur 8 bits à 500 MHz c'est un peu inutile (et peut-être infaisable, mais ce n'est pas mon domaine), en revanche les processeurs 32 bits permettent des applications beaucoup plus complexes et il y a souvent besoin de s'interfacer avec d'autres composants et ce avec des vitesses de transfert plus importantes.
Tu peux très bien monter un µC 32 bits CMS sur une carte mono ou double couche soudée à la main, si ton but c'est d'allumer des leds ou de faire de la PWM à 1 MHz aucun souci. Maintenant t'interfacer avec de la DDR là c'est une autre paire de manche, avec l'intégrité de signal qui entre en jeu.
Un µC 32 bits n'est pas forcément plus simple à utiliser. Tout dépend de ce que tu veux faire. Je prend l'exemple du DMA (Direct Memory Access) qui ne doit pas être implémenté sur les µC 8 bits mais qui peut l'être sur les µC 32bits, si tu programme le mécanisme logiciel du DMA à la main, ca n'a rien d'une chose simple. (Je l'ai fait sur un DSP)
Le mieux est de commencer avec des µC 8 ou 16 bits car les fonctionnalités internes sont réduites et cela permet de se familiariser avec l'architecture des µC, et surtout les bases que l'on retrouvera dans les µC 32 bits. Une fois que les principes de bases sont maitrisés, lorsque tu change de famille, marque, tu n'a plus qu'à lire rapidement la documentation sur ces parties et tu peux te focaliser sur les différences.
Si tu attaque les µC 32 bits avec du ARM et cie, tu va plus faire du développement logiciel (sur un linux embarqué si ca se trouve) et tu va en chier au niveau de la documentation, tu seras confronté à des docs de plusieurs milliers de pages et différents volumes (1 pour le hard, 1 pour le soft, des applications notes à foison, etc).
Merci beaucoup beaucoup pour les réponses ! ça fait vraiment plaisir d'avoir des informations de personnes expérimentées. Je pense que je vais donc acheter le Pickit 3 et finalement rester dans le C en suivant les quelques tuto présents sur le net.
Pour l'étude et les tests j'ai appris que Protheus faisait parfaitement l'affaire hormis le fait qu'il soit payant on peut tout a fait faire un montage interressant qu'on testera en reel après.
L'assembleur n'est quasiment plus utilisé même sur les µC 8 bits, les compilateurs C sont largement plus "optimisants" qu'un développeur lambda qui développerait en assembleur.
Personnellement, j'ai vraiment de gros doutes sur ce que tu dis : quand tu bosses sur des PIC10 ou de PIC12 où chaque octets est compté, je ne vois pas comment tu pourrais faire confiance à l'optimisation du compilateur.
Ex :
- si tu crées une variable gloable, le compilateur va te l'initialiser à 0 alors que ce n'est pas forcement nécessaire
- pour le passage des paramètres d'une fonction, une pile logicielle est automatiquement créée par le compilateur (ça fait de la RAM utilisée)
zeqL a écrit:
La tolérance aux parasites n'a rien à voir avec l'architecture en soi.
En fait je voulais parler de la gravure : les PIC 8 bits ont une techno plus ancienne (donc gravure moins fine) et ils sont donc plus tolèrent aux tension élevées (ex : un PIC32 ne peut pas être alimenté avec des tension supérieur a 3.3V). En plus sur toutes les I/O des PIC 8 bits, il y a des diodes de protection : je ne pense pas que ça soit le cas sur PIC32 (à confirmer)... => attention pour les PIC 8 bits dernière génération, ce n'est peut etre pas vrai...
Remarque : depuis que je suis passé sur µControlleur 32 bits, je n'ai vraiment plus envie de repasser sur du 8bits même si la puissance d'un 8bits suffit pour développer une application donnée (compilateur plus évolué, plus de problème de pagination mémoire, beaucoup plus de mémoire ce qui permet de pourvoir plus facilement créer des fonctions de debug)
L'optimisation du compilateur fait mieux que toi. Quand aux comportements que tu décris, ils dépendent du compilateur et de ses options de compilation, mais un appel de fonction passe forcément par une pile au delà d'un certain nombre de paramètres (cf le standard ABI correspondant).
Après, il faut aussi être un codeur C compétent, qui va savoir par exemple si un switch bien construit est plus pertinent que de la duplication de code (ou vice versa), ça implique de connaître son compilateur... Mais même dans des domaines de l'industrie à gros volume, faible coût, et consommation microscopique d'énergie on est sur du C maintenant.
L'assembleur n'est quasiment plus utilisé même sur les µC 8 bits, les compilateurs C sont largement plus "optimisants" qu'un développeur lambda qui développerait en assembleur.
Personnellement, j'ai vraiment de gros doutes sur ce que tu dis : quand tu bosses sur des PIC10 ou de PIC12 où chaque octets est compté, je ne vois pas comment tu pourrais faire confiance à l'optimisation du compilateur.
Ex :
- si tu crées une variable gloable, le compilateur va te l'initialiser à 0 alors que ce n'est pas forcement nécessaire
- pour le passage des paramètres d'une fonction, une pile logicielle est automatiquement créée par le compilateur (ça fait de la RAM utilisée)
zeqL a écrit:
La tolérance aux parasites n'a rien à voir avec l'architecture en soi.
En fait je voulais parler de la gravure : les PIC 8 bits ont une techno plus ancienne (donc gravure moins fine) et ils sont donc plus tolèrent aux tension élevées (ex : un PIC32 ne peut pas être alimenté avec des tension supérieur a 3.3V). En plus sur toutes les I/O des PIC 8 bits, il y a des diodes de protection : je ne pense pas que ça soit le cas sur PIC32 (à confirmer)... => attention pour les PIC 8 bits dernière génération, ce n'est peut etre pas vrai...
Remarque : depuis que je suis passé sur µControlleur 32 bits, je n'ai vraiment plus envie de repasser sur du 8bits même si la puissance d'un 8bits suffit pour développer une application donnée (compilateur plus évolué, plus de problème de pagination mémoire, beaucoup plus de mémoire ce qui permet de pourvoir plus facilement créer des fonctions de debug)
- Edité par emcy il y a environ 9 heures
Quand tu débute en programmation, je pense que le compilateur à pas mal d'avance sur toi niveau optimisation. Après plusieurs années d'expérience avec la même architecture, oui là tu peux commencer à t'interroger sur les optimisation du compilateur et faire des tests.
La variable globale non définie, c'est un mauvais exemple. Je travaille dans l'aéronautique et même si je fais de la conception carte j'ai pas mal de de notions sur la conception VHDL et un peu soft. Et déjà une variable non initialisée c'est un mauvais point puisque comme tu le dis le compilateur peut l'initialiser.
Ensuite que le compilateur l'initialise ou pas ca change rien du tout : si tu utilise ta variable, la place mémoire est occupée, si tu ne l'utilise pas dans ton code, qu'est-ce qu'elle vient faire dedans ?
Pour le peu de souvenir qu'il me reste normalement la pile se fait au niveau des registres et non au niveau de la RAM dans un premier temps. Et je pense que le compilateur ne gère pas tout au niveau de la pile, c'est aussi la partie processeur du µC qui s'en occupe, c'est en partie dynamique.
Oui la gravure est un facteur mais la suite de ton explication est mauvaise (mais pas forcément fausse).
Comme je l'ai dit dans mon commentaire précédent, une architecture 32 bits sera probablement utilisée avec des composants externes comme de la RAM, des contrôleurs haute vitesse, etc. Or à partir d'un certains débit on utilise des paires différentielles et des lignes adaptées (50/75 Ohms). Or un bus 32 bits qui aurait des lignes à 5V en TTL avec du 50 Ohms, la consommation serait intenable. Mais avec les signaux différentiels et en abaissant la tension d'alimentation on arrive à des consommation beaucoup plus raisonnables.
Sachant qu'un µC 8 bits n'a pas pour vocation à faire du traitement très rapides avec des composants externes comme de la RAM ou du gigabit ethernet, faire un design en 1.8V alors qu'il va s'interfacer avec des bus SPI ou CAN en 3.3V ou 5V c'est un peu ridicule.
Mais imaginons un µC 8 bits qui n'aurait qu'à faire un traitement haute vitesse à 500 MHz et interfacé en LVDS avec une puce externe avec une paire différentielle, bah dans ce cas il faudrait probablement un design en 1.8V ou 2.5V et il faudra probablement avoir un boitier QFN ou BGA car le DIP à 500MHz c'est pas vraiment le top.
Le problème dans ton raisonnement c'est que tu prend ce qui est actuellement fabriqué comme vérité absolue. Or ce n'est pas vrai, l'offre s'adapte à la demande, et je pense que le nombre de µC 8 bits à 500MHz que l'on pourrait vendre doit être extrêmement faible car à priori ils seraient fait pour des applications très spécifiques, et dans ce cas faire un ASIC ad-hoc est plus réaliste.
Concernant les diodes de protections (ou diodes de clamping) elles sont toujours présentes, il y a deux types d'architectures, mais en gros si t'en a pas tu flinguerais ton µC dès la moindre surtension ou courant un peu trop fort.
Je travaille actuellement sur une carte qui a un fonctionnement particulier : elle est alimentée en 15V puis en 3.3V. Il y a un microcontrolleur alimenté en 3.3V ainsi qu'une référence de tension de 3V (branchée sur une entrée du µC) alimentée en 15V. Le 15V étant allumé avant le 3.3V (qui est converti à partir du 15V), la référence de tension sort du 3V avant que le µC ne soit alimenté, mais grâce aux diode de clamping, le courant passe par ces diodes vers le 3.3V et notre brave référence de tension de 3V commence à alimenter le 3V3 via les diodes de clamping du µC (qui va ensuite faire démarrer le 3V3, 20 ms plus tard).
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !