Aller au contenu


Contenu de Geeks

Il y a 26 élément(s) pour Geeks (recherche limitée depuis 26-avril 13)



#57755 Moteurs pour chassis robot

Posté par Geeks sur 09 septembre 2013 - 09:51 dans Mécanique

Effectivement, pour la roue, tu a tout juste Image IPB

Maintenant, je suis aller sur le site Lynxmotion. Ça me paraît pas si mal.
Je pense passer par un jeu de réduction d'un minimas de 50:1 comme par exemple ceux-la qui font une réduction un poil plus importante. Y aura du poids et de la batterie. Je compte faire crapahuter donc il faudra du solide.
Ensuite, les roues. Alors là, je pense qu'il y a deux écoles. Celles de Gotronic sont bien, et pouraît effectivement convenir. Ceci dit, celles de Lynxmotion me convienne aussi (afin de limiter les frais de ports).
A partir de là, il faut des moyeux. Dans le cas de Gotronic, on a des moyeux vendus avec mais il faut prendre une roue après une roues, soit 4 achats. Alors que dans l'autre cas, c'est une paire ! La preuve ! Donc voila le type de moyeux qui semble convenir chez Lynxmotion.

Je riens à précisé que je ne suis pas marié avec Lynxmotion, ceci dit, si je compare un peu les prix, chez nos amis Ricains, j'en suis à $217.70 et y faut ajouter ports et taxes. Pas glop !

Voyons maintenant le cas de Gotronic Image IPBJe commence par les roues. Et là, je me porte sur le même choix.Pour la motorisation, j'ai besoin de couple, du coup je prends une réduction plus forte.
Si je regarde, j'en ai pour beaucoup moins cher finalement. 105,02€ !
Bon, et bien, quand mon électronique sera au point, je virerais mon chassis et je passerais ma petite commande.
A propos, on m'arrêtera si je dis une bêtise mais la réduction de rotation, c'est bien, dans le second cas, on rentre avec 100 tours et on fini avec 1 tour non ?
Merci quand même pour votre aide !



#57753 Moteurs pour chassis robot

Posté par Geeks sur 08 septembre 2013 - 02:44 dans Mécanique

Bonjour,

Depuis le temps... Bref !

Je suis en train d'essayer de sauver les meuble avec un achat ayant fini par me prendre la tête. Le plastique c'est bien quand c'est bien monté mais dès que c'est juste emboîté, bonjour les dégâts !

Suite à cela, marre de toujours payer mes vis, mes taraudages et que ça parte en... Censuré... je me suis décidé, enfin à passer aux choses sérieuse !

Je suis à la recherche de 4 à 6 moto-réducteur avec au bout des roues de buggie. Quelque-chose qui, monté sur cadre métallique (j'en parlerais plus loin), permettra d'avancer, de reculer et de tourné soit dans un endroit vivable et plat, comme dans un jardin ou en montagne. Il faut donc du costaud quitte à ce que l'engin soit lent.

Au niveau cadre, je vais faire un cadre avec de l'alluminium. Percé, taraudé... bref, comme je sait si bien le faire. Il faut donc que je trouve ces 4 ou 6 roues pour avancer maintenant.

Une chose importante, je cherche du fiable. Donc les gadget à la chinoix, c'est pas la peine. Si quelqu'un a déjà eu des choses éprouvés, des sites viable ou la mécanique est bonne, des astuces de ce côté, je suis preneur.

Merci beaucoup.



#49014 Robot et récupération

Posté par Geeks sur 25 septembre 2012 - 04:45 dans Archives

Et re !

Bon alors voila que je vais compliquer un peu les solutions. Je ne peux pas utiliser de wifi car c'est du 2.4 Ghz et ça ne passe pas dans l'eau. J'expliquerais pourquoi plus tard ! Idem pour les xbee !

Si je part sur l'idée de l'infra-rouge, j'aurais alors:
Arduino 1 -> TX -> Infra émission -> Infra réception -> RX -> Arduino 2
Arduino 1 <- RX <- Infra réception <- Infra émission <- TX -> Arduino 2

A ce moment là, je vais me renseigner pour faire mon propre module de transmission bi-directionnel sous 35Mhz voir moins ! A 35 Mhz, on descend facile à 3 mètres de profondeur. A 41 Mhz on descends à 2 mètres. Donc à 17 Mhz, je devrais être peinard !

Petite question au passage, pour essayer ! Si je fais une connexion de type infra-rouge, on passe bien par une communication UART ? Non ? A ce moment là, quelle type de code serais susceptible de convenir ?

J'avance à petit pas, je préfère afin de bien faire le bon choix et la bonne technologie.

Une autre question de type mécanique cette-fois ! J'ai la possibilité de prendre un châssis tout fait! Mais je préférerais partir sur une conception perso. A ce moment là, quelle kit de chenilles et surtout de moto-réducteur pourrait convenir ? Idem, faut-il que le prenne des moyeux exprès ?

Merci pour vos réponses.



#49013 Robot et récupération

Posté par Geeks sur 25 septembre 2012 - 04:36 dans Archives

Kikoo.

Module Wireless APC 220 : il relaie signal serial RX TX entre deux arduinos, portee 800 m. Se branche direct. Alimenté par les cartes arduino.
Cout environ 35 euros(ebay).

Ou alors led infrarouge et capteur IR avec IR library de Ken Shiriff (encore moins couteux). Tu pourrais aussi le piloter avec une telecommande de TV (une seule carte necessaire).

Cordialement,

@hugobiwan




#48697 Robot et récupération

Posté par Geeks sur 11 septembre 2012 - 07:29 dans Archives

Bonsoir,
Changement de cap pour le pilotage !!!

Je pense faire une télécommande dans une valise. Une carte arduino méga <==>xbee<=ONDE RADIO=>xbee<==>arduino méga==>Interface moteur.

Avez-vous déjà tenter cela ? Quelle protocole avez-vous utilisé. Existe-t-il d'autres solutions ?

merci pour vos informations.



#48568 Robot et récupération

Posté par Geeks sur 07 septembre 2012 - 10:19 dans Archives

Ok !

Je viens de me rendre compte qu'on pouvait gagner une cortie avec un 4077. Regarde dans le schéma du sheld arduino ici : http://arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf

Et la petite explication code là : http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.ArduinoExpertMoteurCCDFRduinoMotorDriver1ATestSimple

Comme tu remarquera on simplifie gravement le code que tu m'a donné. Mais j'avoue, j'ai bien eu du mal au départ à extraire la logique ! Mais j'y suis arrivé. Bon une étape de moins, dès que je peux je prendrais ce qui me faut. Et là, c'est pas pour demain Image IPB

En attendant, je vais poursuivre mes investigations.



#48566 Robot et récupération

Posté par Geeks sur 07 septembre 2012 - 09:20 dans Archives

Et bien ! J'en ai mis du temps Image IPB

Bon alors, l'idée est de prendre un L298. Il permet une plage intéressante de fonctionnement et intègre donc deux pont en H.

Si j'ai bien compris, on génère un signal PWM qui va sur la patte EnA. Ensuite si In1 et In2 = 0, il ne se passe rien. Si nous avons In1 = 1 et in2 = 0 alors on a le sens 1. En revanche si on a in1 = 0 et in2 = 1 alors ona le sens 2. Comme il y a deux moteurs en général à piloter et que l'on a les deux ponts en H, on a bien deux fois 3 sorties à utilisé.

Solution pour allégé la carte principale. Prendre une arduino nano et l'utiliser au travers d'une liaison I2C via le L298. Avantage, on gagne en nombre e sorties. Inconvénient, il se trouve que ça ne simplifie pas toujours le soft. Solution bis basé sur deux cartes et une communication entre carte, c'est de faire une liaison série Tx/Rx. Sauf que c'est moins simple à gérer niveau code.

Solution bis des deux autres solution. Utiliser de l'I2C avec un pic genre 12F lui-même chargé de piloter le L298.

Comme j'ai pas envie de me cassé la tête avec un soft qui soit éloigné du soft principal pour la commande des chenilles, je n'utiliserais pas cette solution à base d'I2C.

En revanche, je pense dédié un port su'une arduino méga genre 8 (pwm EnA), 9 (in1), 10 (in2) puis 11 (pwm EnB), 12 (in4), 13 (in3). Le reste étant dédié au reste du projet.

Bon, j'attends votre confirmation concernant mon interprétation du plan du datasheet.

Merci.



#48559 Robot et récupération

Posté par Geeks sur 07 septembre 2012 - 07:03 dans Archives

Ben, c'est simple, il faut voir le bon côté des choses.

Ton système à l'air pas mal ! Mais je pense à juste titre que si c'est la solution, il me manque des infos.

A ce que j'ai regardé de la platine, t'a 4 entrées de pilotage. Il en faut 6 ! Il en manque 2. Ou alors je suis miro Image IPB

Ma solution de partir sur des signaux PWM est compatible avec un pic. Les NE544 ont l'air obsolètes Image IPB

Donc à moins de prendre des variateurs tout fait, ou un sheld ou bien de bricoler des L293, L298, voir de prendre ton système, je voie pas beaucoup de solution "simple" et "fiable".

P.S. Indique moi ton raccordement avec ton module. J'avoue, j'ai beau savoir pas mal de chose, il y a là un mystère que je ne veux pas laisser impuni Image IPB



#48550 Robot et récupération

Posté par Geeks sur 07 septembre 2012 - 03:47 dans Archives

Ah wai, en effet, ça ne le fera pas ! S'il faut 6 pins, je vais droit au mur !

Pour le datasheet, t'inquiète pas, je l'ai. Et c'est aussi ce qui rentrais en contradiction avec les infos que j'avais.

Ou encore mieux, plus simple : http://www.gotronic.fr/art-kit-motor-shield-arduino-12432.htm . Par contre faudra-t-il autant de sorties ?

Sinon, j'ai aussi la solution bis. Utiliser une autre technique ancestrale ne nécessitant plus que 2 pins en PWM :)

Reprenons le fonctionnement d'un servomoteur. 1ms = sens 1. 1.5ms = neutre. 2ms = sens 2. C'est simple, je l'ai déjà mis en oeuvre facilement. A ce moment là, je pense prendre un NE544 qui lui sortira sur un pont en H. Le tout multiplié par deux.

Mais par contre si t'a un exemple de code pour piloter les 6 pins, je veux bien jeter un oeil.



#48548 Robot et récupération

Posté par Geeks sur 07 septembre 2012 - 02:57 dans Archives

Bon, je pense que dans un premier temps, je vais commencer par prendre un châssis tout fait que je modifierais ensuite.
Je pense d'ailleurs me prendre un rover5. Pour ceux qui connaissent http://www.gotronic.fr/art-chassis-rover5-2wd-12394.htm.

Ensuite, je pense que la seconde étape va être le pilotage Arduino / moteurs. Je pense partir d'un L293E mais j'ai des doutes quand à son fonctionnement.
Pour moi, j'ai besoin de 4 sorties au niveau arduino. 2 sorties pwm et 2 sorties sens de rotations. Hélas, le peu de schéma que j'ai trouvé mentionne plus de sorties Image IPB
A confirmé bien sûr.

Pour l'alimentation, déjà je ne partirais pas d'une tension de 7.2V. trop faible pour l'exercice. Une batterie au plomb de 12V viendra alimenté le tout. A savoir: Arduino, L293D (donc moteurs) et je ferais des alimentations à base de régulateur et de condensateur afin de limité le risque de parasite due à l'oscillation des régulateurs.

Pour le moment j'en suis là, tant que je n'aurais pas réussi cette portion, je n'avancerais pas sur les autres. Par conte je me suis permis d'en parlé à titre indicatif.

Maintenant, j'aimerais avoir plus de détails, des exemples de schéma pour la partie puissance. Comment est piloter le L293E ? Si nous ne trouvons pas de solution adéquat, j'ai déjà dans ma ligne de mir une solution 100% arduino mais moins malléable que la solution L293E et quelques composants autour.

En espérant que j'arriverais à trouver une solution fiable.



#48499 Robot et récupération

Posté par Geeks sur 06 septembre 2012 - 08:30 dans Archives

Bonjour,

Cela fait quelques temps que j'ai mes cartes Arduino qui dorment ! J'ai un peu de temps devant moi ces jours-ci donc je pense refaire un peu de robotique.

Au niveau électronique, je recherche un schéma fiable pour récupérer des signaux de type PWM utilisé sur des équipements RC. 1 à 2ms avec un neutre réglable sur 1.5ms. Le type de moteurs employés seront de 3V à 12V et la tension d'entrée sera elle variable aussi. Soit 6, 9 ou 12V. Voila, ça c'est pour la petite recherche subsidiaire en robotique.

Je vais devoir commencer par un châssis. J'en possède déjà un qui serais à rénové, ou bien je le laisse en l'état et je m'attaque à un nouveau système. Le mieux serais pour moi qu'il soit suffisamment grand et porteur pour resté dehors même pendant un sale temps (pluie, neige, vent).

J'aimerais, au final, que sa commande passe par du wifi (j'ai récupéré un point wifi qui semble fonctionné et que je peux bricolé afin de récupérer des infos vers une carte Arduino). A voir si c'est utilisable ! Un retour de caméra type webcam serais un plus. A ce niveau là, je recherche le principe du retour d'image et de paramètres vers un PC. De l'autre je recherche aussi le principe pour passé du PC vers le robot.

Pour le moment je suis bloqué là. Je vais essayer de me basé le plus possible vers la récupération, sauf s'il faut que je crée certains composants.

J'espère que ce sujet vaste sera réalisable. Je ne suis pas pressé à la minute. Je dirais que c'est un projet qui doit s’étaler sur minimum 6 mois voir 1 ans.

Merci d'avoir pris le temps de me lire.



#18542 Fox Board G20

Posté par Geeks sur 09 novembre 2010 - 08:40 dans Hack mod customisations et autres modifications

Bonjour à tous,

En ce moment je cherche des informations sur la G20 et en glanant internet, j'ai remarqué que de nombreux points pouvaient soulever de nombreux problèmes. Je me propose de discuter autour de ces points et des solutions à apporter pour que les développements patinent moins. Les principales solutions, à ce que j'ai pu comprendre était logicielle. Peut-être que ne suis-je pas dans la bonne section et merci de la déplacer si ça doit être fait.

De ce que j'ai pu lire, j'en ai retiré un certain nombre de questions que j'aurais aimé traiter et avoir une réponse claire et en français. Bah oui je ne possède pas un bon anglais et je ne suis pas le seul.

Question 1 : Quand on utilise de l'I2C par le port J7, il faudrait flashé la carte FoxBoard G20. Vrai ou Faux ?
Question 2 : Dans le cas où on est censé flasher la carte, on s'y prend comment ?

Question 3 : La création d'un programme à compiler se fait directement sur la FoxBoard en SSH ou alors elle se fait sur son pc puis envoyer ensuite dans la FoxBoard ?

Question 4 : J'ai cru comprendre que l'on pouvait réinstaller la FoxBoard. Si oui, quelle est la procédure pour une débian et une gentoo ? Est-ce la même ?

Question 5 : La FoxBoard génère parait-il des interférences avec les modems ! Est-ce vrai, ou alors c'est un problème de blindage à effectuer autour de la FoxBoard pour que ça fonctionne ?
Question 6 : Je n'ai pas trouvé beaucoup de sources en C++ sur la toile. J'aurais aimé savoir si une zone existe où on en parle longuement afin de ne pas à avoir à chercher partout pour essayer d'améliorer les softs déjà écrits.
Question 7 : Diverses questions que j'aurais pu oublier ou celle que vous avez et qui demande une réponse concernant la carte FoxBoard G20.

Je crois que j'ai fait le tour et en fonction des réponses, je tâcherais de recensé tout ça pour les faire apparaître sur le site sous forme de faq.

Je vous remercie pour votre aide et attention, désolé s'il reste des fautes, je me débrouille comme je peux.
Geeks



#18524 Introduction à la carte FOX

Posté par Geeks sur 07 novembre 2010 - 10:59 dans Programmation

Bonsoir,

Je compte aquerir dans les semaines qui suivent une G20 pour expérimenté tout d'abord puis pour réaliser un ensemble de projet ensuite. J'attends avec impatience ton prochain tutoriel.

Dans le cas ou je devance l'apparition de ton tutoriel, me permet-tu de te joindre par MP afin de débuter dans de bonnes conditions ?

Merci et encore bravo pour ce tutoriel sur la précédente version de la Fox.
Geeks



#18511 Bonjour

Posté par Geeks sur 07 novembre 2010 - 12:29 dans Et si vous vous présentiez?

Bonjour à tous,

Je me présente, je suis Geeks et mon pseudonyme se prononce Jex. Depuis un paquet d'années en amateur, je pratique la conception robotique et j'ai longtemps oeuvré avec passion avec l'emploie des Pic 16F... Aujourd'hui ces pics, pourtant très pratique, m'ont montrée leurs limites de fonctionnement, m'obligeant à changer de principe.

Dans mes projets futurs, je cherchais une platine de développement (éventuellement sous linux) capable d'emblée de gérer USB, I2C et Ethernet avec une programmation en C++. Les détours du web m'ont convaincu sur l'emploi d'une carte G20 FoxBoard que je compte acquérir sous peu. J'aurais peut-être, je pense l'occasion de revenir dans le forum pour exploser plus longuement les quelques points que je ne connais pas sur cette carte qui semble prometteuse. C'est en faisant quelques recherches dans le domaine que j'ai découvert votre forum que je trouve sympathique.

J'ai de nombreux projets sous mon aile, allant de la domotique sur IP à la conception robotique terrestre et amphibie. Pour le moment je suis encore sur le coup de la construction d'un submersible RC (mon second pour être exact) et un projet de ROV est venu sur le tapis afin de m'en servir sur terre comme dans les profondeurs de l'eau. En attendant que la colle, la résine, j'aurais tout le loisir de travailler sur la FoxBoard.

C'est ce qui m'amène à dire que je reviendrais souvent (ou pas) ici afin de demander quelques subtilités pour faire avancer mes projets.

En attendant, je vous remercie d'avoir pris le temps de me lire et de m'accueillir dans ce forum.
Geeks

EDIT : Correction sommaire, beaucoup de fautes de frappes m'ont échappé avec le recul de l'écran et ma vue faible !
EDIT Bis : C'est bien beau de dire "Désolé, je vous taquine et je suis très tolérant sur les fautes de français et sur la syntaxe qu'on utilise sur les forums. Moi aussi je peux en faire, inutile de les lister :) " mais pour le coup elles ont été listé !



#30858 Capteur à effet Hall

Posté par Geeks sur 11 octobre 2010 - 01:46 dans Electronique

Bonjour à tous,

Je m'intéresse de prêt aux capteurs à effets hall. Je n'ai pas eu l'occasion d'en avoir sous la main, de tester ce que cela vaut, donc avant de me lancé, je voudrais avoir vos retours d'expérience afin de mieux abordé le sujet dans mes constructions robotiques.

En espérant que la doc que je trouverais et qui complètera ce sujet ainsi que vos informations finirons par constituer une petite base de la pratique de ces composants.

Geeks



#22122 Choix à faire

Posté par Geeks sur 10 octobre 2010 - 03:41 dans Programmation

Effectivement, tu a raison de le marqué pour la différence entre C et C++.
Ceci dit, je voulais te montrer que j'avais quelques base. Je te rassure, je suis arrivé à utiliser du C pour un 16F876 en simulation avec PICC.

Maintenant je bloque sur quelques petites choses toutes bêtes et qui pour le moment porte à confusion car souvent mal utilisé et mal expliqué.



#22120 Choix à faire

Posté par Geeks sur 10 octobre 2010 - 03:13 dans Programmation

Oui, héhé!
Tien tu me parle de linux... J'avais un vieux projet d'un noyau qui devais tourné en solitaire sans un disque dur de portable et qui devait avec un FPGA piloter un robot. Il faudra que je me ressorte de la doc la dessus. Il y a peut-être mieux maintenant que ce gros bazar :)



#23538 2A 1F 2C 55...

Posté par Geeks sur 10 octobre 2010 - 10:49 dans Et si vous vous présentiez?

[quote"zeqL"]Concernant l'assembleur, pourquoi n'est plus à la mode ?

- Compliqué : chaque µP/µC/DSP à ses instructions propres. Bien sûr il y a des similarités.
[/quote]
Oui !
[quote"zeqL"]
- (Très) proche du hardware : nécessite de savoir comment fonctionne la cible.
[/quote]
Oui et je trouve celà plus pratique... Question de goùts.
[quote"zeqL"]
- Lourd : dès que l'on commence à rentrer dans des programme un peu complexe, l'assembleur rajoute encore plus de complexité
[/quote]
Ça se vaut! C'est plus facile de ne pas s'occuper de w mais en revanche parfois c'est bien se savoir ce qui se passe derrière en réalité.
[quote"zeqL"]
- Optimisation : oui pour un programmeur expérimenté, mais cela peut-être tout le contraire.
[/quote]
Je comprend pas le sens de ta phrase. Le cours de BIGONOFF explique parfaitement ce ue fait l'assembleur, chaque subtilités et en plus il donne des rudiments tels que le travail sur les bits (ors registre).
[quote"zeqL"]
Donc les nouveaux langages, notamment le C, permettent d'avoir des fonctions toute faite, probablement optimisées et utilisable pour la plupart des cas.
[/quote]
Ok, je suis bien d'accord avec ça.
[quote"zeqL"]
Afficher un texte sur un afficheur LCD avec un PIC16F, en C : environ 10-20 lignes, en ASM : plusieurs pages.
[/quote]
C'est pas faux mais avec quelques routines c'est un jeu d'enfant et ça revient à moins de 10 lignes en asm...
[quote"zeqL"]
Néanmoins tu as toujours la possibilité en C de coder des routines en ASM. Et certains compilateurs C pour PIC permettent de récupérer le code en ASM, donc tu peux repasser derrière pour optimiser :) [/quote]
Fonction intéressante que je ne connaissait que pour le C++, il y a longtemps, très longtemps !

Globalement on y gagne avec le C mais si on cherche un peu l'asm peut être pratique, débat clos !



#22118 Choix à faire

Posté par Geeks sur 10 octobre 2010 - 01:49 dans Programmation

Je rêve ou tu pinaille la !



#22116 Choix à faire

Posté par Geeks sur 09 octobre 2010 - 11:47 dans Programmation

De mémoire :
string text = "Salut, je crois de mémoire que le C s'écrit ainsi et que je saurais alors me dépatouillé";
if(text != null) {
printf text;
}
else {
printf "Aucune données saisie!";
}
}[/code]

Donc si ça ne va pas plus loin que ça, je devrais m'en sortir alors !



#22114 Choix à faire

Posté par Geeks sur 09 octobre 2010 - 08:14 dans Programmation

Je connais le site... Heureusement sinon je n'aurais pas eu la connaissance de l' ICD2 !
Ma question était plus par rapports aux connaissances du site, on c'est je pense mal compris!

Mes investigations m'ont amenée à considérer le Pic 16F88 car il rentre parfaitement dans les cahiers des charges que j'ai actuellement sous la main. Il me reste une chose à avoir, un compilateur C et une doc qui explique le C pour pic.

Justement ou puis-je trouvé une documentation sur le C appliqué au pic ?

Voilu



#22112 Choix à faire

Posté par Geeks sur 09 octobre 2010 - 04:29 dans Programmation

Bonjour tout le monde, ou re bonjour tout le monde,

J'exposait dans un autre post des choix drastiques fait jusque alors et qui me convenais parfaitement niveau PIC 16FX (remplacez X par 84/876A) cadencé en horloge externe de 4 à 20 MHz. L'assembleur pronais chez moi une place assez importante car simple (a mon goût), efficace et surtout pas limité par MPLAB.

Seulement voila, ma problématique actuelle dans mes projets sont que la taille d'un Pic 16F876A est trop grosse pour mon application et puis je pense qu'il y a plus petit pour autant de taille mémoire programme ainsi que l'utilisation de l'horloge interne à 4MHz.

Seulement il y a un hic ! Vers quel Pic à mémoire flash directement programmable en C puis-je me tourné ?
Je possède un ICD2 (c'est une chance me dirais vous mais encore que c'est facilement disponible) et bien sûr je le synchronise avec MPLAB.
J'aimerais tant que faire ce peu trouvé une doc pour apprendre le Pic en C pour pouvoir m'y essayer et tenter d'avancer un peu.

Auriez-vous des indications à ce sujet, car les 3/4 de mes projets utiliserons de l'UART ou de l'I2C et des afficheurs. Il faut qu'il soit facilement programmable en C et enfin qu'il ne soit pas non plus fait pour les paniers percés !

Merci



#23536 2A 1F 2C 55...

Posté par Geeks sur 09 octobre 2010 - 04:20 dans Et si vous vous présentiez?

Tout à fait !

Maintenant, c'est vra que moi j'ai que trop l'habitude de mon 16F876A et que pourtant j'aimerais trouvé plus petit (pour des applications embarqués, moins couteuse en ressources, sans quartz, donc en utilisant celui qui est intégré et pour finir qui joue sur de L'uart seul, l'I2C seul, PWM entrante ou sortante, voir les deux dernières en même temps. L'assembleur dans ce cas serait vite limité en rapidité de développement.

Donc je vais surement faire comme suit, un pic 16F876A en assembleur sous 20MHz et des pics moins gros en taille mais aussi lourd en programmation avec une horloge interne. Le débat est ouvert ! A ce sujet, je vais surement posé la question plus loin dans le forum pour laisser cette partie là dédié à la présentation.

Merci...



#23534 2A 1F 2C 55...

Posté par Geeks sur 09 octobre 2010 - 02:34 dans Et si vous vous présentiez?

Et bien alors, je vais relancer mes ateliers pour me mettre au C.
Pfiou, moi qui pensait en être débarrassé définitivement !



#23531 2A 1F 2C 55...

Posté par Geeks sur 09 octobre 2010 - 12:12 dans Et si vous vous présentiez?

Alors je vais tenté de répondre au Geeks ou jex !

Tout à commencé avec un groupe de copain qui avait chacun un pseudonyme commençant avec un "G". Nous avions Grundt, Gunter et il manquais Geeks! Epoque sournoise ou l'informatique le supplante aux joies du direct, le Geek reste sur son PC. Comme je code beaucoup aussi et que je fais rarement dans la moitié un a dit voila Geek et un autre à répondu jex ?
Nous avons alors dit tu prononce mal le mot Geek et c'est resté Geeks prononcer Jex.

Pour ce qui est du C, je voie que c'est devenu la mode pour les mid-range de microchip. Poah et l'optimisation ?
Autant je suis d'accord que le C est plus facile (non plus lisible à cause des {} autant quand il recode, c'est imbuvable !!! L'assembleur ma permi, par exemple de travaillé en mode 4 bits sur un afficheur 2*16 prévus en 8 bits, de faire un maître I2C, de tester des entrées et des sorties tout en gérant parfaitement le registre w. C'est pratique je trouve mais les registres sont dur à utilisé. Dans le C, c'est écrit et il n'y a qu'à interprété, du coup on dit un mot clair et ça code seul !

Sauf que voila, tout ça est beau mais je ne fais pas comme les autres 4MHz ne suffisent pas dans mon cas et c'est 20MHz qui sont utilisé. Les 3/4 des libs sont faite pour du 4MHz alors qu'en est-il pour le 20MHz ?

Comme on le voit de suite, j'ai choisit mes standards pour deux raisons. La premièreest la possibilité de se dépanné très rapidement (plus facile directement en assembleur à l'instruction prêt qu'en C ou et bien... voila quoi ! Et les 20MHz est là uniquement pour permettre de faire plus rapidement des instructions. Alors à suivre, je ne demande qu'à être conquis !