Répondre à la discussion
Affichage des résultats 1 à 30 sur 30

Horloge commune µC



  1. #1
    thomasalbert1993

    Horloge commune µC


    ------

    Bonjour

    Quel est l'interêt d'utiliser un oscillateur à quartz commun pour plusieurs microcontroleurs ? j'utilise des ATMEGA8535, ce serait donc en mettant mon signal du quartz sur la pin OSC1 et laisser la pin OSC2 en l'air...

    à quoi cela sert d'utiliser la meme source d'horloge ?

    que veut il mieux faire ? horloge commune ou 1 quartz par µc ? est-ce que cela pourrait reduire le pourcentage derreurs dans des transmissions series ?

    merci

    Thomas

    -----

  2. #2
    thomasalbert1993

    Re : Horloge commune µC

    personnz ???

  3. #3
    Jack
    Modérateur

    Re : Horloge commune µC

    L'avantage est qu'utiliser un oscillateur au lieu de deux coûte deux fois moins cher et prend deux fois moins de place.

    Maintenant, il ne doit pas être fréquent d'utiliser 2 µC sur la même carte. Autant en prendre un plus "gros".

    A+

  4. #4
    invite76a

    Re : Horloge commune µC

    Deux pic12, ça fait un pic24 ?

    th.

  5. A voir en vidéo sur Futura
  6. #5
    lil-vince

    Re : Horloge commune µC

    J´allais dire comme Jack, ca coute moins cher (déjà une bonne raison) et effectivement sa doit être plus simple pour de la liaison synchrone...
    A+

  7. #6
    thomasalbert1993

    Re : Horloge commune µC

    en fait j'ai pas 2 mais 4 ou 5 microcontroleurs lool
    ppur un projet qui sera surement commercialiser au prix de 1000 € environ... pur les artificiers ^^
    tous en liaison serie UART

  8. #7
    Jack
    Modérateur

    Re : Horloge commune µC

    Et pourquoi pas un seul µC?

  9. #8
    thomasalbert1993

    Re : Horloge commune µC

    tout d'abord je dois bien avoir une bonne centaine d'entrée sorties à utiliser. Ensuite, dix d'entre elles doivent etre des interruptions, et je dois pouvoir effectuer 4 ou 5 choses à la fois... D'où les 4 ou 5 µc

  10. #9
    SiNeRgY

    Re : Horloge commune µC

    Bonsoir
    IL existe des OS pour des application MULTI-TACHES pour les PIC 18F, je n'ai jamais essayé mais je me suis interessé un moment, je te donne un très bon lien http://www.picos18.com/.
    Bon courage

  11. #10
    invite76a

    Re : Horloge commune µC

    Citation Envoyé par SiNeRgY Voir le message
    Bonsoir
    IL existe des OS pour des application MULTI-TACHES pour les PIC 18F, je n'ai jamais essayé mais je me suis interessé un moment, je te donne un très bon lien http://www.picos18.com/.
    Bon courage
    Mais quelle ânerie :
    - tu parles de pic 18F, alors que le sujet porte sur les atmel
    - tu n'as pas essayé, et tu ne sais pas ce que c'est ; qu'est ce que tu peux en dire ??

    Je souscris compètement à la réponse de Jack.

    thierry

  12. #11
    thomasalbert1993

    Re : Horloge commune µC

    merci pou vos reponses et effectivement je travaille sur des atmel et non des pics... J'ai vu qu'avec un Quartz de 16MHz le tau. D'erreur a luart est de 3,5% pour du 115kbauds ce qui est énorme pour mon système qui se dit trés sécurisé ! Pensez vous qu'avec un quarts commun cela réduirait ce taux puisque les micro serait plus synchrones ??

  13. #12
    SiNeRgY

    Re : Horloge commune µC

    Citation Envoyé par thm Voir le message
    Mais quelle ânerie :
    - tu parles de pic 18F, alors que le sujet porte sur les atmel
    - tu n'as pas essayé, et tu ne sais pas ce que c'est ; qu'est ce que tu peux en dire ??

    Je souscris compètement à la réponse de Jack.

    thierry
    Ce que je disais était la suite des phrases "je dois effectuer 4 ou 5 taches a la fois ", "et pourquoi pas un µC ?".
    C'est vrai que ca parle de ATMEL et pas de PIC, mais un µC est un µC !!!
    Même si je n'ai pas essayé, quece que ca coute de voir ce lien.

  14. #13
    DAUDET78

    Re : Horloge commune µC

    Citation Envoyé par thomasalbert1993 Voir le message
    J'ai vu qu'avec un Quartz de 16MHz le tau. D'erreur a luart est de 3,5% pour du 115kbauds ce qui est énorme pour mon système qui se dit trés sécurisé !
    D'où tu sorts cette affirmation? A ce taux là, il n'y aurait plus de liaison série asynchrone!
    Ce n'est pas plutôt, ces 3,5%, l'erreur d'horloge ? et ça, c'est tout à fait plausible sachant qu'une liaison asynchrone admet, de mémoire, 5% d'écart sur l'horloge sans erreur de data.
    J'aime pas le Grec

  15. #14
    invite76a

    Re : Horloge commune µC

    Citation Envoyé par thomasalbert1993 Voir le message
    merci pou vos reponses et effectivement je travaille sur des atmel et non des pics... J'ai vu qu'avec un Quartz de 16MHz le tau. D'erreur a luart est de 3,5% pour du 115kbauds ce qui est énorme pour mon système qui se dit trés sécurisé ! Pensez vous qu'avec un quarts commun cela réduirait ce taux puisque les micro serait plus synchrones ??
    Ce genre d'erreur peut résulter de différences dans les fréquences d'oscillateur internes, et donc un horloge commune, ou un quartz à chaque µC l'évitera. Une autre manière d'éviter ce genre d'erreur de communications est d'utiliser le SPI ou I2C à la place de liaisons asynchrones.


    thierry
    Dernière modification par invite76a ; 09/02/2008 à 08h30.

  16. #15
    Jack
    Modérateur

    Re : Horloge commune µC

    Je ne comprends toujours pas pourquoi tu t'obstines à utiliser plusieurs µC. Le problème de transmission serait automatiquement résolu.

    Sinon, thm a raison: SPI et I2C sont des liaison synchrones, dont plus de problème. Et les vitesses de transmissions peuvent monter bien au delà des 115200 bits/s.

    A+

  17. #16
    PA5CAL

    Re : Horloge commune µC

    Citation Envoyé par Jack Voir le message
    Je ne comprends toujours pas pourquoi tu t'obstines à utiliser plusieurs µC.
    La réponse:
    Citation Envoyé par thomasalbert1993 Voir le message
    tout d'abord je dois bien avoir une bonne centaine d'entrée sorties à utiliser. Ensuite, dix d'entre elles doivent etre des interruptions, et je dois pouvoir effectuer 4 ou 5 choses à la fois...
    La vitesse de réaction et la puissance de calcul des microcontrôleurs ne sont pas infinies. Quand les modèles les plus puissants et les plus rapides de la gamme ne suffisent plus, il faut bien passer à la parallélisation de plusieurs unités.

    De plus, si le design du système est correctement réalisé, les performances de 4 ou 5 microcontrôleurs séparées peuvent être bien meilleures que celles d'un seul microcontrôleur 4 ou 5 fois plus rapide. C'est d'autant plus vrai qaund chacun s'occupe d'un processus indépendent. La latence due au traitement d'interruptions plus prioritaires est minimisée ; on s'affranchit des opérations de changement de contexte ; avec des communications de flux de données traitées matériellement, on s'affranchit des tâches d'ordonnancement ; etc. .

    On peut aussi s'autoriser à utiliser des microcontrôleurs différents, adaptés au maximum à chacun des process à réaliser.

    Si le système s'y prête bien, on peut même y gagner d'un point du vue coût (coût de développement et prix des composants).
    Dernière modification par PA5CAL ; 09/02/2008 à 09h55.

  18. #17
    DAUDET78

    Re : Horloge commune µC

    Cela me rappelle le bon temps des transputeurs T805 ..... avec liaison interpuce ultra rapide .....
    J'aime pas le Grec

  19. #18
    thomasalbert1993

    Re : Horloge commune µC

    c'est vrai qu'il serait plus judicieux d'utiliser du i²C ou SPI, mais c'est un peu moins pratique à mettre en oeuvre je trouve... Mais je vais tout de même y réfléchir... En fait le truc cest que chaque µc puisse communiquer avec chaque autre.

    et pour les 4 ou 5 µc, PA5CAL a bien compris !! en fait j'ai plusieurs modules (un module gérant un afficheur LCD couleur, un autre gerant la communication USB, DMX, et lecteur compact flash, un autre gerant des boutons poussoirs, et un autre s'occupant d'afficheurs 7 seg...) chaque processeur a son programme, et lorsque c'est nécessaire, on envoie une trame UART au µC de la carte mère, qui traitera les données et renverra une reponse si necedssaire)...

  20. #19
    Jack
    Modérateur

    Re : Horloge commune µC

    Si le système s'y prête bien, on peut même y gagner d'un point du vue coût (coût de développement et prix des composants).
    Je suis sceptique.

    Tu connais beaucoup d'exemples d'utilisation de plusieurs µC d'usage général ?

    Maintenant, en tant qu'amateur, si ça peut simplifier la tâche ...

    Là encore, j'ai un doute: il va falloir ajouter tous les problèmes de communication. Avec 5 µC, pas question de SPI ou de transmission asynchrone. Il faut un bus, l'I2C par exemple: bon courage. Alors qu'avec un seul µC, tous est accessible en mémoire.

    A+

  21. #20
    DAUDET78

    Re : Horloge commune µC

    Je rejoins Jack sur ce point. Avec une carte PC104, on a tous les drivers qu'il faut, les contrôleurs écrans, la RAM en pagaille, la Flash pour le programme et le µP x86 qui déborde de puissance ..... sans compter l'O.S. multi tache si besoin ....
    J'aime pas le Grec

  22. #21
    DavidDB

    Re : Horloge commune µC

    Citation Envoyé par Jack Voir le message
    Là encore, j'ai un doute: il va falloir ajouter tous les problèmes de communication. Avec 5 µC, pas question de SPI ou de transmission asynchrone. Il faut un bus, l'I2C par exemple: bon courage.
    A+
    Ou un simple petit µC avec interface CAN, comme cela, il n'y aura plus que la carte mère qui écoute le bus, et au besoin, les cartes annexes pourront intercepter les trames qui les concernent...

    Mais bon, pour gérer USB, DMX, LCD, afficheur 7segments: un µC doit suffire.
    Donc, en comptant la carte mère c'est maximum 3µC, voir deux...

    David.

  23. #22
    PA5CAL

    Re : Horloge commune µC

    Citation Envoyé par Jack Voir le message
    Tu connais beaucoup d'exemples d'utilisation de plusieurs µC d'usage général ?
    C'était le cas dans une sur trois de mes réalisations professionnelles, environ.

    Dans le domaine industriel et militaire, la segmentation de l'application en plusieurs sous-systèmes physiquement indépendants offre des garanties quant à la sécurité et aux performances minimales de ces sous-systèmes.

    En limitant au maximum leur interdépendance, on réduit la complexité et les besoins en resources de ces sous-systèmes.

    Le besoin en composants moins puissants autorise alors le recours à des modèles standards éprouvés et ayant de nombreuses secondes sources, gage d'un meilleure pérennité pour le produit.

    Le développement s'en trouve également facilité. Les contraintes imposées sur chaque sous-système sont allégées, et puis on peut très naturellement faire travailler plusieurs équipes indépendantes en parallèle sur le projet.


    Citation Envoyé par Jack Voir le message
    Maintenant, en tant qu'amateur, si ça peut simplifier la tâche ...

    Là encore, j'ai un doute: il va falloir ajouter tous les problèmes de communication. Avec 5 µC, pas question de SPI ou de transmission asynchrone. Il faut un bus, l'I2C par exemple: bon courage. Alors qu'avec un seul µC, tous est accessible en mémoire.
    Choisir un environnement multi-processeurs ne fait que changer la nature du problème de communication inter-process.

    Ce n'est pas parce qu'une information ne transite que par la mémoire que cela est forcément plus simple. C'est parfois tout le contraire, car cela oblige à réaliser logiciellement la synchronisation des différents process, et cela coûte en ressources supplémentaires et complique énormément le design pour arriver à garantir la performance (vitesse, latence) du système global.

    Selon le débit requis, les échanges peuvent être réalisés via SPI ou I2C, mais également en direct (protocole minimal, garanti par les spécifications temporelles ou sur interruption) ou via une mémoire FIFO.

    Passer à un environnement multi-processeurs peut même finalement représenter une simplification.

  24. #23
    Jack
    Modérateur

    Re : Horloge commune µC

    Dans le domaine industriel et militaire, la segmentation de l'application en plusieurs sous-systèmes physiquement indépendants offre des garanties quant à la sécurité et aux performances minimales de ces sous-systèmes.
    Bien sur. Mais si tu reprends la fil depuis le départ, tu comprendras qu'on ne parle plus de la même chose: thomasalbert1993 veut mettre tous ses µC sur la même carte puisqu'il veut partager l'horloge.

    J'en profile d'ailleurs pour préciser qu'une horloge commune n'améliorera en rien la synchronisation lors d'un échange de donnée: l'horloge de transmission étant souvent obtenue par division de l'horloge CPU, rien ne garantit que les horloges d'émission et de réception soient en phase.

    A+

  25. #24
    thomasalbert1993

    Re : Horloge commune µC

    excusez moi mais le nbut du tpoic est d'expliquer le but du quartz commun :S là on s'éloigne vachement !!

    pour l'UART entre les µc, je comptais mettre des portes OU à quatre entrées dont les sorties seraient reliées à RXD de chaque µc, et lres entrées au TXD de chaque µc. Donc chaque micro peutr communiquer ac tous les autres...

    apres entre le SPI, I²C, et UART, je sais pas trop quoi prendre... Mais SPI et I²C cest un peu pareil non ?

  26. #25
    thomasalbert1993

    Re : Horloge commune µC

    Ah Jack a été plus rapide que moi

    ok pour l'horloge commune et la synchro

    aussi je compte utiliser des ATMEGA8535 !!! pas autre chose !!

  27. #26
    PA5CAL

    Re : Horloge commune µC

    Si l'horloge commune ne garantit pas forcément la phase des horloges de communications (quoiqu'on puisse le faire facilement, mais ça n'a pas forcément d'intérêt), elle garantit en revanche l'absence de glissement (la même phase est maintenue pendant toute la durée de fonctionnement) et d'erreurs de transmission qui en résultent.

    Nb: dans mes réalisations, toutes les unités étaient montées sur la même carte et partageaient la même horloge, pour la raison évoquée dans la phrase précédente. Tout ce que j'ai dit reste valable pour le projet de thomasalbert1993.
    Dernière modification par PA5CAL ; 09/02/2008 à 13h38.

  28. #27
    invite76a

    Re : Horloge commune µC

    Bonjour

    Ayant regardé la datasheet de l'atmega8535, celui ci ne possède pas d'interface I2C, donc le SPI est plus adapté, mais il faudra prévoir des pins de sorties CS (Chip Select) autant qu'il y a d'esclaves.
    Je mentionne aussi un petit RTOS gratuit (que j'ai testé) pour les avr : http://helium.sourceforge.net

    thierry

  29. #28
    thomasalbert1993

    Re : Horloge commune µC

    ok

    question qui n'a rien a voir mais qui reste tout de meme dans mon projet :

    connaissez vous un controleur pour ecran LCD 320 * 240pix 6 bits par couleur (262 144 couleurs donc) que je puisse facilement interfacer avec un atmega ? ou alors dois-je le réaliser moi meme ?

    http://www.farnell.com/datasheets/71533.pdf : voici l'afficheur en question

  30. #29
    Jack
    Modérateur

    Re : Horloge commune µC

    Nb: dans mes réalisations, toutes les unités étaient montées sur la même carte et partageaient la même horloge, pour la raison évoquée dans la phrase précédente.
    C'est ton projet. Si tes choix te semblaient judicieux, je les respecte

    Si l'horloge commune ne garantit pas forcément la phase des horloges de communications (quoiqu'on puisse le faire facilement, mais ça n'a pas forcément d'intérêt), elle garantit en revanche l'absence de glissement (la même phase est maintenue pendant toute la durée de fonctionnement) et d'erreurs de transmission qui en résultent.
    Si de chaque côté, les horloges de transmissions sont générées à partir de quartz de fréquences identiques, le glissement ne sera pas suffisant pour entraîner une perte de synchro, surtout sur une dizaine de bits.

    A+

  31. #30
    PA5CAL

    Re : Horloge commune µC

    Citation Envoyé par Jack Voir le message
    Si de chaque côté, les horloges de transmissions sont générées à partir de quartz de fréquences identiques, le glissement ne sera pas suffisant pour entraîner une perte de synchro, surtout sur une dizaine de bits.
    Ça c'est vrai pour I2C et SPI, par exemple. Mais en éliminant les glissements, on peut également envisager des communications directes par les ports d'E/S, plus rapides, avec plusieurs milliers de bits par trame, voire, pour les systèmes les plus simples, un flux continu de données sans élément de synchronisation une fois passée la phase d'initialisation. Une horloge unique offre ces quelques possibilités supplémentaires. Ça n'a rien d'obligatoire, mais c'est parfois bien utile.


    De toute manière, si dans le cas de thomasalbert1993 les 4 ou 5 microcontrôleurs sont proches, partagent la même alimentation et travaillent à la même fréquence, comme tu l'as indiqué dans ta première réponse, l'utilisation d'une horloge unique est finalement moins compliquée et moins chère, et je ne vois pas pourquoi on s'en priverait.

Discussions similaires

  1. impulsion salvatrice commune
    Par Trainskill dans le forum Epistémologie et Logique (archives)
    Réponses: 0
    Dernier message: 28/05/2007, 14h41
  2. Problème masse commune
    Par minuscheri dans le forum Électronique
    Réponses: 4
    Dernier message: 21/03/2007, 18h48
  3. Problème de masse commune..
    Par Leen dans le forum Électronique
    Réponses: 28
    Dernier message: 12/11/2006, 22h20
  4. Horloge lumineuse, horloge mecanique et Einstein
    Par pidofra dans le forum Physique
    Réponses: 6
    Dernier message: 22/03/2006, 15h21
  5. Ma commune a-t-elle le droit ?
    Par yoyo36 dans le forum Environnement, développement durable et écologie
    Réponses: 5
    Dernier message: 13/07/2005, 11h11
Découvrez nos comparatifs produits sur l'informatique et les technologies.