choix d'un uC
Répondre à la discussion
Affichage des résultats 1 à 15 sur 15

choix d'un uC



  1. #1
    ABN84

    choix d'un uC


    ------

    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

    -----
    "Engineering is the art of making what you want from what you get"

  2. #2
    BastienBastien
    Invité

    Re : choix d'un uC

    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.

  3. #3
    invite03481543

    Re : choix d'un uC

    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
    @+

  4. #4
    BastienBastien
    Invité

    Re : choix d'un uC

    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.

  5. A voir en vidéo sur Futura
  6. #5
    invite03481543

    Re : choix d'un uC

    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.
    @+

  7. #6
    BastienBastien
    Invité

    Re : choix d'un uC

    Bonsoir,

    Citation Envoyé par HULK28 Voir le message
    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.

    Citation Envoyé par HULK28 Voir le message
    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 !

  8. #7
    invite03481543

    Re : choix d'un uC

    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.

  9. #8
    BastienBastien
    Invité

    Re : choix d'un uC

    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.

  10. #9
    mat64

    Re : choix d'un uC

    Citation Envoyé par BastienBastien Voir le message
    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

  11. #10
    ABN84

    Re : choix d'un uC

    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.
    "Engineering is the art of making what you want from what you get"

  12. #11
    invite03481543

    Re : choix d'un uC

    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.

  13. #12
    BastienBastien
    Invité

    Re : choix d'un uC

    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.

  14. #13
    ABN84

    Re : choix d'un uC

    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
    "Engineering is the art of making what you want from what you get"

  15. #14
    invite03481543

    Re : choix d'un uC

    Citation Envoyé par BastienBastien Voir le message
    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.

  16. #15
    invite03481543

    Re : choix d'un uC

    Citation Envoyé par einstein Voir le message
    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.

Discussions similaires

  1. Réponses: 1
    Dernier message: 16/02/2008, 21h59
  2. Choix d'un µC
    Par invite5d1bc976 dans le forum Électronique
    Réponses: 1
    Dernier message: 14/05/2007, 22h47
  3. Choix d'un 80 ED
    Par invited293830e dans le forum Matériel astronomique et photos d'amateurs
    Réponses: 2
    Dernier message: 12/02/2007, 14h38
  4. choix d'un PC
    Par invite54ac07b6 dans le forum Matériel - Hardware
    Réponses: 8
    Dernier message: 15/11/2006, 19h56
  5. choix d'un CAN
    Par invite73b31da2 dans le forum Électronique
    Réponses: 1
    Dernier message: 22/02/2005, 17h54
Découvrez nos comparatifs produits sur l'informatique et les technologies.