Go Down

Topic: [Projet] Bi-ATmega644 (Read 9635 times) previous topic - next topic

zoroastre

May 07, 2012, 10:09 am Last Edit: May 08, 2012, 08:56 pm by zoroastre Reason: 1
Yep!

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.

EDIT1 : Ajout du schematic en fichier joint.

@+

Zoroastre
Gné! ;)

skizoh

Bonjour,

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 :)

Skizo !

barbudor

Je sais pas si tu connais Occam ?

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/

zoroastre

Yep!

Merci pour ces infos Barbudor ;)

Je dois effectivement en avoir déjà entendu parler puisque j'ai quelque part dans mon pc un fichier qui porte ce nom...occam-pi pour être exact.

Je m'en vais de ce pas à la chasse aux informations ;)

@+

Zoroastre.
Gné! ;)

gerse

Salut Zoroastre

Tu fais ca pour la beauté du geste ou tu as une idée précise d'application?

Gerse

zoroastre

#5
May 07, 2012, 03:41 pm Last Edit: May 07, 2012, 03:55 pm by zoroastre Reason: 1
Yep!

@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  :smiley-mr-green:

Quote from: 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 ;)

@+

Zoroastre.
Gné! ;)

gerse

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

skywodd

Salut,

Sympa comme projet ^^


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 ...)


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 ...
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

zoroastre

Yep!

Quote from: skywodd
merci artouste au passage

Heu!!!...dites donc Mr Artouste, il me semble que vous pourvoyez souvent...et moi alors je suis trop rétrograde ]:D

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.
Gné! ;)

skywodd


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 !


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.
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

zoroastre

#10
May 08, 2012, 08:52 pm Last Edit: May 08, 2012, 08:54 pm by zoroastre Reason: 1
Yep!

Voilà, j'ai terminé mes premiers essais.

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.
Gné! ;)

skizoh

et béh, pour un montage si gros je le trouve bien propre ^^ bravo =) et courage pour ton problème de switch ^^

Skizo !

barbudor


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

zoroastre

#13
Jun 03, 2012, 12:18 pm Last Edit: Jun 03, 2012, 02:20 pm by zoroastre Reason: 1
Yep!

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 : http://arduino.cc/forum/index.php/topic,106012.msg796112.html#msg796112 ), 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.

D'un point de vue programmation, il y a ceci qui permet une gestion des tâches (pour rebondir sur le commentaire de skizoh) : http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=95490

@+

Zoroastre.

EDIT1 :

Gné! ;)

Gromain59

salut zoroastre,

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 ?

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

Go Up