choix d'un uC

[invitec35bc9ea]

bonjour,
sur quels criteres faut-il se baser pour choisir un PIC?
autrement dit comment savoir si un 16F me suffit ou si j'ai besoin d'utiliser un 18F?
merci
-----

[BastienBastien]

Bonjour,

Je ne suis pas un pro, mais déjà, il faut qu'il y ait les périphérique, autour du microprocesseur, dont tu as besoin. Par exemple, si tu as besoin d'un contrôleur CAN, de deux ports 8 bits, d'I2C et de SPI, et d'une ALU (ou UAL == Unité Arithmétique et Logique) qui a une vitesse de 4 MIPS, alors tu peux savoir lequel convient et lequel ne convient pas.

[invite5637435c]

Salut,

les PIC18F sont très semblables aux PIC16F, en tout cas la connaissance des 16F permet d'aborder les 18F sans encombres.
La différence majeure est la capacité en mémoires Flash, Ram et E²PROM, plus de timers, plus d'USART, plus de A/D, bref plus de tout.
Les 18F prennent le pas sur les 16F, ils permettent de bâtir des systèmes plus puissants tout en ayant des coûts très proches des 16F haut de gamme.

Les critères de choix sont comme le dit BastienBastien, liés aux ressources nécessaires et à l'évaluation des ressources mémoires utiles au soft.
La vitesse est aussi à prendre en compte parfois.
Pour ma part j'ai choisis plusieurs µC type, que j'utilise préférentiellement selon le degré de complexité du système à bâtir:

PIC12F615 pour les toutes petites applis pas chers.
PIC16F628A |
PIC16F872A | -> complexité faibles à moyennes
PIC16F877A |
PIC18F8722 pour des réalisations plus complexes
dsPIC30F3010 réalisations audio et traitements de filtrages numériques
@+

[BastienBastien]

Bonjour HULK,

Merci pour ces précisions.

Le cours numéro 1 de BigOnOff (que je viens de terminer) est très bien, il traite le 16F84+asm. Le cours numéro 2 traite du 16F877+asm et au tout début de ce cours, BigOnOff présente les différences entre le 16F84 et le 16F877. Il décrit également comment "porter" les programmes écrit sur le premier, vers le deuxième (registres en plus, etc).

Quant à la rapidité de calcul de l'UAL, exprimée en MIPS (Millions d'Instructions par Seconde), je me demande comment déterminer - connaissant le programme assembleur à réaliser -, sa vitesse minimale.

Car, lorsque le programme est écrit en assembleur, on peut compter le nombre de cylcles requis pour effectuer le traitement, mais il peut y avoir plusieurs interruptions qui engendrent une suspension du traitement du programme "normal". Que faire, pour s'assurer que le programme "normal" ait le temps de s'executer ? Prendre un coefficient de sécurité ? Un coeff de 2 semble énorme, pour la plupart de applications, non ?

Et lorsque le programme est écrit en C (sans routine critique en asm), comment évaluer la vitesse de traitement de l'UAL requise ? Car dans ce cas, y'a pas moyen de compter, à moins de se plonger dans les libs asm de l'IDE mais ce serait un boulot titanesque !

Je devine qu'on peut évaluer ça expérimentalement ou "au feeling", mais doit bien y avoir des méthodes/outils ?

Je viens d'avoir une idée, peut être qu'il existe des simulateurs de PIC qui déterminent la charge, en fonction du PIC indiqué, non ?

Merci à vous.

[A voir en vidéo sur Futura]

[invite5637435c]

Salut,

lorsque je veux savoir le temps d'une boucle ou connaitre la durée exacte d'un processus en C, je place un "espion" type led sur un port et je mesure au scope le temps entre 2 clignotements.
Je pratique comme ça pour vérifier beaucoup de choses, ne me servant du debugger uniquement pour vérifier des valeurs de pointeurs ou de registres internes.
Sinon j'utilise l'assembleur sur des fonctions vraiment critiques, puisque comme tu dis les temps de cycles sont bien plus lisibles qu'en C.
@+

[BastienBastien]

Bonsoir,

lorsque je veux savoir le temps d'une boucle ou connaitre la durée exacte d'un processus en C, je place un "espion" type led sur un port et je mesure au scope le temps entre 2 clignotements.

Merci du tuyau. C'est pourtant évident. J'aurO dû y penser.

puisque comme tu dis les temps de cycles sont bien plus lisibles qu'en C.

Pourquoi, c'est lisible ? Je sais pas s'il existe sur terre un mec assez courageux pour aller compter dans les libs C, dans les headers, dans toutes les autres libs utilisées et dans les sources du kernel (si elles sont fournies) pour remontrer jusqu'au code asm et évaluer le nombre de cycles pris par une fonction.

Si on voulaient compter en étant SUR du nombre de cycles que ça prend, il faudrait cross compiler, puis désasembler et compter, non ? Je suppose que ça fonctionne, mais c'est... fastidieux !

[invite5637435c]

Non il y a une méthode plus simple qui consiste à regarder le fichier asm généré par le compilateur, c'est le "disassembly listing" que tu trouveras en ouvrant une fenêtre "watch" sous MPLAB en mode debug.

[BastienBastien]

Bonjour,

Ok, merci beaucoup. Pour des applications importantes, ça doit être fastidieux.

Je suppose que parfois, on agit de manière plus expérimentale : on cadence le PIC à une allure qu'on juge moyenne, pour faire tourner l'application, tout en essayant de faire enclencher les interruptions bien plus que ça le serait en réalité (pour se mettre dans des cas défavorables) et puis on prend une marge de sécurité, c'est-à-dire qu'on prend une fréquence de quartz supérieure à celle avec laquelle on a pas de problème.

Einstein, es-tu satisfait des réponses ?

Merci les électroniciens.

[mat64]

Je suppose que parfois, on agit de manière plus expérimentale : on cadence le PIC à une allure qu'on juge moyenne, pour faire tourner l'application, tout en essayant de faire enclencher les interruptions bien plus que ça le serait en réalité (pour se mettre dans des cas défavorables) et puis on prend une marge de sécurité, c'est-à-dire qu'on prend une fréquence de quartz supérieure à celle avec laquelle on a pas de problème.

Personnellement, je fais un peu comme ça. J'essaye de faire une première évaluation pifométrique des fonctions les plus critiques (vraiment vite fait), histoire de tomber pas trop loin, et zou, un proto et j'applique la méthode que tu évoques

[invitec35bc9ea]

bonjour,
si je pose la question c'est qu'actuellement j'utilise un 16F877 et je commence à medemander qi celui ci sera capable de gerer toutes les foonctions que je lui implemente à savoir:
gerer en permanence les interruptions pour recevoir le signal de deux codeurs incrementaux.
commander grace à 8 bits deux moteurs PAP
recuperer 3 LONG dans une trame asci envoyée par RS232 sur le RX
faire des operation mathematiques sur ces LONG.

[invite5637435c]

Le 16F877 permet de pas mal travailler, j'ai une appli en RS485 qui tourne actuellement avec 4 cartes dont une fait de l'acquisition de données et des calculs sur des long int.
Il y a également la gestion des interruptions pour la RS485 entre autres.
Le µC est plein à 90% en ROM et 94% en RAM mais ça rentre.
Il est souvent possible de ruser un peu sur les calculs et éviter l'usage de certains long int.
Il faut aussi parfois réécrire certaines fonctions pour affiner, voir écrire certaines parties en assembleur...
Ca vaut le coup si économiquement il y a une réelle contrainte, sinon tu peux directement migrer en PIC18F, sans avoir à toucher grand chose au soft déjà écrit.

[BastienBastien]

Bonsoir,

HULK, petite question : selon le compilateur C, le code généré peut être plus ou moins gros. Est-ce que la différence est importante ? Ou est-ce que tous les compilos se valent tous ? Est-ce qu'avec certains compilos, on peut spécifier le genre d'optimisation que l'on souhaite ; un truc du genre :

--optimisation-en-taille-de-code
--optimisation-en-vitesse-d-execution
--optimisation-en-niveau-de-sous-programme

Et, petite autre question : si je comprends bien, tu as bouffé presque 8 ko de RAM en codant presque uniquement en C. As-tu eu besoin d'optimiser, pour atteindre cette empreinte mémoire ? Et est-ce que l'idée de code cette appli en asm t'a traversée l'esprit ? Je suppose que non, car quel boulot ça ferait !

Merchi.

[invitec35bc9ea]

bonsoir,

Ca vaut le coup si économiquement il y a une réelle contrainte, sinon tu peux directement migrer en PIC18F, sans avoir à toucher grand chose au soft déjà écrit.

c'est aussi mon avis, mais sachant que je ne travaille pas seul et donc ne decide pas seul, tout doit etre justifié. quels arguments mettre en avant pour justifier un passage au 18F?
merci

[invite5637435c]

Bonsoir,

HULK, petite question : selon le compilateur C, le code généré peut être plus ou moins gros. Est-ce que la différence est importante ? Ou est-ce que tous les compilos se valent tous ? Est-ce qu'avec certains compilos, on peut spécifier le genre d'optimisation que l'on souhaite ; un truc du genre :

--optimisation-en-taille-de-code
--optimisation-en-vitesse-d-execution
--optimisation-en-niveau-de-sous-programme

Et, petite autre question : si je comprends bien, tu as bouffé presque 8 ko de RAM en codant presque uniquement en C. As-tu eu besoin d'optimiser, pour atteindre cette empreinte mémoire ? Et est-ce que l'idée de code cette appli en asm t'a traversée l'esprit ? Je suppose que non, car quel boulot ça ferait !

Merchi.

Les compilo ne se valent pas tous, tant pour l'ergonomie (IDE) que pour le code généré.
Le résultat final n'est pas non plus du simple au double.
Certains compilateur haut de gamme proposent des optimisations qui consistent à privilégier certains types de traitements du précompilateur.
Pour ma part je ne travaille en asm que contraint, je préfère de loin le C que je trouve plus rapide pour répondre à un besoin professionnel.

[invite5637435c]

bonsoir,

c'est aussi mon avis, mais sachant que je ne travaille pas seul et donc ne decide pas seul, tout doit etre justifié. quels arguments mettre en avant pour justifier un passage au 18F?
merci

Les arguments peuvent varier selon les objectifs du projets à réaliser:

1/ les contraintes de temps liées à entrer le code au chausse pied peuvent être préjudiciable au temps (donc au budget global) alloué initialement.

2/ Le coût entre un PIC16F877A et un PIC18F4520 est en faveur du PIC18F4520 (-30%).

3/ La famille 18F évolue davantage que la famille 16F.

Il y en a surement d'autres qui vont dépendre des contraintes de ton projets que j'ignore.