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
personnz ???
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+
Deux pic12, ça fait un pic24 ?
th.
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+
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
Et pourquoi pas un seul µ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
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 :Envoyé par SiNeRgY
- 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
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 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.
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.
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
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+
La réponse:
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).
Cela me rappelle le bon temps des transputeurs T805 ..... avec liaison interpuce ultra rapide .....
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)...
Je suis sceptique.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).
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+
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 ....
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.
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.
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.
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.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.
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+
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 ?
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 !!
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.
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
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
C'est ton projet. Si tes choix te semblaient judicieux, je les respecteNb: 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.
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.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.
A+
Ç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.
