Comme mon projet commence à se dessiner et que les premiers tests sont dans l'ensemble positifs, je partage mes débuts.
L'objectif est de créer une carte à deux microcontrolleurs 20Mhz, ceci pour deux raisons essentiels :
La première, utiliser des uC uniquement en format dip et pourvoyant le plus de sorties possibles. (Le candidat idéal fût donc l'ATmega644P).
La seconde, se rapprocher des automates modernes qui, de nos jours, possèdent une tâche rapide et une tâche à vitesse courante (ou lente).
La communication entre les deux uC est réalisée en utilisant une liaison I2C, les résistances de pull-up sont implantées sur la carte. Sur le prototype, j'ai également intégré un transceiver SN75176 pour les liaisons rs485.
La carte telle qu'elle est aujourd'hui, n'est pas exhaustive, il est tout à fait possible de doubler la liaison rs485 et pourquoi pas ajouter une autre liaison rs232. D'autres composants comme une horloge temps réelle ou une eeprom peuvent également trouver leur place.
Les dimensions du prototype sont : 136 x 98 mm. Elles seront certainement revues.
Il va sans dire que le prototype en cours est ma toute première version et qu'elle est loin d'être exempte de defauts. Je ne manquerais pas de faire une list bugs sur laquelle vous pouvez vous pencher et apporter vos recommandations ou critiques, elles seront les bienvenues.
Quelques images :
TODO :
Essai Bink simple ---> Ok.
Essai liaison I2C ---> Ok. (Blink Maitre/esclave)
Essai liaison RS485 ---> Ok. (Pilotage Carte relais Rs485 Maitre/esclave)
Essai Multimaitres ---> Ok. Ecriture sur une eeprom.
LIST BUGS :
20 Mhz inopérant
---> [RESOLU]
Update version Sanguino vers la 23r2
Modification fichier boards.txt
atmega644.name=Sanguino W/ ATmega644P 20Mhz
...
atmega644.build.f_cpu=20000000L
Switch vs ISP
---> [NON RESOLU]
Il n'est pas possible de programmer indépendamment les uC lorsqu'ils sont tout deux onboard.
Le switch coupe bien l'alimentation de l'un ou de l'autre.
Le bouton RST est opérationnel.
Ecart Pins sorties
---> [NON RESOLU]
Il manque un pas entre les connecteurs femelles.
Initialement, les connecteurs mâles devraient être bons.
Le choix technique n'est pas encore validé (vf shield).
Mon projet est inspiré par Core2duino, Core3duino, etc.
Sympa ce projet, ça peut donner quelque chose de bien performant si tu arrive a instaurer une méthode simple d'utilisation pour faire la distinction entre tache rapide et tache lente, beau début bon courage
C'est un langage mis au point dans les années 80 destiné au développement d'architectures massivement parallèle.
Le langage inclue nativement des notions telles que les exécutions en // ainsi que la communication entre tâches.
Il avait été essentiellement conçu pour s'adapter à un type de processeur (ou est-ce le contraire ?) qui s'appellait le Transputer et conçu par la société britanique Inmos (plus tard rachetée par Thomson ou SGS je sais plus mais çà a signé la mort du système).
Le Transputer était un des premiers processeurs à disposer de mémoire interne.
Mais l'originalité est qu'il implémentait de manière hardware les 2 notions d'Occam : parallélisme et communication.
L'environnement de développement te permettait de définit ton application par des tâches et ensuite de mapper ces tâches sut autant de processeurs que tu disposait. Le système savait que la tâche X devait communiquer avec la tâche Y et établissait de manière transparente le lien de communication point-à-point entre les tâches.
Tu pouvait développer ton algorithme avec 1 seul processeur et ensuite monter en puissance en connectant d'autres processeurs et ceci de manière pratiquement sans limite.
J'ai vu récemment que quelqu'un avait porté le langage Occam sur Arduino mais je ne sais pas si c'est avec la même capacité multiprocesseur. Voir : http://concurrency.cc/book/
@Barbudor
En ce qui concerne concurrency, il s'agit d'émuler du multithreading de la meilleure manière possible. Le langage utilisé pour ce faire est l'occam, qui ne semble pas trop difficile à appréhender, du moins dans les balbutiements
gerse:
Tu fais ca pour la beauté du geste ou tu as une idée précise d'application?
Oui et non XD
Sérieusement, je réchigne à souder des composants cms d'autant plus avec l'avénement des chips 32 bits (même si il existe des pics 32bits en format dip), je cherche donc à obtenir plus de souplesse et de puissance, la souplesse en nombres d'entrées/sorties et la puissance en terme de traitement parallèle des informations.
J'essaye de créer une carte qui me servira de standard. Pour la suite, je compte développer deux ou trois shields pour des applications plus précises telles que la domotique ou la robotique. Je prévois déjà un shield ethernet à base ENC28J60, un shield MEGA pour une interconnection des sondes plus aisée et un dernier dédié à la domotique (2 écrans LCD tactiles, ethernet, RS485, DS1307, boutons, etc).
J'avouerais que pour l'instant, j'ai une idée plutôt approximative sur la conception des shields.
Je sais déjà qu'il va me falloir reprendre quelques trucs en prévision de la v1.1
Disons pour simplifier que ma carte est équivalente à un ATmega1280 avec 1.2 fois plus de sortie et la possibilité de faire 2 fois plus de choses simultanément pour un prix réduit
Ok
là j'atteind les limites de mon incompétence, mais si c'est plus que pour le plaisir afin d'atteindre de la performance et du registre à bas pris regardes peut être la Pinguino qui semble richement dotée avec leur pic32MX en boitier DIP et qui travaille en environnement Arduino ...
Néanmoins, Skywood disait dans un post que l'environnement de programmation n’était pas très stable, mais ca devrait arrivé.
Ceci dit la communication inter process c'est pas toujours du gâteau quand on recherche la performance et la sécurité.
Gerse
gerse:
là j'atteind les limites de mon incompétence, mais si c'est plus que pour le plaisir afin d'atteindre de la performance et du registre à bas pris regardes peut être la Pinguino qui semble richement dotée avec leur pic32MX en boitier DIP et qui travaille en environnement Arduino ...
Pas en boitier DIP (enfin pas pour les cartes commerciale), si tu veut une pinguino avec PIC32MX220 en boitier DIP tu dois la fabriuer toit même
(J'essaye d'en faire une justement, j'ai les pic32 (merci artouste au passage ;)), les composants divers, reste plus qu'as trouver le temps pour faire le pcb ...)
gerse:
Néanmoins, Skywood disait dans un post que l'environnement de programmation n’était pas très stable, mais ca devrait arrivé.
C'est pas qu'il est pas stable, il est ... en constante évolution, on finit par s'habituer à devoir faire un svn update avant de lancer l'ide pinguino ...
Heu!!!...dites donc Mr Artouste, il me semble que vous pourvoyez souvent...et moi alors je suis trop rétrograde ]
Ouép! j'ai le même sentiment à propos de pinguino, c'est en constante évolution et dans sa plus jeune jeunesse. Cà grandit vite à cet age là et c'est pas toujours fiable.
Je serais quand même interessé de voir ce que donne ces fameux pic à 32 bits. Quoique je considère que 8 bits est humainement concevable (entendez gérable) alors qu'au delà...c'est l'abîme...
zoroastre:
Ouép! j'ai le même sentiment à propos de pinguino, c'est en constante évolution et dans sa plus jeune jeunesse. Cà grandit vite à cet age là et c'est pas toujours fiable.
Niveau fiabilité c'est pas le pire, il n'y a "que" une petite modif du core pinguino par semaine, par contre l'ide ça turbine, une màj par jour !
zoroastre:
Je serais quand même interessé de voir ce que donne ces fameux pic à 32 bits. Quoique je considère que 8 bits est humainement concevable (entendez gérable) alors qu'au delà...c'est l'abîme...
L'avantage des pic32 c'est surtout la taille de la ram et de la flash, et les périphériques qu'ils intégrent.
Aprés, 32bits c'est sympa pour des applications qui demande de la perf en calcul, mais sinon c'est comme un bon vieux µc 8 bits.
La conclusion est que les deux uC sont fonctionnels, que le port rs485 se pilote comme à mon souvenir, c'est dire parfaitement, et que l'i2c ne pose pas de problème particulier dans un configuration maitre/esclave ou même avec plusieurs maitres.
Mon dernier test :
Les deux ATmega644 ont eue la tâche d'écrire des données dans une eeprom i2c, le programme rigousement identique dans la trame et le timing, la duemilanove affichait en quasi temps réel les données enregistrées dans l'eeprom vers le moniteur.
Pour faciliter le debuggage et pour permettre la réussite du programme, j'ai offert 4 tentatives à chacun des 644.
Pour en finir avec le prototype ici présenté, je pensais initialement qu'en coupant l'alimentation des uC à travers un switch, j'aurais pû programmer soit l'un soit l'autre...que nenni, çà ne marche pas, et j'en conclurais même en disant que ce switch m'a apportait plus de problème que de solution. Dans certain de mes essais, je me suis rendu compte que le bus i2c freezé ou pire encore, le uC lui même (essentiellement celui à droite sur les premières images ou ici en bas).
A cause de ce problème, j'ai maintes fois dû debrocher/rebrocher mes uC et je commence à craindre un éffondrement des pinoches...Je vais donc retourner quelques temps à ma platine afin de confirmer mes doutes sur le sujet.
Je vais revoir mon choix également sur le régulateur LD1085 (Qu'est-ce que çà chauffe ces bêtes là)
zoroastre:
que le port rs485 se pilote comme à mon souvenir, c'est dire parfaitement, et que l'i2c ne pose pas de problème particulier dans un configuration maitre/esclave ou même avec plusieurs maitres.
Commentaire intéressant.
Il faudra que je t'en reparle à l'occasion....
Avant de reprendre en partie le projet, j'avais comme problème essentiel de pouvoir programmer indépendamment mes deux uC.
C'est donc un gros point noir que je viens de résoudre ce matin même : Il suffit en fait de couper la liaison SCK sur l'un ou l'autre des uC (logique en fait !!!).
Un simple cavalier officiera sur le prochain proto.
Afin d'economiser du materiel, je ferais les remarques suivantes : 1 seul oscillateur peut cadencer les 2 uC (voir post : 2 arduino + 1 oscillateur - #3 by zoroastre - Français - Arduino Forum ), 1 seul brochage ISP avec un cavalier 3 broches sur SCK (programmation indépendante des chip) et pour finir, 1 seul bouton reset commun (si besoin).
D'autres changements seront apportés dont essentiellement : alimentation indépendante du proto et connectiques pass-through pour empilage sur carte fille.
je suis avec intérêt ton projet
Je suis entrain de développer une version musclée de la mainboard xPLDuino avec l'aide de l'équipe. Je compte utiliser un atmega1284p pour cela.
Alors une question me vient: pourquoi un 644p alors que le 1284p offre de meilleur prestation pour un coût identique ?
Gromain59, j'avais deux 644p sous la main et ne sachant quoi en faire, l'idée m'est venu de les associer sur une seule carte. Voilà le pourquoi tout simplement
De plus, il faut prendre en compte le routage du typon, mon but est d'éliminer tout strap et de router le circuit sur une seule face (en essayant de respecter les règles conventionnelles). Ce n'est pas une tâche facile d'autant plus que je suis plutôt débutant aussi bien sur les cartes arduino que sur la partie électronique. Par chance, la communauté documente bien ses travaux et les circuits standalone sont disponibles à profusion.
J'ai testé le routage sur deux 328, brièvement, et pour l'instant je n'en suis pas satisfait. Peut être que j'essaierais sur la gamme des 1280 dip. En effet, il n'est pas toujours évident et j'ai fortement l'impression que les constructeurs de chips font tout pour nous compliquer le travail
Je disposerais de mes travaux complets dés validations finales et réceptions, dans l'idéal, en proposant une carte fille.
skizoh, Si tu m'en achètes 1000, çà peut s'arranger
Plus sérieusement, je n'ai pas l'intention de commercialiser ce qui reste à considérer comme un prototype ou une vulgaire experience de laboratoire.
Si le projet prend de l'envergure et apporte de véritables solutions à des problèmes de gestion domotique ou robotique, la disponibilté du typon sera gratuite et sans contrainte. Des graveurs professionnelles ou amateurs pourront à loisirs et pour quelques euros te faire le pcb.
Ce qui demeure à mes yeux interessant pour l'heure sont les considérations sur le quartz et la gestion du SCK pour ISP.
Nouveau proto (non finalisé) :
Les connectiques seront pass-through = stackable (encore 4 groupes à implanter).
Il manque le bornier d'alimentation (ou jack ou broches)
emplacement second quartz ou pas (+ cavalier entre les 2 CI) ?
Faut-il mettre l'impédance + condo pour l'ADC (vf datasheet) ?
Plan de masse ?
(Par rapport au proto précedent, j'ai donc supprimé la partie alimentation et je remets les éléments sur la carte fille : Cette version me semble beaucoup plus cohérente et modulable).
Il y a encore des ajustements à faire sur les espacements entre composants et je dois regarder aussi à ne pas trop surcharger de pistes sous les µC.
<mode : sérieux>
Soigne particulièrement le plan de masse et les découplages, surtout du coté analogique .
Un bon condensateur de découplage n'est pas obligatoirement celui qui à la plus forte valeur, un bon compromis est un condensateur chimique (ou tantale) de plusieurs µF qui peut être raisonnablement à quelque distance des accès à découpler et un condensateur céramique de 10nf ou 100nF plus petit mais câblé au plus court, l'idéal est de prendre des condos CMS en format 1206 ou 0805, 0603 c'est faisable mais il faut des bons yeux ou une bonne loupe.
Prévoit aussi des holes trous pour des reprises de masse près des connecteurs des E/S.
Cela manque sur les conceptions Arduino surtout pour les entrées analogiques, toujours elles.
Merci pour les conseils 68tjs, effectivement j'ai omis de parler des condos de découplage, je prends régulièrement une valeur de 100nF (1/CI).
Pour les connectiques, j'avais pensé un moment à disposer carrément des 3 broches principales, Pin + Gnd + Vcc, un peu comme sur les shields mega. C'est idéal pour connecter des sondes bien en face de l'entrée arduino.
Par contre, je n'avais pas songé à disposer uniquement de la masse et c'est une trés bonne idée que tu viens de me suggérer.
Ancien proto en bas, le nouveau plus concis en haut :
Les premiers tests sont bons : blink + com I2C.
Je n'ai pas encore sérigraphié de shield pour l'instant, suite à mes premiers dessin, je me suis rendu compte qu'en serrant trop les connectiques, il devenait difficile de placer des composants sur les cartes filles. J'ai donc écarté les connecteurs stackables afin de laisser un peu plus de place.
