Bonjour,
Je viens d'acheter (par l'intermédiaire d'un de nos collègues forumreurs) un ICD2.
Ma question : faut-il obligatoirement un RJ11 sur la carte cible pour le raccordement ?
Peut-on modifier le cable (ou en faire un autre) avec connecteur type HE10 ou RS232 ?
Comment faites-vous pour brancher ce cable ?
Merci d'avance pour vos expériences.
Salut Gérard,
pour ma part je me suis fait un câble où d'un coté j'ai un RJ11 femelle et de l'autre j'ai un connecteur en ligne à 5 points que je plug sur la carte cible.
Je prévois toujours sur la carte cible ce connecteur en ligne mâle (plutôt qu'un RJ11 pas toujours facile à implanter sur une carte dense, qui me permet de faire une reprog "in-situ".
Tu peux tout aussi bien prévoir 5 pastilles à souder où tu viens mettre tes 5 fils, une fois ton prog au point tu les enlèves.
La doc de l'ICD2 t'indique le brochage du RJ11 avec un croquis montrant le RJ11 femelle sur la carte cible avec le brochage vu de dessous.
Si tu as de la gaine thermo rétractable, tu soudes les 5 fils sur le RJ11 femelle, tu places les gaines qui couvriront les parties métalliques, un coup de fouën pour rétracter la gaine, un coup de colle à chaud pour noyer et solidariser le tout (garantie le maintien mécanique dans le temps) et voilà une bretelle de liaison prête.
Longueur 15~20cm.
Salut JY,
Je savais que tu trouverai une solution.
Je pense opter pour le connecteur 5 points femelle au bout du cable et 5 points mâle sur la carte cible.
Tant que j'y suis, je voudrais me mettre (doucement...) au C pour travailler avec des outils qui cohérents : MPLAB, C, ICD2.
Après avoir fouillé sur le site de Microchip, je ne trouve que C30 et C18.
Quel compilateur faut-il pour les 16F ?
Bon, c'est vrai qu'il sont un peu vieillots mais il m'en reste et c'est avec eux que j'ai fait mes premières armes PIC.
Peut-être qu'en 2008 je me mettrai aux 18F.
Pour les besoins de l'alim en cours, j'ai recherché un compilateur C qui serait à la portée financière du plus grand nombre afin que les prog que j'ai fait soient exploitables et modifiables par les lecteurs intéréssés par le projet.
Comme tu le sais, je travaille habituellement avec HitechC mais sont prix est dissuasif bien que ce soit un très bon produit.
Il y en a 1 qui est pas mal, MikroC de chez Mikroelektronika.
Les avantages:
L'interface de développement est bien fait, il est plutôt bon en taille de code généré.
Il supporte les PIC jusqu'aux PIC18.
Il est assez proche de la norme ANSI en tout cas peu de divergence.
Le prix est attractif.
Inconvénients:
Il ne s'interface pas à MPLAB mais il suffit d'importer le Hex et de le charger dans l'appli par ICD2.
Il ne gère pas une variable de type bit (donc char obligatoire).
Les bibliothèques sources ne sont pas publiques (pas forcément un handicap il suffit de créer ses propres fonctions).
Mises à jours régulières.
Une communauté (forums) assez actifs.
Il existe la version MikroBasic, comme je sais que tu es déjà sur Proton+.
Dommage qu'à l'époque Brunog ait été trop directif et insistant sur cet outil, qui mérite néanmoins de s'y arrêter et présente pas mal d'intérêt pour des Hobbystes éclairés.
Dommage car il semblait bien connaitre l'outil en question...espéront le revoir un jour avec moins de susceptibilité.
Il existe aussi C2C un peu dans le même esprit qui s'interface avec flowcode mais je ne le recommande pas personellement, il séloigne des exigences ANSI et flowcode tu sais ce que j'en pense.
@+
Et comme çà, ça ne va pas?Il ne gère pas une variable de type bit (donc char obligatoire).
http://forums.futura-sciences.com/post1453144-6.html
Oui Jack tu as raison dès l'instant qu'il s'agit d'un port 8 bit par exemple.
Par exemple:
#define true 1;
#define false 0;
n'est pas possible avec ce compilo sans créer une structure adaptée ou utiliser un char, c'est un peu lourd...
Comprends pas#define true 1;
#define false 0;
n'est pas possible avec ce compilo sans créer une structure adaptée ou utiliser un char,
Il n'y a pas de préprocesseur dans ce compilateur?
Salut,Envoyé par HULK28
C'est normal non ?
A partir du moment ou un bit fait partie d'un byte (vu qu'il s'agit d'un micro 8 bits) il me semble logique qu'il ne soit pas possible d'assigner immédiatement un bit et sa valeur sans passer par un octet.
Le principe est strictement le même en langage d'Assemblage...
C'est plutôt le fait de pouvoir assigner une variable de type bit qui me semble en contradiction avec le hardware du µC 8bits...
Bonnes fêtes à tous.
David.
Mais il s'agit ici de simplifier l'écriture afin d'éviter les masques et tout le tralala.
N'importe comment, n'importe quel micro 8 bit fera un accès 8 bits sur son bus, même pour le modifier ou tester qu'un seul bit.
A+
Oui,
Avec ton exemple du post#5, tu évites l'utilisation des masques et tout le tralala, une fois le bit défini dans l'octet non ?
David.
oui.Avec ton exemple du post#5, tu évites l'utilisation des masques et tout le tralala, une fois le bit défini dans l'octet non ?
Mais en fait je ne vois pas quel problème tu soulèves finalement. Je suis parti du fait que Hulk disais que son compilateur ne supportait pas le type bit.
A ma connaissance, aucun compilateur C ne le supporte non plus. On est obligé de passer par un artifice tel que celui que j'ai présenté dans le post#5. Je n'ai rien inventé ni découvert. C'est à cet effet qu'a été créé le champ de bit dans les structures.
A+
En fait, je dis exactement la même chose que toi, la variable de type bit n'existe pas, mais l'assignation de type bit est heureusement possible...
En Assembleur, je respecte la procédure que du décris dans ton post#5 afin d'assigner un bit dans un octet, seule l'écriture diffère.
Donc, au final le "problème" soulevé par Hulk, n'en n'est pas un vu qu'il suffit d'une simple assignation pour pouvoir travailler sur un bit.
David.
Oui, tout à fait d'accord, le type bit n'existe pas en C, mais personnellement je trouve lourd de devoir assigner une structure systématiquement pour définir un type bit, sur des systèmes orienté µC c'est tout.
Ce n'est qu'une question pratique en fait.
Sur HitechC je déclare de manière transparente un bit comme n'importe quelle variable sans me préoccuper du format assigné par le compilo.
Sur le plan de la norme ANSI il est plus logique en effet que le compilo ne propose pas le type bit mais c'est tellement plus pratique...
Salut Hulk,
avec ton compilo, comment fais-tu pour organiser les bits afin de pouvoir réaliser un masque ultérieurement par exemple ?
Avec le type "struct" c'est toi qui détermine l'organisation des bits et du fait la manipulation des bits permet intuitivement de faire les masques ou les opérations logiques sur l'ensemble des bits.
David.
En principe, dans tout bon compilateur, il y a un fichier d'entête qui définit tous les registres ainsi que leurs bits qui ont une fonction particulière.Oui, tout à fait d'accord, le type bit n'existe pas en C, mais personnellement je trouve lourd de devoir assigner une structure systématiquement pour définir un type bit, sur des systèmes orienté µC c'est tout.
Ca se présente comment l'utilisation d'une variable de type bit?
Je fais un masque avec l'opératuer OU, mais dans le cas ou je veux manipuler une condition d'état dans un if par exemple, ou d'une simple comparaison d'état (vrai/faux, ON/OFF, etc) le passage de bit par structure est inévitable si le compilateur ne prend pas en charge cette particularité et c'est ça que je trouve lourd puisque pour les µC ce sont des situations pratiques.
Oui c'est vrai, mais il n'empêche que ça reste une gestion de char.
Je préfère déclarer:
static bit FALSE;
qu'une structure surtout si j'en ai une vingtaine de ce style dans un soft.
Saint ANSI, priez pour Hulk.
Bon, on a tous nos petites manies
Va au bout de ta pensée Jack, peut-être ai-je tort.
Il faut reconnaitre un avantage aux structures: çà marche avec tous les compilos.
De plus, en utilisant les unions, tu peux voir ta variable ou ton registre de 8 bits comme un octet, 8 bits indépendants, mais tu peux aussi faire des regorupements de bits: par exemple, si tu as 3 bits affectés au diviseur d'un compteur, tu peux gérer ces 3 bits comme une entité indépendante:
après, si tu trouves que "resul.compt.div" est un peu long à manipuler, rien ne t'empêche, comme sur mon compilateur, de faire des #define dans le fichier d'entête. Par exemple:Code://***** déclaration************************** union{ struct octet { unsigned char b0: 1, b1: 1, b2: 1, b3: 1, b4: 1, b5: 1, b6: 1, b7: 1;} bits; struct diviseur{ unsigned char div: 3, bidon: 5;} compt; unsigned char octet; } resul; //***** utilisation ************************** resul.octet = 0; // accès à l'octet entier resul.bits.b0 = 1; // accès aux bits resul.bits.b5 = 1; resul.compt.div = 5;
#define diviseur resul.compt.div
du coup, dans ton programme, tu écriras un truc du genre:
diviseur = 5;
A+
Dernière modification par Jack ; 31/12/2007 à 00h49. Motif: p'tite faute d'orthographe
Oui en effet je n'avais pas pensé à cet usage de union...
Merci pour ce conseil.
Je me suis longtemps demandé quel était l'intérêt pratique des unions moi aussi.Oui en effet je n'avais pas pensé à cet usage de union...
Sur ce, je vais me coucher car je n'ai pas ta résistance légendaire
A+
Tiens Gérard, voici à quoi ressemble la "bretelle" en question.
Salut,
Concernant tout cable ICD2, un point très important quand on travaille avec des PIC18 à frequence élevée ou a fortiori avec les 16 bits (PIC24 ou dsPIC) c'est la longueur du câble !!
Ne surtout pas faire des cables ou des "rallonges". Microchip a raccourci le cable d'origine qui faisait environ 25 cm à 10/15 cm pour pouvoir gérer les fréquences élevées car les signaux sont TTL....
Toute tentative se traduit par des problèmes permanents ou aléatoires de connection. Certains de mes collègues en ont fait les frais...
a+...
et meilleurs voeux à tous
Dernière modification par RISC ; 31/12/2007 à 19h23. Motif: correction
Salut JY,
J'ai récupéré 2 cables avec d'un coté une RJ11.
Je vais me faire 2 bretelles, une avec connecteur mâle et une avec connecteur femelle.
Concernant les compilateurs .... je crois bien que je vais rester Proton (que les as du C ne se moquent pas et me pardonnent), c'est tellement plus simple avec le Basic et il sait faire avec les bit !
Dans - de 2h, on y sera ... en 2008
Je m'en sers uniquement en programmateur, donc pas de soucis de rallonger de quelques cm enfin jusqu'à présent,depuis le temps,je n'ai jamais rencontré de soucis de communication ou de prog.
Peut-être qu'en débuggeur ce ne serait pas le cas en effet.
@+
Dépoussiérage...
Hulk pourrais-tu me donner une reference pour le connecteur que tu as utilisé?
Les fils sont soudés ou sertis ?
merci
