Aller au contenu


Contenu de eihis

Il y a 63 élément(s) pour eihis (recherche limitée depuis 14-mai 13)



#17732 Combat avec les transistors

Posté par eihis sur 12 août 2010 - 09:12 dans Electronique

leon a dit: "J'avoue que je n'ai pas non plus compris ce que veut dire eihis par "un collecteur reste un collecteu". Tu peux préciser, stp?"

..je pensais pas que tu releverais un truc dans ce genre.
en fait, faut pas m'en vouloir, mais parfois je me demande a quoi servent tes remarques.. tu tiens un compteur de posts ?

@+



#17734 Quelques questions sur les outils

Posté par eihis sur 13 août 2010 - 04:44 dans Hack mod customisations et autres modifications

bonjour,
j'arrive un peu sur le tard, mais concernant le fer a souder, je ne suis pas du tout daccord avec ce que je viens de lire.

Il ne faut pas confondre puissance et température du fer.
un fer thermoregulé de 80W fait du super boulot et ne brule aucune piste.
l'erreur de base, c'est de prendre un fer trop puissant s'il n'a pas de régulation de la température de panne.
En fait, en prenant un fer moins puissant ( passer du 30w au 18w comme j'ai pu le lire), c'est déplacer le probleme : le fer chauffe moins, effectivement, mais des qu'il s'agit de chauffer une connection un peu epaisse ou un plan de masse, ton fer colle et tu n'arriveras plus a chauffer ta soudure (boulot de m...).

Je parle en connaissance de cause, je fais de la maintenance electronique industrielle et je bosse tous les jours avec un weller WP80 de 80w sur des cartes avec et sans CMS, en multicouche. si je brulais des cartes , y'a longtemps que j'aurai perdu mon job...

En conclusion, il vaut mieux investir 50 à 60 euros dans un fer (en station) thermorégulé de 45w à 60W plutot que dans un fer 20w non régulé a 15 ou 20 euros qui ne permet pas la souplesse de travail que fournit le premier cité... mais tout dépent de ce que tu comptes faire avec, dans quel but, de la frequence d'utilisation, bien entendu...

@+



#18359 Marche gyroscopique - proto "MZ"

Posté par eihis sur 20 octobre 2010 - 08:58 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Salut eihis

Trés intéressant ton travail et ton site aussi ;)

Allier la gyroscopie inertielle à la marche ça me rappelle ce brevet du CEA: FR2902870A1

ça pourra peut-être t'aider dans tes travaux!

En tous cas n'hésite pas à nous envoyer des updates.

Vive Foucault....


coucou !


J'ai un peu mis de coté ce montage , ayant démarré et déja bien avancé sur un projet de micro-ordinateur a base de PIC avec RAM exterieure et tout le toutim.
Mais j'ai lu avec interet ton lien vers le brevet. j'aimerais avoir accès au 'the walking gyro' de jameson, paru dans 'robotics age vol7.1 '.. mais je crois que c'est plutot compromis (introuvable?..)

mon probleme avec 'MZ' , c'est qu'il faut trouver un moyen de rétracter très rapidement la jambe, pour pouvoir profiter au mieux de l'effet gyroscopique induit par la chute du corps du robot du coté ou l'on vient de rétracter la jambe...la solution semble etre un systeme pneumatique ou a electro-aimants (mais j'y crois peu vu le poids..) .
A part ça, une variante a tester consiterait a monter le gyro sur une base a 3 roues orientées comme un anneau autour d'un corps circulaire.

la mise en route des moteurs de ces roues va entrainer une rotation du corps du robot sur lui meme par rapport au plan du sol : hors si un gyroscope tourne en meme temps , solidaire de ce corps, alors l'ensemble devrait se soulever d'un cote ou de l'autre, selon le sens de gyration du corps par rapport au plan du sol(en d'autres termes, on fait tourner le corps sur l'axe Z si XY est le plan du sol).De la, en alternant des rotation 'horaires' / 'inverse-horaires' succéssives, on devrait obtenir un engin qui se déplace d'une facon peu orthodoxe , en prenant appui sur le sol par un double effet de reaction(friction) + precession . Je m'y colle quand j'aurais un peu plus de temps !

Merci pour ton lien et ton commentaire ! ++



#18847 HELP première programmation

Posté par eihis sur 10 décembre 2010 - 10:53 dans Programmation

Salut,
Je pense que l'on a tout ce qu'il faut pour programmer enfin ce PIC mais puisqu'on est complètement néophyte en la matière, on espère que quelqu'un puisse nous guider :

On s'est procuré deux PIC 16F88 et un clone du PICkit2. On a trouvé le fichier HEX du Tinybootloader version 16F88 pour 8MHz interne et celui pour 20MHz (mais on ne sait pas si CCP1 est sur B3).

On a aussi téléchargé le logiciel PICkit2 et programmé (in-circuit) les bootloader sur chaque PIC sans problème.

Au niveau de la conception du vrai programme, on a je pense compris le principe (en même temps avec Flowcode…). Le simulateur nous dit que cela fonctionne (mais on n'a pas encore testé réellement).
Avec Flowcode, on arrive à traduire l'algo en C et normalement en HEX (je dis normalement parce que parfois ça ne marche pas ; on a d'ailleurs téléchargé MPLAB + HI TECH C, Code Blocks...mais on ne sait pas s'en servir.)

Le seul problème, c’est que lorsqu’on met le programme en HEX sur le PIC avec le logiciel PICkit2, le bootloader déjà installé est supprimé… Comment faire ?

Merci beaucoup !


kikou !

Le role du bootloader est justement de charger un programme en mémoire du pic sans passer par l'ICSP : souvent le bootloader utilise la liaison série pour recevoir le programme en mettre en mémoire.
Si tu programme un pic en ICSP, tu efface forcément le bootloader puisque dans ce mode de programmation, on doit envoyer exactement la quantité d'octet correspondant a la totalité de l'espace mémoire (une sorte "d'image mémoire",contenant les datas et le code programme :c'est le fichier 'HEX' généré par le compilateur.

Pour verifier que le programme est envoyé sur le pic en ICSP, il faut regarder a l'oscillo si tu as bien des signaux sur les broches d'ICSP (broches PGC,PGM,PGD) et que la broche VPP est bien mise a l'état haut (tension de programmation).
dans le cas d'un bootloader, il faut lire sa documentation , pour savoir la manip. a suivre afin de mettre le pic en mode 'load' et accueillir ton programme.

@+



#18848 HELP première programmation

Posté par eihis sur 10 décembre 2010 - 11:23 dans Programmation

OK, je vais sûrement faire ça...je ne dois pas trop traîner...mais j'ai pas beaucoup de sous.
Qu'est-ce que vous pensez de ça, ça ou ce qu'on trouve ?
Ce sont vraiment des programmateurs ? Il n'y a rien besoin d'autre ? Parceque ça m'a l'air très peu cher par rapport à ce qu'on trouve sur d'autres sites...


concernant ces programmateurs, ils sont tous fonctionnels.
j'utilise un prog. sur port parallele , mais pour pic 18F.
le prog. sur port parallele utilise les tensions disponibles sur le port : elles sont suffisantes pour programmer , ce qui explique le peu de composants nécéssaires ( en général, on retrouve 3 ou 4 diodes et 3 ou 4 transistors et quelques résistances) : c'est simple,et très robuste.
Par contre, il ne faut pas espérer ajouter un cable au bout : tu auras trop de parasites et tes progs vont etre mal chargés, ce qui impose de brancher ta carte supportant le pic directement 'au cul' de ton pc ( sur la fameuse carte dont on parle, branchée sur le port parallèle)

Si ces programmateurs sont simples, c'est parceque l'ICSP (In-Circuit-Serial-Programming) est simple :

si un pic a 32Ko de mémoire, il suffit pour le programmer de lui envoyer les 32Ko EXACTEMENT sur les connections prévues pour ça : une horloge (PGC) + les datas série (PGD).
2 autres broches sont utilisée : PGM (qui fait entrer le pic a l'etat 'programmation' quand elle est a l'état haut, avant de lui transferer le programme complet,
et VPP qui est la tension de programmation.
VPP peut etre : la tension normale , ou la tension 'low voltage', dans le cas des pic18 (je n'ai pas le datasheet des 16F/C et je ne sais pas si ce mode existe chez eux..)

Voila pourquoi ces montages sont si simples.
Attention quand meme, car une autre nécéssité est d'avoir une alimentation 5V extérieure pour alimenter le pic lors de la programmation (certains montages pompent les 5V sur le port parallèle, mais c'est plutot risqué)

@+



#18882 HELP première programmation

Posté par eihis sur 11 décembre 2010 - 07:03 dans Programmation

Merci beaucoup pour ton aide ! Je commence à y voir plus clair.
Par contre mon programmateur n'utilise pas la patte PGM mais le bootloader semble quand même installé.

J'ai réalisé cela, c'est avec ça et les pattes Tx Rx que je peux installer mon programme ? Avec quel logiciel ? J'ai aussi besoin du programme sous forme de fichier HEX ?

Sinon, comment faire sans le bootloader ?
Merci


salut !
Le bootloader, c'est un mini programme qui reste en permanence dans le PIC.
Son role est de charger un programme principal en mémoire, et de le 'lancer' : il utilise a ma connaissance toujours les broches rx/tx série du PIC.
Le bootloader occupe très peu de mémoire dans le pic,et si tu choisis d'en utiliser un, tu dois aussi en connaitre le mode de fonctionnement afin
d'initier le téléchargement d'un nouveau programme, ainsi que l'emplacement mémoire ou le bootloader va charger ce programme.

si ton bootloader utilise la liaison série du pic (ce qui doit etre le cas..),alors c'est par cette liaison que tu dois lui envoyer
les données de ton programme (le bootloader va se charger de les ecrire dans la mémoire du pic au fur et a mesure : il jour le role
d'intermediaire, qui t'évite de 'flasher' ton pic entièrement.

Le bootloader a des avantages (rapidité/simplicité) mais aussi des inconvénients : il faut utiliser un logiciel dédié pour envoyer le programme.
Pour que le bootloader entre en mode 'programmation' et attende l'envoi de ton programme par la liaison série, il y'a plusieurs méthodes
possibles comme par exemple un strap a mettre ou enlever sur ta carte , ce qui le met en état 'attente de données a charger en mémoire'.


L'autre type de programmateur utilise les broches PGxxx , et se branche sur ton pc via le port LPT ou série ou encore un port USB ,
et sur ta carte par un connecteur au broches 'normalisées' par Microchip.
Ce connecteur de programmation comporte 6 broches :

br1- VPP ----> MCLR/VPP du PIC
br2- VCC ----> vers le +5 de ta carte
br3- GND ----> GND de ta carte
br4- DATA ----> PGD du PIC
br5- CLOCK ---> PGC du PIC
br6- LVP ----> PGM du PIC

(attention, il en existe des variantes...).

Si tu programmes ton pic avec ce genre de programmateur, il te suffit d'un logiciel freeware (il en existe un bonne quantité) ,
qui demandera un fichier .HEX comme source a charger dans le pic.
J'utilise pour ma part PP18 , version 2.02 qui est sous license libre GPL, en ayant correctement configuré les signaux nécéssaire ( ce réglage dépend du montage utilisé).
Il detecte automatiquement la présence de la carte de programmation sur le port parallèle,
et la fameuse carte comporte en tout et pour tout 4 transistors + 8 résistances.

@+ !



#18917 HELP première programmation

Posté par eihis sur 14 décembre 2010 - 07:41 dans Programmation

salut !

Tu cherches a faire clignoter un led sur le port A , bit 0 :P
..ca doit marcher sur le papier,et vu le code ( meme s'il est sacrement étrange et peu optimisé ).

Les warning sont la pour te signaler que les fonctions non utilisées provenant du fichier 'include' ne sont pas compilées :
Le but est de gagner de la place mémoire . Rien d'anormal .

niveau code, TRISx sert a determiner le 'sens' d'un port (entrée ou sortie) :
il n'est pas nécéssaire de le redéclarer a chaque fois que tu accede au port ( ca n'a pas lieu d'etre sauf si tu as modifié depuis le dernier accès le 'sens' du port [lecture->ecriture et vice- versa])
A part ça, tu devrais prendre l'habitude d'écrire les variables/mots cles en majuscule pour différencier tes variables propres des variables 'reservées'.
ecrire TRISA au lieu de trisa , par exemple, ou 'PORTA' plutot que porta. c'est con, mais ca aide bcp a clarifier le programme quand on le relit :D

A part ça,attention aux bits de config, au moment de transferer le prog. (ne pas mettre par exemple le WatchDog en route si ton programme ne le gère pas (ce qui est ton cas il me semble, avec ce bout de code) ^^ ..
EN ICSP, ca tourne surement, moyennant une config correcte sur les fameux bits 'de config'.

...avec un bootloader, ces bits ne sont surement pas utilisés (mais j'en suis pas sur.. a toi de fouiner dans la config du logiciel )
egalement, voit dans le compilateur si tu peux (ou dois) cocher l'option 'code relocatable' (c'est a mon avis nécéssaire pour envoyer un programme a l'aide d'un bootloader)

@+!



#19098 programmer en c?

Posté par eihis sur 09 janvier 2011 - 04:30 dans Programmation

hello

c, c++, pascal, cobol, fortran, basic .. tout est question de compilateur , qui traduira le code en language machine.
Pourtant, certains micros sont plus 'orientés C' que d'autres ( ils comprennent dans leur jeu d'instruction machine des commandes très proches de la syntaxe du 'c' ce qui rend la compilation très efficace ( boucles 'while' par exemple.))

tu as le choix dans le language car le compilateur est la couche 'd'abstraction' avec le hard.

@+



#19219 Transistor ou Ampli op ?

Posté par eihis sur 22 janvier 2011 - 12:04 dans Electronique

coucou !

TRANSISTOR = nécéssité de polarisation dans la zone 'linaire' + gain fixe , ce qui entraine que pour augmenter le gain , il faut ajouter des etages supplémentaires ( ce qui ajoute a chaque etage de plus du bruit superposé sur le signal 'utile'. il faut calculer les courants de repos et tenir compte donc du gain (hfe) . un mauvais montage grille facilement le transistor ( courant trop important dans le collecteur, par exemple)

AOP = impedance d'entrée théorique infinie, gain théorique infini ( on le fixe par un jeu de résistances , et les formules pour le determiner sont simplifiées car ne prennant pas en compte les courants dans le circuit. de plus la plupart sont protégés en sortie conte les C-Circuits ce qui les rend très robustes a l'utilisation 'non experte'.

néanmoins, dans la pratique, pour choisir un aop il faut regarder de près : sa tension d'alim , et son slew-rate (pente max du signal) pour savoir s'il pourra bosser dans la bande de fréquence souhaitée.

@+



#19396 Une main robotique pour handicapés

Posté par eihis sur 22 février 2011 - 06:30 dans Assistance à la personne

bonjour,

je rentre un peu tard sur le sujet, mais je commence a m'y interresser depuis quelque temps.
en ce qui concerne le traitement des signaux electriques captés sur le corps (signaux nerveux), je me demande si un reseau de neurone ne serait pas le plus adapté : l'individu peut directement faire lui meme la phase d'apprentissage au reseau (modification du poids des liaisons...)

j'ai malgré tout des doutes par rapport a l'autonomie de systemes comme ceux la : si une main 'bionique' fonctionne 2h au maximum, c'est plutot génant.

@ bientot pour des news :
j'attaque le sujet avec un montage expérimental de captage des pulsations electriques et je vous tiendrais au courant de l'évolution au fur et a mesure tu temps que j'aurais de dispo.



#52085 service de programmation eprom / mcus / Gals etc

Posté par eihis sur 11 décembre 2012 - 10:45 dans Reventes, matériel d'occasion, récup

Bonjour,

Dans le cadre de l'extension des activités de ma société, je m'interroge sur la pertinence de proposer un service de programmation de composants type eprom,eeprom, pals, gals , MCUs (PIC , ATMEL etc ), avec envoi des fichiers numériques source ( Jedec , .HEX , etc ) et fourniture du composant a programmer.
La tarification serait basée sur le prix réel du composant ( source : farnell / RS etc ) + un tarif fixe pour la programmation (selon taille du fichier ou type de composant ) + cout expédition.

pensez vous que ce genre de service peut etre utile sur le web.
existe t-il déja ? si oui, ou ça ? , qui ? , quels tarifs, quels délais ?

Ensuite, je souhaite distribuer des composants et modules de qualité, importés d'asie.
Pourriez vous me donner une liste de composants/ modules que vous employez regulierement, et dont les prix sont , a votre avis, trop élevés ? ( exemple : afficheurs 128x64 , arduino... etc)

merci d'avance pour vos réponses!

stef



#52093 service de programmation eprom / mcus / Gals etc

Posté par eihis sur 11 décembre 2012 - 02:09 dans Reventes, matériel d'occasion, récup

Bonjour,

je me suis peut etre mal exprimé. le service fourni serait uniquement celui du transfert : le client fournit le fichier source + la ref. du composant a programmer. Il reçoit ensuite chez lui le composant, programmé avec le source qu'il a fournit ( fichier .HEX , .BIN , .JED etc...)



#52114 service de programmation eprom / mcus / Gals etc

Posté par eihis sur 12 décembre 2012 - 10:11 dans Reventes, matériel d'occasion, récup

salut,

oui, je comprends ton point de vue : pour tout ce qui est microcontroleurs, un kit d'upload suffit ( pickit...etc ) , mais ca se complique pour les GALs , EPLDs, FPGAs ,d'ou l'idée du service.

La copie de proms de cartouches de jeu de consoles plus ou moins agées est aussi ciblée,
ainsi que la programmation des proms pour modification des injections pour le tuning auto ( peu de gens sont équipés du materiel nécéssaire ).

mais bon, ok, je prends note de tout ça.

concernant les modules (arduino) ,
pouvez vous me donner une rérérence exacte ,
puis le prix le plus bas trouvé a l'heure actuelle pour ce module ? ( citer le site vendeur )

merci @+