FAQ: Suggestions et contributions

[monnoliv]

C'est ici que vous êtes invités à participer aux FAQ (Foires Aux Questions) en électronique.

[thm]

FAQ : Quelle différence y a-t-il entre un µC 8 bits RISC (PIC16) et un CISC (HC08)

Une structure interne complexe et … aussi très limitée

Voilà la structure interne d’un PIC récent (16F88) (image jointe)
On y constate déjà que l’adressage de la RAM se fait sur 9 bits, les 7 premiers venant du registre d’instruction et les deux derniers venant du registre « status » et donc « positionnant » les banques. C’est le petit (1) en exposant du « RAM Addr »
Donc, un pic aura comme maximum absolu de mémoire 2^9 soit 512 octets RAM. Ne cherchez donc pas un pic avec plus de mémoire, cela n’existe pas. De même pas question de trouver un PIC avec plus de 8k Mots de programme, l’adressage de cette zone se faisant sur 13 bits.
Enfin, il est amusant de constater les différentes « largeurs de bus » sur cette figure : 3,7,8,9,13,14 bits . mais 35 instructions seulement ? oui mais déjà 5 largeurs de bus. Chez Freescale (HC08), une donnée, c’est un octet et une adresse c’est deux octet. La mémoire s’adresse de manière linéaire sur tous les 64Ko. Des données peuvent être stockées en Flash ou en ram, des programmes peuvent être stockes et exécutés depuis la RAM ou la Flash. Des HC08 avec 32 ou 64 K de flash sont courants.

Un code « spaghetti », pas à la vitesse que l’on croit..

J’ai failli m’y faire prendre !
Entre un PIC16F à 20 Mhz qui exécute une instruction par cycle et un HC08 à 8Mhz dont chaque instruction prend 2 à 3 cycles, quel est le plus rapide ?? Le P.. évidemment ?
La réponse n’est pas ce que l’on croit, en effet : les 20Mhz du PIC sont à diviser par 4 pour avoir le temps de cycle d’une instruction. C’est cette valeur (5Mhz) qui est à comparer aux 8Mhz du Freescale où il est conventionnel de parler de fréquence donnant le temps de cycle. En effet, à quoi sert d’avoir une horloge à 100Mhz, si elle est divisée par 1000 ? Mais nous verrons également plus loin qu’une seule instruction Freescale exécute l’équivalent de 2 à 3 instructions PIC. Donc si une instruction CISC prend de 1 à 4-5 cycles à s’effectuer (3 en moyenne), elle est donc au minimum deux fois plus rapide du fait de la vitesse de la clock CPU.

Même pour l’horloge interne d’un PIC 16F628 qui est à 4Mhz, soit 1 Mhz « cycle » elle reste trois fois plus lente que celle d’ un 908 de base type QY4 ou QB8 avec une horloge interne de 3,2 Mhz.



Voici un petit exemple d’utilisation des « banques » : c’est la procédure d’initialisation du PORTC d’un PIC16F690 :

BCF STATUS,RP0 ;Bank 0
BCF STATUS,RP1 ;
CLRF PORTC ;Init PORTC
BSF STATUS,RP1 ;Bank 2
CLRF ANSEL ;digital I/O
BSF STATUS,RP0 ;Bank 1
BCF...

Donc, il est amusant de constater que sur six instructions, quatre de celles –ci ne servent à rein, si ce n’est à positionner la bonne « banque ».

En assembleur CISC Freescale, ce bout de code s’écrirait en deux lignes :
CLR PORTC
CLR ANSEL

Comparons donc les deux bouts de code du point de vue :

Occupation de la mémoire
PIC : 6x14 bits : 84 bits (soit plus de 10 octets)
MOT : 2x2 octets : 4 octets

Vitesse d’exécution
PIC : 6 cycles
Motorola :
3x3 cycles = 6 cycles

Donc ; en occupant deux fois moins de mémoire, à vitesse de bus égales, la durée serait identique, mais le Freescale est plus rapide » : Son bus, à 8MHZ,équivaudrait à une horloge PIC à 32 MHz….donc de fait deux fois plus rapide que les PIC 16F à 20Mhz.

Ceci confirme d’ailleurs ce qui est généralement constaté et admis (et démontré plus loin) , à savoir que pour une même application, le code PIC est en moyenne DEUX à TROIS fois plus long (et d’autant moins lisible), d’où son appellation « code spaghetti »
Donc, si une instruction CISC occupe en moyenne 2,5 octets .. la même chose en RISC fait aussi environ 2,5 à 3 mots de 14 bits soit au minimum 34 bits ou 4 octets d’ instructions. Occupation de la mémoire programme moindre pour faire la même chose en CISC…EN plus du fait que le PIC16F NE PEUT PAS adresser plus de 8K-mots (voir ci-après).

Les pages.

La structure de longueur fixe des instructions PICs 16 (14 bits) fait que, une fois que l’on retire les trois premiers pour le code instruction, il en reste … 11 pour l’adresse de l’instruction . 11bits .. ne permettrent pas d’adresser plus de 2K. Donc re-bellotte. Pour les Pics avec 8K instructions (le maximum, rappelons le), gros problèmes en perspective pour passer d’une page (de 2K) à une autre (de 2K). Mais microchip a trouvé une « astuce ». Il faut utiliser deux bits d’un registre appelé « PCLATH » Heureusement également , note ami Big… nous a préparé une macro de son goût. Ceci dit, outre le fait que trois instructions supplémentaires (encore de la place mémoire et du temps perdu) sont exécutées à chaque goto, n’est pas ce que l’on peut appeler d’une simplicité et d’une clarté exemplaires (pas pour moi en tous cas).


« Il n’y a que 35 instructions à apprendre » :
un peu d’assembleur CISC comparé au RISC (tiré d’une note microchip TB071)

Voici la manière d’activer les interruptions

CISC : CLI (Clear Interrupt Mask) ; RISC : BCF INTCON,GIE (Bit Clear File …etc.)????

Branchement conditionnel :

CISC : CBEQ Compare and Branch if Equal

En RISC PIC 16 :

SUBWF M,W
BTFSC STATUS,Z
GOTO addr 3 4

A condition que M soit dans la bonne “Banque », sinon, il faut rajouter 2 à 4 “BCF status ..”, “BSF status.. » pour se (re)positionner dans la bonne « banque »
Encore aussi de la mauvaise fois PIC, puisque l’instruction CBEQ ne modifie pas les opérandes, contrairement à la soustraction. Donc, si il fallait vraiment « simuler » un CBEQ, il faudrait une ou plusieurs instructions supplémentaire qui sauvegardent et remettent M à sa valeur initiale !!

D’autre part, l’instruction CBEQ possède un mode d’adressage indirect (indexé) avec post incrément, qui nécessiterait encore x instructions PIC si on voulait réellement le « simuler »

Quelque exemples qui parlent d’eux même :

DAA (Decimal ajust Accumulator, ajustement décimal) instruction d ‘un octet … n’existe pas en PIC 16 , la routine équivalente fait 9 instructions et s’exécute en 10 cycles.

Le « saut » JMP se « traduit(rait) » GOTO en assembleur RISC .. oui, sauf que le « goto ne permet de se déplacer que dans un espace de 2K ; contre 64K pour JMP.

SBC (substract with Carry) soustraction avec retenue s’écrit en RISC PIC 16 :

BTFSS STATUS,C
INCF M,F
SUBWF M,F

Pour terminer un peu de calcul :

Les instructions de multiplication : MUL (8bitsx8bits) et de division DIV (16/8 bits) natives dans les HC08 et qui s’exécutent respectivement en 5 et 7 cycles (sur un bus deux fois plus rapide) n’existent pas chez PIC 16F. Elles doivent être exécutées par des routines respectivement en 74 et 269 cycles.

* * * * * * * * * * * * * * * *

[HULK28]

salut,

j'ai cru comprendre dans de précedents échanges avec d'autres membres, que tu es plutôt fervent de la famille 68HCXX.
Ta contribution est louable puisque tu développes un argumentaire qui se tient même si tu as déjà choisi ton camp, ce qui en principe à tendance à défavoriser toute démonstration.
Je me permet d'intervenir car j'ai longtemps utilisé le 68HC11 et notament le 68HC711E9 ainsi que le 80C552 de chez Philips, pour aujourd'hui avoir opté pour la famille PIC18FXX et PIC16FXX entre autres.
Alors tu dois te dire "mais il est fou", comment abandonner de si beaux joujoux pour du RISC?
Eh bien, il faut te dire la chose suivante:

Lorsque Microchip a lancé sa famille de µC, il ont sortit gratuitement des outils de programmation, ils ont réfléchis à des applications low cost pour 1$ tu avais ton µC largement suffisant pour une petite appli et tu n'avais même pas d'outils nouveau à acheter.
Pendant ce temps là, les "gros" du µC pouvait abandonner d'un coup d'un seul tel ou tel produit sans préavis car de toute façon le marché du µC pour ces firmes répond avant tout à leur propre marché (téléphonie, machine à laver,etc).
Donc si demain la téléphonie draine la prod de µC et ben toi tu passes... en dernier, voir pas.
Tu trouves ça jouable quand toi tu comptes produire tes appareils pour faire tourner ta boutique?
Moi, non.
Alors que Microchip, ou ATMEL d'ailleurs, c'est leur fond de commerce, il ne font pratiquement que ça, et la cerise sur le gateau, c'est que eux au moins ils ont un site qui incite au respect, chose que n'ont pas les autres cités plus haut.
Alors pour le reste, c'est de la pipe, car si tu savais le nombre d'appli qui tourne dans le monde avec du PIC, et que tu compares les délais d'appros des uns et des autres, le choix est vite fait.
Pour ma part y a pas photo, même si je reconnais les ressources confortables des 68HCXX et 80C552.
De plus la famille PIC18F offre des ressources nettement supérieures avec compatibilité ascendante, souvent même brochage (PIC16F877 et PIC18F452 par exemple)
Donc d'un coté Goliath, les majors, avec leur lourdeur légendaire et leurs aléas flippants, de l'autre le petit (devenu grand et respecté) qui répond à un marché que les autres ont ignorés.
Voilà, je ne cherche pas la polémique, mais je te livre mon expérience d'utilisateur et de client.
amicalement.

HULK

[Gérard]

Motorola a encore frappé !

Je pense que je dois vraiment être nul puisque je reste PIC.
Je me console en me disant qu'il faut aussi des nuls pour faire un monde.

Bonne nuit à tous et que TOUS les µC vous portent conseils (même les HC !)
Gérard.

[thm]

Bonjour, HULK

Merci pour tes commentaires, avec lesquels je précise que je suis globalement d’accord. Mais il me semble un peu nécessaire de recadrer la petite analyse que j’ai faite plus haut ».

Je suis d’accord que microchip a été le premier à introduire des environnements gratuits et à avoir plus eu une politique tournée vers les amateurs. Mais c’était il y a dix ans, et il est probable que si j’avais commencé les µC à cette date, j’aurais choisi les PICs. Mais ctuellement, aussi bien Freescale que Atmel, … proposent des environnements gratuits (asm, debug, C,C++) et aussi des µC en « sample ». (jette un coup d‘oeil sur www.freescale.com , site que je trouve personnellement assez convivial).

J’ai comparé uniquement les PIC16 et les HC08. Je sais bien qu’il y a des pics 18,24,33,.. Et j’aurais pu aussi bien comparer les HCS08 (t cycle de 50 nsec) au PIC18 ou les HCS12 (80Mips) aux PIC24, mais ce n’était pas mon propos. D’ailleurs, existe-il un PIC 18 ou 24 à 8 pattes ? Non, mais il existe bien un HC08 et un HCS08 à 8 pattes (et à moins de 1USD en quantité).
De plus, si tu regardes la note MCP dont je me suis référencé pour la comparaison de l’assembleur, tu verras que l’assembleur PIC18 est beaucoup plus proche de celui du HC08, ce qui contribue à me faire penser que la structure des 16F est, actuellement, très loin d’être quelque chose d’idéal, mais plutôt (d'un peu ?) dépassé.
Quand à la disponibilité pour des productions en masse, je ne suis pas concerné, étant purement amateur. Je pense aussi que les micro 8 bits ont une place particulière. Un professionnel mentionnait récemment que dès qu’un besoin de calcul plus important était nécessaire, il était plus avantageux ($) de passer directement aux cœurs ARM plutôt qu’aux 8 bits de course ou aux 16 bits.
Ceci dit, je reconnais quand même un avantage indéniables aux PICS : il sont mieux distribués que les autres µC. Et Freescale (Motorola à l’époque) n’a pas particulièrement bien réussi le marketing de la succession de ses HC05 et HC11. Je crois aussi que beaucoup d’amateurs HC ne seraient jamais passés aux PICs si les HC08 avaient été disponibles et mieux promotionnés plus rapidement.

Voilà, donc, pour conclure, ma petite présentation était destinée à faire prendre conscience à l’amateur qu’il n’y a pas que les PICs comme µC et que leur suprématie en terme de facilité d’utilisation et de performance n’était pas si évidente que cela.

amicalement

th.

[monnoliv]

Bonjour,
Je comprends bien l'intérêt des uns et des autres pour "son" type de µP. Cependant il me semble intéressant, de même que pour tout le monde, de connaître de manière générale la différence entre un code RISC et CISC. Donc c'est bien de participer à la FAQ mais pas pour la guéguerre entre uP. D'autre part il y a une multitude de µC CISC et RISC 8bits:
Des CISC: Siemens SAB, Freescale HC, Atmel AT89, Silabs C8051, ...
Des RISC: Microchip PIC1X, Atmel AT90, ...
Et plein d'autres.
thm, pourrais-tu synthétiser la différence sans faire intervenir de marque ???
Merci,

[abracadabra75]

Bonjour.
Moi, quand je bricole mon électronique, c'est pas pour faire la guerre, je laisse ça aux chefs.....
Je ne fais que donner mon point de vue, sans polémiquer.
J' ai utilisé pendant longtemps le 68HC11 sous diverses formes, jusqu'au jour où voulant m'approvisionner, on m'a répondu 'Allez l' acheter chez Sasfépu'.
Oh que j' ai été content!
Mon beau compilateur, hop: à la poubelle, mes extension projetées: éjectées.J' ai alors un peu regardé le marché des µP, et j' en ai conclu que, dans l' état actuel des choses, les PICS semblaient les plus à même de répondre à mes modestes besoins, sans devoir s' arrêter du jour au lendemain (encore que, on ne sait rien de l' avenir)
Je n' ai pas cherché à calculer que ma boucle allait durer 39,436 µsecondes en plus (ou en moins). Sachant qu' un µP passe son temps à ..... attendre 98% du temps (et peut-être plus), à notre échelle quelques instructions en plus ou en moins n' ont aucune importance: qui parmi notre communauté doit travailler en temps réel?

Par contre, étant un farouche partisan de l'assembleur, je regrette les bonnes instructions type CISC, du 68HC11,et devoir sans cesse penser si je suis dans la bonne banque me gonfle tellement que je ne cherche pas trop à savoir où je suis, et d'un coup de macro je m'y place , même si j'y suis déjà...

Ce que je vois, c'est le but que je veux atteindre, peu m' importe le fabriquant de la puce que j' utilise, si elle me permet de réaliser rapidement mon montage. Je n'ai pas d' action de l' un ou l'autre, alors pour moi, Truc ou Machin, peu me chaut.

La meilleure pour moi, c'est celle avec laquelle avec j' atteins mon but le plus rapidement, et là je regrette les bons vieux 'Sasfépu'.

[thm]

Citation:

Posté par abracadabra75

La meilleure pour moi, c'est celle avec laquelle avec j' atteins mon but le plus rapidement, et là je regrette les bons vieux 'Sasfépu'.

Le Sasfépu a de beaux enfants :

68705 --> 68hc908
68HC11 --> MC9S12 (68HC12)

Thierry (www.68hc08.net )

PS: ton asm 68HC11 est 100% compatible 68hc12

[abracadabra75]

Merci du renseignement.
Mais comme l' a dit, il me semble que c'est Hulk28, (j'ai la paresse de vérifier, 1000 excuses si je me trompe), le fabriquant n' a fait aucune publicité pour son nouveau produit, ses compatibilités avec l'ancien. Sans doute, le monde amateur (dans le sens d'aimer...) ne pèse pas suffisamment lourd dans la balance économique pour qu' on le traite autrement que par le mépris. Alors....? hé bien, on renvoie l' ascenseur, et on adopte un matériel plus 'sérieux'.
Autre point: au moment de la disparition du 68HC11, aucun distributeur n' avait le remplaçant. Alors que doit faire le pauvre abandonné? attendre un remplaçant hypothétique? faut être serieux et ne pas prendre l' utilisateur que pour un ... (disons plutot cochon de payant!)
Bonne soudures!

Ps. le 100% compatible permet-il d'utiliser le même compilateur et les mêmes outils de débogage? (j'utilisais celui de Controlord)

J'ajouterai aussi que, pour moi, la question de la vitesse d'exécution est assez secondaire, car il suffit d' une mauvaise programmation pour bouffer le gain réalisé par le temps dexécution des instructions. Et quand on analyse certains programmes publiés ici ou là, je suis effaré de constater que les esprits tordus et compliqués fleurissent dans ce domaine...

[Patrick]

Salut

Moi, personnellement, je suis très content de MICROCHIP®. J'ai commandé sur leur site des PIC18F24j10 (1.14$) et un ICD2. L' ICD2 est arrivé en 2 jours par UPSExpress et les PIC, 2 jours après.

Plus haut on parle de l'environement gratuit de MICROCHIP mais je dois souligner un point : L'ICD2 coute 120$, si je le compare au MSP430 de chez TEXAS (µC très très répandu dans l'industrie européenne) ce dernier est mieux en terme de prix car il est l'un des micro les moins chère du marché, son débugger est gratuit ainsi que l'environement si on prend du libre. L'inconvéniant très difficile à trouver à l'unité la plus part du temps il faut en commander 1000.

Mais pour en revenir à la conversation personne ne peut dire si tel micro est mieux qu'un autre, il dépend de l'application que l'on souhaite développer. J'ai déjà developper sur :
68HC11
PIC16 et 18
MSP430
TINI® (basé sur un 80C400 et géré avec une JVM et le tout programmé en JAVA)

Pour moi une fois que l'on passe en langage évolué on arrive plus très bien à se rendre compte du micro le mieux mise à part les subtilitées hardware de tel ou tel micro (certains PIC possèdent des sorties pour piloter directement des afficheurs, d'autres MSP on une interruption sur chaqu'une de leurs entrées ...)

Cordialement
Pat

[HULK28]

Salut,

en fait le problème pour moi n'est pas de comparer des performances entre tel et tel µC, d'autant que les dits µC sont parfaitement ciblés par les fabricants qui répondent à un marché et non pas à nos petites personne.
Je pense que c'est plus en fonction des critères de coûts et d'approvisionnement qu'il faut juger la chose.
En plus comme dit Patrick, le langage évolué permet de s'affranchir de ces guerres de comptoir.

[chatelot16]

je suis bien d'accord sur le principe : l'assembleur c'est s'enfermer dans un type de micro precis le C c'est garder sa liberté , mais pratiquement , je vais bientot me mettre au pic : y a t il un compilateur C gratuit ? merci

sinon je risque de faire comme d'autre , de me tartiner l'assembleur , car il y a peut etre des compilateurs C libre pour les arm mais c'est trop gros pour ce qu'il me faut

[gienas]

Bonjour à tous

Ce fils, une FAQ, n'est pas seulement destiné à "parler" de µC et PIC, il peut servir à autre chose.

Par exemple, recueillir des liens intéressants, à classer, pour le déposer dans un autre épinglé fermé.

Voilà pour des explications, et la génèse du projet:

http://forums.futura-sciences.com/sh...#post1 437280

Thème 1

Sera rempli de liens au fur et à mesure des réponses.

Thème 2

Sera rempli de liens au fur et à mesure des réponses.


Thème 3

Sera rempli de liens au fur et à mesure des réponses.


Thème 4

Sera rempli de liens au fur et à mesure des réponses.


Thème 5

[DAUDET78]

Site d'explications pour l'examen radio amateur. Mais on y trouve des tas d'informations sur les composants numériques analogiques, calcul de redressement etc etc
http://pagesperso-orange.fr/f6crp/elec/index.htm
on tombe sur une page et on sélectionne, à droite, le sujet à regarder

[DAUDET78]

Le site incontournable pour tout ce qui est batterie en tout genre et chargeur: http://www.ni-cd.net/

[Toufinet]

J'ai trouvé récemment ce programme, choppé du site www.aurelienr.com :
http://www.aurelienr.com/electroniqu...lec/picdel.zip

C'est un programme qui génère le code ( assembleur ) pour créer une tempo de X ms , en fonction de la fréquence de l'horloge Y.
Mis à part ce logiciel fort utile, aurelienr propose pas mal de montages, à base de PIC principalement, et aussi quelques amplis audio avec un rapport qualité / prix plutôt bon.

[PA5CAL]

Bonjour

Citation:

Posté par mydarklife

on n'alimente RIEN avec du courant! Bon sang le courant est TOUJOURS demandé par la charge!

J’en ai moi aussi marre de voire des gens parler de générateur de courant. C’est vrai ! Le courant est dépendant de la charge. Et inévitablement de la tension un générateur de courant c’est théorique c’est pour expliquer un peu comment les choses fonctionnent. Une prise de courant 230V ne délivre pas une intensité, elle délivre une tension de 230V ! L’intensité est demandée par l’appareil que l’on raccorde.

Erreur. S'il est vrai que la plupart des appareils sont fabriqués de manière à être alimentés par une source de tension, la grande majorité des composants discrets peuvent (et parfois doivent) être alimentés par une source de courant.

Il s'agit bien d'une réalité technique, et pas seulement d'un concept à usage pédagogique. Dans ce cas, c'est le courant qu'on impose et la tension et la puissance absorbée qui résultent de la charge. Cette utilisation des composants est généralement rendue nécessaire à cause de caractéristiques conduisant à une grande variation du courant dans une faible plage de tension.

Ainsi, les LED, diodes, transistors bipolaires, condensateurs et batteries rechargeables (la liste n'est pas exhaustive) doivent impérativement être alimentés par un courant contrôlé (éventuellement par une source de tension et une résistance), sous peine de dysfonctionnement ou de destruction. Les portes logiques I2L, les liaisons RS422, les miroirs de courant, les sources de courant, les convertisseurs courant-courant sont autant de circuits qui fonctionnent également sur la base de courants, et non pas de tensions.

Citation:

Posté par mydarklife

Bon pour revenir à nos moutons on ne fournis pas 20mA à une led zut, c’est la LED qui consomme 20mA mais quand elle reçoit une tension à ces bornes de 3V ici dans l’exemple.

Donc dans notre cas le paramètre a vérifié est donc que la LED ne soit pas en présence dune tension supérieure à 3V.

Dans le cas présent on se doit de fournir 20mA à la LED. Je m'explique.

Pour un même modèle, la caractéristique tension-courant varie d'un composant à l'autre, et dépend également de la température.

Quand la datasheet indique une tension de 3,0V à 3,4V pour un courant de 20mA à 25°C (température jonction), cela signifie :
- que certaines de ces LED consommeront 20mA si on les alimente (peu de temps) sous 3,0V
- que d'autres d'autres consommeront 20mA si on les alimente (peu de temps) sous 3,4V
- que la majorité des LED ne consommeront 20mA que si on les alimente (peu de temps) sous une certaine tension qui sera comprise entre 3,0V et 3,4V

Mais cela signifie également :
- que la LED qui consomme 20mA sous 3,4V ne consomme que 8mA sous 3,0V et éclaire trois fois moins que prévu
- que la LED qui commençait à consommer 20mA sous 3,0V peut, en chauffant naturellement, finir par consommer 20mA sous 2,8V mais aussi 30mA sous 3,0V avec un risque de destruction
- qu'en alimentant un nombre important de ces LED sous 3,2V , certaines fonctionneront correctement, d'autres n'éclaireront que très peu, d'autres éclaireront très fort, et d'autres encore finiront par griller (instantanément, rapidement, ou à l'occasion d'une augmentation de la température ambiante ou d'une diminution de la ventilation).

Ce n'est pas une vue de l'esprit, mais un fait confirmé par l'expérience.