Mes soucis avec les PIC

[Antoane]

Bonjour,

Je me suis mis aux PIC.
J'ai donc acheté 2 beaux 16F877A, et un 16F628A. J'ai créé un programmateur : http://www.tavernier-c.com/programmateur_de_pic.htm
et j'utilise IC-Prog.
Je branche le tout, j'ouvre mon programme, et je lui dit "Tout programmer".
Il me demande si je veux vraiment programmer ce composant, je lui dis que oui. Il me raconte alors qu'il écrit sur mon pic, et les leds de mon programmateur clignotent.
Mais, alors -comble de la grossièreté-, il m'affiche une belle croix rouge et me dit "échec de vérification à l'adresse 0000h !".
D'ou vient le problème ? est-ce parceque mon programmateur ne prend pas en charge un pic finissant par A ?

PS : je ne pense pas que l'erreur vienne du programme qui a été fait sous flowcode_V3, et qui foonctionne en simulation. Par ailleurs, J'ai testé deux pic (un 16F877a et un 16F628a) : même résultat.

Merci de votre aide.

-----

[invite03481543]

Bonjour,

je ne connais pas IC-PROG mais je suppose que quand tu veux programmer un PIC il te demande lequel, non?

As-tu déjà pu programmer un PIC genre 16F84 tout bête avec ton engin?
Il faudrait être sûr de ta carte et de tes branchements avant tout, comme par exemple vérifier la tension Vpp lors de la programmation.

[Antoane]

Bonjour,
J'ai directement essayé de programmer un 16F628A.
Je pense que ma carte est bonne car lorsque je lance IC-Prog, il me propose, dans "option", de tester le hardware : lorsque je le fait, je trouve des valeurs coerentes avec ce que je devrai trouver, d'après le schéma.
Sauf, peut-être : 12,5V, c'est suffisant comme tension de programmation ?

Je mes quand même mon programme en C, au cas où il y aurai une erreur dans les déclarations au début (ou ailleurs ) :

#define MX_PIC

//Définir pour microcontrôleur
#define P16F628A
#define MX_EE
#define MX_EE_TYPE1
#define MX_EE_SIZE 128
#define MX_UART
#define MX_UART_B
#define MX_UART_TX 2
#define MX_UART_RX 1
#define MX_PWM
#define MX_PWM_CNT 1
#define MX_PWM_TRIS1 trisb
#define MX_PWM_1 3

//Fonctions
#include <system.h>
#pragma CLOCK_FREQ 32768

//Configuration de données

//Fonctions internes
#include "C:\Program Files\ExpressPCB\Matrix Multimedia\Flowcode V3\FCD\internals.h"

//Déclarations de fonction Macro


//Déclarations de Variable
char FCV_PORT_A;



//Définitions supplémentaires


//Implémentations Macro

//Installation supplémentaire


void main()
{
	
	//Initialisation
	cmcon = 0x07;


	//Code d'initialisation d'Interruption
	option_reg = 0xC0;


	//Boucle
	//Boucle: Tant que1
	while( 1 )
	{
		//Entrée
		//Entrée: PORT A -> PORT_A
		trisa = trisa | 0xff;
		FCV_PORT_A = porta;


		//Condition
		//Condition: PORT_A = 1?
		if( FCV_PORT_A == 1 )
		{
			//Sortie
			//Sortie: 1 -> PORT B
			trisb = 0x00;
			portb = 1;


		} else {
			//Sortie
			//Sortie: 0 -> PORT B
			trisb = 0x00;
			portb = 0;


		}


	}


	mainendloop: goto mainendloop;
}

void interrupt(void)
{
}

Merci.

[VIIV]

Je comprend vraiment pas. Ca doit être le 100ème message disant "mon programmateur fait maison marche pas". Pourquoi les gens refusent de dépenser 30€ pour un PicKit2, et avoir la paix une foi pour toute, pouvoir debugger le PIC par ICSP....
On m'as toujours dit que l'électronique c'est pas du bricolage, et que faut avoir du matos de pro pour pouvoir faire un truc correct....

Mais bon je suis encore jeune et con.

[A voir en vidéo sur Futura]

[invite87be5ae9]

Je comprend vraiment pas. Ca doit être le 100ème message disant "mon programmateur fait maison marche pas". Pourquoi les gens refusent de dépenser 30€ pour un PicKit2, et avoir la paix une foi pour toute, pouvoir debugger le PIC par ICSP....
On m'as toujours dit que l'électronique c'est pas du bricolage, et que faut avoir du matos de pro pour pouvoir faire un truc correct....

Mais bon je suis encore jeune et con.

Oula ! Il faut pas s'énerver
C'est vrai qu'en tapant "erreur 0000h" sur la fonction recherche, on risque d'en avoir pour des soirées à écumer les messages récurrents sur ce souci.

Ainsi, je vais re-donner l'éternelle réponse :
Le souci avec IC-PROG et les programmateurs home-made est que le programme balance aveuglément les données sur le port, et vérifie ensuite.
Donc les LEDs peuvent clignoter, mais pour d'innombrables raisons, le PIC peut quand même ne pas être programmé !
Ca peut aller de l'erreur de schéma, de mauvaises temporisations, même de PIC branché à l'envers ou grillé.

Pour résumer :
Si on doit programmer un firmware une fois en passant, dans une carte réalisée à partir d'un magasine ou un schéma sur internet, on peut risquer de faire un programmateur à quelques euros sur une plaque d'essai avec des composants de fond de tiroir.

Si on veut expérimenter, je rejoins à 100% l'avis de VIIV ! Autant débourser un peu plus et opter pour une solution plus professionnelle qui détectera le PIC, le programmera rapidement, et de manière fiable.
Je crois que les plus réticents changeront d'avis après plusieurs heures/jours passés à débugger un programme qui n'était tout simplement pas buggé, mais mal programmé dans le PIC !

Je pense avoir été le premier sur ce forum à conseiller ce Pickit2 à l'époque où il était encore loin de ce qu'il est actuellement, et personne n'a eu l'air de s'en plaindre... Au contraire

[Antoane]

Bonjour,
Merci pour vos réponses.

comprend vraiment pas. Ca doit être le 100ème message disant "mon programmateur fait maison marche pas". Pourquoi les gens refusent de dépenser 30€ pour un PicKit2, et avoir la paix une foi pour toute, pouvoir debugger le PIC par ICSP....

En fait on ne doit pas avoir la même vision du programmateur de µC : pour toi -et lolomatic-, ce n'est qu'un outils qui permet ensuite de construire quelque chose -un beau système qui régule l'arrosage du jardin, par exemple-. Pour moi -et plus de 100 autres (car il y a ceux qui fonctionnent du premier coup, ou qui ne connaissent pas cet exellent forum ; bien qu'il faille aussi enlever les pingres)- construire un programmateur de µC, c'est déjà un agréable moment : tout autant que celui de construire une belle horloge murale qui va indiquer l'heure en clignotant, et en adaptant l'éclairage des-dites led à la luminausité ambiente.

En effet, 100 d'entre eux (ou plutôt, de nous ) on eu des problèmes (je l'ai aussi vu dans le forum, bien qu'ayant été absolument incapable d'y répondre ).
Mais probablement pas plus que si ça avait été leur horloge.

Mais bon je suis encore jeune

Je le suis encore plus

et con.

Ca reste à voir

C'est vrai qu'en tapant "erreur 0000h" sur la fonction recherche, on risque d'en avoir pour des soirées à écumer les messages récurrents sur ce souci.

Et c'est ce que je fis... et j'ai vu la lumière _vous remarquez au nombre au combien élevé de que je suis de bonne humeur_ : il faut entre 13 et 14 V au MCLR ! or, comme je l'ai indiqué, je n'ai que 12.5V ! J'ai donc rajouté une petite diode de plus (en fait, je l'ai changé : remplacé par une diode ayant une tension de seuil de 1.2V, c'est pas un peu élevé pour une diode ? C'est une CMS) entre la patte GND de mon 78l12 et la masse : programmation du composant réussie !

Merci donc pour votre aide !

[invitee0bbe70d]

Bonjour Antoane,

Je suis également en faveur du Pickit2 pour les raisons qui suivent :
La plupart des programmateurs fonctionnant sur le port série ou parallèle dépendent des caratéristiques électriques de ces ports.
Beaucoup des montages que l'on voit n'ont pas pris en compte les cas extrêmes qui peuvent se présenter mais ont été élaborés sur la base du "on essaye et on modifie jusqu'à ce que cela fonctionne".

Pour clarifier mon propos :
une liaison série RS232 à comme caractérisques au niveau sortie : +/-5V à +/-15V.

Si ta sortie série est à +/-15V la plupart des montages fonctionneront, par contre si elle est à +/-5V la plupart des montages ne fonctionneront plus du tout.

Donc beaucoup de personnes construisent leur programmateur correctement et celui-ci ne fonctionne pas ...et ne fonctionnera peut-être jamais par ce qu'il n'est pas fait pour tenir compte des caractéristiques minimum et maximum des composants et des standards.
Je pense (et beaucoup sur ce site également ) que c'est frustrant pour une personne qui démarre d'être confronté à ce genre de PB et c'est la raison pour laquelle les posts précédents ont également conseillé un programmateur qui fonctionne dans tous les cas de figures...

Si tu as de bonnes connaissances en électronique et du matériel style oscillo tu pourras détecter tout problème au niveau électronique sans quoi tu risques de passer du temps sans finir par résoudre ton PB....

PS : le titre de ton sujet devrait plutôt être "mes problèmes avec un programmateur fait maison..."
Les PICs n'ont rien à voir avec tes PB actuels...

[invite87be5ae9]

Pour clarifier mon propos :
une liaison série RS232 à comme caractérisques au niveau sortie : +/-5V à +/-15V.

Si ta sortie série est à +/-15V la plupart des montages fonctionneront, par contre si elle est à +/-5V la plupart des montages ne fonctionneront plus du tout.

bonjour à toi Microchip (je pensais jamais dire ça un jour...)

Non seulement, comme tu dis les niveaux peuvent varier dans cette plage, d'un fabricant à un autre, mais en plus, il faut savoir qu'ils s'effondrent rapidement, car il s'agit de sources de tension qui ne doivent pas être chargées !
Les cartes mères modernes fonctionnement maximum avec des niveaux TTL (de moins en moins), et surtout avec du 3.3 V ! Donc pour générer les niveaux requis par la norme RS232, il faut passer par des convertisseurs à base de pompe de charge, très économes en énergie et efficaces pour générer une tension donnée, mais absolument pas adaptées à alimenter quoi que ce soit !

Ceci dit, heureusement que certains programmateurs (port parallèle ou JDM) disposent d'une alimentation supplémentaire ! Même si ça reste du bricolage, ces programmateurs sont à privilégier !

[Antoane]

Bonjour,


Me re-voici parce que ça marche, ma belle horloge indique l'heure, tout va bien.
Donc merci à tous pour votre aide, au combien précieuse.

le titre de ton sujet devrait plutôt être "mes problèmes avec un programmateur fait maison...

Et oui, pour l'instant, je n'avait de problème qu'avec mon programmateur... Mais le voici en état de marche, et les problèmes vont, à présent, bel et bien venir de tous ces petits "milles pattes" noirs, qui répondent au doux prénom (ce sont mes préférés )de 16F...

Me voici donc aux prises avec un charmand petit insect, du nom de 877, auquel on a ajouté ce petit suffixe : -A (son groupe-sangain, peut-être ?).
Ma question porte sur sa mémoire, et plus particulièrement sur son EEPROM : sa mémoire "classique", dans laquelle est par exemple stocké ela valeur d'une variable, est volatile (c'est le bon terme ?), càd vidée en cas de coupure de courant ?
En revanche, les valeurs entrées dans l'EEPROM sont conservées n'est ce pas ?
Dans le programme, il est possible de modifier la valeur des variables de cette mémoire.
Et : lorsque j'ouvre IC-Prog, il me montre une "fenêtre", dans laquelle je peut modifier les valeur de l'EEPROM.
Ma question est donc (si le reste n'est pas qualifié de "questions") de savoir comment programmer l'EEPROM ?

Seconde question : toujours à propos de cette sacrée EEPROM :
J'utilise Flowcode pour programme mon mille-pattes, et j'ai une "routine" EEPROM. Par défaut, il me dit qu'elle fait 256octet, mais je peus aussi la paramétrer pour quelle face 1024octet.
Donc, au final, quelle taille fait-elle, dans la bestiole ? Est-ce dans cette mémoire qu'est le programme ?

Merci d'avance pour toutes vos réponses !

[invite03481543]

Bonsoir,

En revanche, les valeurs entrées dans l'EEPROM sont conservées n'est ce pas ?
Dans le programme, il est possible de modifier la valeur des variables de cette mémoire.
Et : lorsque j'ouvre IC-Prog, il me montre une "fenêtre", dans laquelle je peut modifier les valeur de l'EEPROM.
Ma question est donc (si le reste n'est pas qualifié de "questions") de savoir comment programmer l'EEPROM ?

Tu peux en effet modifier des datas stocker en EEPROM de cette façon mais ce n'est pas top.
Le mieux est de les modifier par une routine dédiée à cela, au travers de ton programme, c'est plus efficace et tu peux y inscrire des données sensibles et de manière "lisible".

Seconde question : toujours à propos de cette sacrée EEPROM :
J'utilise Flowcode pour programme mon mille-pattes, et j'ai une "routine" EEPROM. Par défaut, il me dit qu'elle fait 256octet, mais je peus aussi la paramétrer pour quelle face 1024octet.
Donc, au final, quelle taille fait-elle, dans la bestiole ? Est-ce dans cette mémoire qu'est le programme ?

no comment sur flowcode pour ma part.
Un pic possède une taille EEPROM fixée par construction (voir datasheet de ton PIC), cela n'est pas configurable à volonté.

@+

[Antoane]

Bonjour,
Je m'en vais donc écrire dans mon EEPROM avec une jolie petite routine Flowcode... Mais pourquoi "no comment" à son propos ?

Sinon, à propos d'un 80C552 :
dans un pic, chaque instruction du programme prend 2octets de mémoire.
Dans un 80C552 (PPE obligent), est-ce qu'il suffit d'un octet ? la mémoire "programme est donnée en ko, et non en "14bits words" ; un rapport avec la différence RISC (pic, notament) et CISC (le fameux 80C) ? Si quelqu'un pouvait alimenter une led (blanche) avec ses 20mA nominaux pour m'éclairer... (un lien vers la doc du 80C552, qui, je le craint, a eu raison de moi... (la doc, pas le µC) :http://www.kar.elf.stuba.sk/predmety/mmp/pdf/80c552.pdf )


Un autre sinon, à propos des mémoires : J'ai pas assez de mémoire dans mon µC, je compte donc en ajouter une externe. J'ai lû dans ce même forum que les mémoires type 27C, à chagement parallèle (est-ce le bon terme ?) càd avec plein de fils d'adresses et de data, son plus ou moins dépassées, qu'aujourd'hui, on utiliserait plutôt une fonctionnant à l'I²C. Qu'en pensez-vous ?
De même, (tant qu'on est sur l'I²C - je m'y suis m'y il y a deux semùaines, c'est génial. Le bac-blanc de SI portait d'ailleurs dessus, bien que ça n'interesse sans doute pas grand monde), me conseillerez-vous plutôt d'utiliser un gros pic, avec ses 40 pattes, ou plutôt un petit, entouré de PCF8574 (la doc : http://www.nxp.com/acrobat_download/.../PCF8574_4.pdf ) ?
Encore l'I²C, et le bit d'acquiessment : l'esclave appelé doit répondre obligatoirement au coup d'horloge suivant l'envoie de l'adresse, sinon ??? On recommence la "procédure d'appel" ?
enfin, comment être sur que, lorsque la communication va être coupé, tous les maitre ne vont pas prendre la ligne en même temps ?

Merci d'avance,
Bonne soirée.

[invite03481543]

Bonjour,
Je m'en vais donc écrire dans mon EEPROM avec une jolie petite routine Flowcode... Mais pourquoi "no comment" à son propos ?

Une "jolie routine" est un abus de langage avec flowcode.

Sinon, à propos d'un 80C552 :
dans un pic, chaque instruction du programme prend 2octets de mémoire.
Dans un 80C552 (PPE obligent), est-ce qu'il suffit d'un octet ? la mémoire "programme est donnée en ko, et non en "14bits words" ; un rapport avec la différence RISC (pic, notament) et CISC (le fameux 80C) ? Si quelqu'un pouvait alimenter une led (blanche) avec ses 20mA nominaux pour m'éclairer... (un lien vers la doc du 80C552, qui, je le craint, a eu raison de moi... (la doc, pas le µC) :http://www.kar.elf.stuba.sk/predmety/mmp/pdf/80c552.pdf )

Les différences entre PIC et 8051 (le 80C552 est une version du 8051 avec un coeur I2C) sont multiples, le mode de fonctionnement est très différent également.
L'un (le PIC) possède un jeu d'instructions réduit, ce qui permet de rapidement apprendre à s'en servir, en contre partie il faut souvent un code assembleur plus lourd pour obtenir un équivalent de programme de 8051 qui lui possède un jeu d'instructions étendu plus long à apprendre mais plus concis en terme de code généré.
Ce sont 2 approches différentes également en terme d'architecture interne au niveau des bus, des temps de cycle par instruction, etc.
Bref ce sont 2 approches différentes, en faire ici un comparatif complet serait assez long et sujet à polémique comme d'habitude, donc le mieux est de te faire ta propre opinion en consultant les nombreux cours et sites propres au 2 techno RISC et CISC.

Un autre sinon, à propos des mémoires : J'ai pas assez de mémoire dans mon µC, je compte donc en ajouter une externe. J'ai lû dans ce même forum que les mémoires type 27C, à chagement parallèle (est-ce le bon terme ?) càd avec plein de fils d'adresses et de data, son plus ou moins dépassées, qu'aujourd'hui, on utiliserait plutôt une fonctionnant à l'I²C. Qu'en pensez-vous ?
De même, (tant qu'on est sur l'I²C - je m'y suis m'y il y a deux semùaines, c'est génial. Le bac-blanc de SI portait d'ailleurs dessus, bien que ça n'interesse sans doute pas grand monde), me conseillerez-vous plutôt d'utiliser un gros pic, avec ses 40 pattes, ou plutôt un petit, entouré de PCF8574 (la doc : http://www.nxp.com/acrobat_download/.../PCF8574_4.pdf ) ?

Pour ma part j'ai longtemps utilisé le 80C552 qui était à l'époque très intéressant pour ce fameux coeur I2C intégré, aujourd'hui la majorité des PIC mid-range possède un tel interface I2C.
Selon l'application on peut soit utiliser des petits PIC en maitre-esclave ou en multi-maitres ou encore seul avec des périphériques I2C dédiés à la gestion de l'heure, des mesures AD, DA, résistances variables,etc.
C'est une question de rationalité plus que de possibilité.

Encore l'I²C, et le bit d'acquiessment : l'esclave appelé doit répondre obligatoirement au coup d'horloge suivant l'envoie de l'adresse, sinon ??? On recommence la "procédure d'appel" ?
enfin, comment être sur que, lorsque la communication va être coupé, tous les maitre ne vont pas prendre la ligne en même temps ?

L'I2C est régit par un protocole, la gestion des conflits est prévu.
Il faut lire ce protocole avant de développer quoique ce soit pour bien comprendre les mécanismes à mettre en oeuvre ensuite.
http://www.technologuepro.com/microc...ur/Bus_I2C.htm

Le mieux étant la spec technique du concepteur Philips sur l'I2C que je te joins.
@+

[Antoane]

Bonsoir,

Une documentation très intéressante(chia*te et intéressante n'étant pas contradictoires ), merci beaucoup.
Cependant, il me reste quelques questions :

Page 16 :

Obviously, devices with a 0 to 100 kbit/s I2C-bus interface cannot be incorporated in a fast-mode I2C-bus system because, since they cannot follow the higher transfer rate, unpredictable states of these devices would occur.

Pourtant :

they [slaves] can then prolong the LOW period of the SCL signal to slow down the transfer.

Donc je ne vois pas pourquoi devices with a 0 to 100 kbit/s I2C-bus interface cannot be incorporated in a fast-mode I2C-bus system , d'autant que d'après le reste du texte le "fast-mode" semble compatible avec le standart ! je ne comprend pas.



Concernant le PCF8574 :le courant d'entrée de chaque ligne, sda et scl, c'est le "leakage current", soit par exemple sur le PCF8574 1µAmax ?

Sinon, le maximum allowed input current through protection diode, il s'agit du courant maximum pouvant circuler dans la diode de protection cablée (dans le composant) anode à l'entrée et cathode au Vcc (diode de "clamping", leur vrai nom ?) ?



Le bus est limité à une capacité de 400pF, sinon quoi
D'ou vient cette capa parasite, principalement ? Un PCF8574, par exemple, c'est que 1pF, pas grand chose.... Alors ? les fils ? le PCB ????



Merci beaucoup pour ton aide, on ne plus enrichissante !!!

[invite03481543]

Il existe assez peu de composants I2C qui peuvent accepter le Fast Mode (FM) à 400Kbits/s et encore moins qui tournent avec le dernier mode le Fast Mode+ (FM+) -> 1Mbits/s.

Par exemple si on prend la RTC PCF8583, elle ne peut tourner qu'avec un bus à 100Kbits/s, c'est le lot des composants sortis entre 1982 et 1996.
Alors que la RTC DS1631 plus récent accepte le FM.

Le FM est utilisable aussi sur des ADC 12 bits performants comme le ADM1176 de chez Analog Devices.

Le FM+ est surtout intéressant pour les RAM et E²PROM de grande taille ou des circuits évolués récents (multiplexeurs ou adaptateur USB-I2C).

L'évolution du protocole I2C étendu reste compatible avec les circuits anciens à condition de descendre la vitesse du bus lorsqu'on veut dialoguer avec eux.

Le bus est limité à 400pF pour permettre un temps de monté (rise time) restant dans le gabarit soit 1µs en mode standard et 300ns en mode Fast.
Cette capacité est dûe essentiellement aux capa d'entrée des circuits, qui étant en parallèles (SCL et SDA) s'additionnent, et à la capa du PCB.
Lorsque une liaison filaire est réalisée c'est la capa du câble qui devient prédominante il faut donc prendre en considération sa capa et sa résistance linéïque et adapter le pull-up en conséquence.
Le plus souvent on utilise des drivers de ligne (I2C bus Expander) pour abaisser l'impédance de ligne en attaquant avec des courants plus forts, comme avec le 82B715 par exemple.

[Antoane]

Une réponse parfaitement claire, merci beaucoup.

Une petite question à son propos, le PCF8574 : j'ai un schéma dans lequel le pin P0 est reliée à la sortie d'un ULN2003 (avec résistance de pull-up), et P1 en entrée d'un autre ULN2003, avec également une résistance de tirage. Mon soucie vient de ce cablage : si je lui dit : écrit XXXXXX10₂, et que la sortie de mon premier ULN2003 (donc cablée à P0) est à 1, y'aura pas un problème ? ou alors, est-ce que mon µC doit d'abord lire P0, et agir en conséquence ? Mais dans ce cas, si P0 change d'état entre temps ? Et du coup, lorsqu'il lit P0, P1 se retrouve polarisé par ma pull-up !

Bonne soirée !

PS : j'adore ta signature !

[invite03481543]

j'ai un schéma dans lequel le pin P0 est reliée à la sortie d'un ULN2003 (avec résistance de pull-up), et P1 en entrée d'un autre ULN2003, avec également une résistance de tirage. Mon soucie vient de ce cablage : si je lui dit : écrit XXXXXX10₂, et que la sortie de mon premier ULN2003 (donc cablée à P0) est à 1, y'aura pas un problème ? ou alors, est-ce que mon µC doit d'abord lire P0, et agir en conséquence ? Mais dans ce cas, si P0 change d'état entre temps ? Et du coup, lorsqu'il lit P0, P1 se retrouve polarisé par ma pull-up !

Le PCF8574 peut être lu en 'polling' (scrutation) ou peut se manifester par le biais de son interruption INT qui va signaler un changement d'état au µC sur une entrée d'interruption.
Le µC va alors aller lire le PCF pour recueillir les datas.
Pour écrire dans le PCF sur une sortie particulière sans altérer les autres sorties il faut que tu fasses un masque pour écrire uniquement sur le Px de ton choix.

Par exemple si tu veux écrire un 1 sur P1 que l'on suppose à 0 mais ne pas interférer sur les autres PORT Px tu peux écrire:

Data à envoyer = PORT_lu | 00000010

Si un portx est à 1 ou 0, en faisant un OU tu ne modifieras pas son état et seul P1 passera à 1.

Un exemple:

supposons que l'état du PCF8574 soit à 00110001 et que tu veuilles mettre P1 à 1:

00110001 | 00000010 = 00110011 après écriture.

En espérant avoir bien compris ta question.
@+

[Antoane]

Bonjour,
c'est exactement ça !
Ici, tu proposes de faire le masque avec un OU, est-ce possible avec un XOR ? Il me semble l'avoir lû, mais je ne retrouve plus comment le faire...


Existe-il une "rêgle", ou une formule pour connaître la capacité d'un bus en fonction de la façon dont sont placés les fil les un par rapport au autres (en nappe dans le sens précaunisé par Philips ou torsadé, blindé, non blindé...), et la longueur du bus ? Sinon, aurais-tu une abaque ? (je sais que ton disque-dur regorge de ce type de document )

Merci !

[Antoane]

rebonsoir,

supposons que l'état du PCF8574 soit à 00110001 et que tu veuilles mettre P1 à 1:

00110001 | 00000010 = 00110011 après écriture.

Et pour mettre P0 à 0 ?

[invite03481543]

rebonsoir,

Et pour mettre P0 à 0 ?

Là tu utilises un XOR.
supposons que l'état du PCF8574 soit à 00110001 et que tu veuilles mettre P1 à 1 et P0 à 0 (sans toucher au reste):

00110001 ^ 00000010 = 00110011 après écriture.

[invite03481543]

Existe-il une "rêgle", ou une formule pour connaître la capacité d'un bus en fonction de la façon dont sont placés les fil les un par rapport au autres (en nappe dans le sens précaunisé par Philips ou torsadé, blindé, non blindé...), et la longueur du bus ? Sinon, aurais-tu une abaque ? (je sais que ton disque-dur regorge de ce type de document )

Merci !

Ben non ça dépend du câble.
Le fabriquant du fil donne l'impédance de son câble, il faut le demander sinon.
Perso j'utilise du câble téléphonique plat 6 conducteurs avec des RJ en bouts dont la capacité est de 100pF/m.
http://www.transistek.com/catalogue/..._30m_21558.php

[Antoane]

Ben non ça dépend du câble.
Le fabriquant du fil donne l'impédance de son câble, il faut le demander sinon.

L'impédance ??? quel rapport ? ce n'est pas une "sorte de résistance en alternatif, dépendant de la fréquence" ?

[invite03481543]

Tes signaux sont alternatifs pas continus donc on parle d'impédance de ligne (R,L et C).

[Antoane]

Ok, merci beaucoup.

[philr12]

Bonjour ,

voir aussi l'exellent site de Mr Bigonoff ( hébergé par abcd électronique )
http://www.abcelectronique.com/bigon....php?par=b782f

chargr son cours en bas de page ; le traité sur le protocole I2C se trouve à la page 357

[Antoane]

Bonjour,
Une question sur les liaisons (encore !).
Voilà, j'ai un µC implété sur une platine, et il doit contrôler deux afficheurs 7segment, situés à une distance résonable (50 à 100m). Mais, comment ? Quelle liaison filaire (si, si.) utiliser ?
J'aimerais bien utiliser l'I²C (maintenant que je commence à la connaître :s: ), mais ça fait un peu loin ! Sinon, la RS232, ou 485, mais il faut un autre µC au bout... (à moins qu'il n'existe un composant du genre 8574 pour RS485 ?), le bus 8fils (4fils de data, 2 d'adresse - un par afficheur 7seg-, et deux pour l'alim...) mais ça fait beaucoup de fils...
Que faire ?

PS : Je m'en vais donc jeter un oeil sur "l'I²C d'après Bigonoff".
Bonne après-midi.

[invite03481543]

Bonsoir,

le RS-485 est un bon choix pour cette distance, l'I2C lui est exclus.
Il te faut 4 fils (GND, VCC, TX et RX), un petit µC sur place et un transceiver genre MAX487E pour adapter la liaison.
Ou une liaison sans fils à condition d'avoir sur place l'énergie disponible.
@+

[Antoane]

Bonjour,
Hélas ! trois fois hélas... pas de source d'énergie sur place, il faut la transporter depuis la platine principale.

Est-il vraiment imposible de se débarasser du µC ?
Serait-il possible de "fabriquer" un double émetteur RS485, plutôt que d'utiliser deux MAX487 ? il émettrait la ligne du bus I²C et deux comparateurs en lecture au bout ? Un lm358, par exemple ? et un PCF8574 pour décoder le tout ? un schéma valant mille mots...
c'est le µC en plus qui m'embête....
Mais ça fait un peu (trop) bricolage...

Une autre idée ?


Sinon, pour faire faire au programme une courte pose (quelques centaines de ns), par exemple pour respecter le temps pendant lequel un signal doit rester à l'état haut pour un autre composant, une solution "ésthétique" existe-elle ?
Ce que j'ai fait, jusqu'alors, ça a été d'effectuer des instructions, sans aucun intéret au niveau du programme. Avec un quartz à 20MHz, par exemple, un instruction prend 4 coups d'horloge, soit 200ns.
Un calcul compte-il pour une instruction ? demande-il donc 4 coups d'horloge ? parceque dans ce cas, var1 = var1, et hop ! 200ns de passées. Existe-il donc une solution plus élégante ? un delaiµs ou delains existe-il ?

Merci d'avance !!!

[invite03481543]

Bonsoir,

Un µC en bout est nécessaire, un µC n'est rien de plus qu'un composant programmable dont le prix en comparaison du service et de la simplicité est bien faible.

un nop suffit pour faire une tempo équivalente à un coup d'horloge soit 200ns.
Tu peux mettre plusieurs nop en cascade pour augmenter ce temps.

[philr12]

Bonsoir à tous

effectivement pas d'I²C pour plus de 4-5 mètres. Sur une distance pareille attention aux parasites et aux pertes. Je n'y connais pas plus sur ce sujet.
Pour faire patienter le PIC tu peux aussi utiliser les timers ( y'en a deux bien souvent le 0 et le 1 )

[Antoane]

Merci beaucoup pour vos réponses... Va pour un second petit µC, alors...

Bien reçu pour le nop, c'est plus élégant qu'un calcul inutil...

Une question à propos des timers : est-il possible de les "cascader", en utilisant les pin T0CK , par exemple, ou dans le logiciel ?
Aussi, pourquoi est-ce qu'on utilise pas plus souvent l'oscilateur interne du pic ? ça évite de mettre un quartz, au combien dispendieux, et ça libère 2pin - et au cours actuel du pin... ça vaudrait peut-être le coup !
Dans ce cas, est-ce qu'il faut quand même 4 oscilations pour effectuer une instruction ?

Merci d'avance.

Bon dimanche.