bonjour à tous,
suite à une discution sur un autre sujet sur ce forum, je cherche à utiliser l'i2c avec un pic qui ne l'a pas d'origine, pour cela je cherche un emulateur qui permettrait d'utiliser 2 broches pour communiquer en i2c
je cherche donc un programme en C qui puisse etre utiliser avec le compilateur de ccs et ajouter l'utilisation de l'i2c
Bonjour
Dans le répertoire Drivers de CCS il y a une serie de "serial EEPROM Functions" dont au moins la première la 2401.C repose sur une communication via I2C. Cette fonction ne semble pas faire appel à un hardware spécifique A vérifier
je l'ai vu mais je ne comprends pas bien comment ça fonctionne, je suis débutant
cette fonction utilise directement le protocole i2c, il faut donc que le pic possede deja un bus i2c pour pouvoir s'en servir, hors moi ce que je cherche, c'est justement emuler un protocole i2c sur un pic qui n'a pas ce bus
Salut,
l'avantage avec un hardware I2C embarqué dans le µC c'est que tu n'as pas à te soucier de gérer les mécanismes du protocole I2C, il te suffit d'appeler les routines dédiés à la lecture et à l'écriture pour E²PROM en mode I2C.
Comme te le disais Jack dans l'autre topic que tu as ouvert, la gestion par soft de l'I2C nécessite sa bonne connaissance pour avoir de bons résultats.
Il est donc plus commode de choisir un PIC avec I2C embarqué, ce qui te permet d'utiliser les E²PROM série allant de 1Kb à 1Mb au moins.
Si ton appli ne nécessite pas beaucoup d'octets en E²PROM, tu peux aussi choisir un PIC avec E²PROM interne, c'est alors encore plus simple.
je comprends bien mais il n'existe pas de pic12Fxxx avec bus i2c, je vais vous expliquer ce que je veux faire:
je veux utiliser des pics tres on marché pour servire d'interface entre un recepteur et le pic principal, de sorte que celui-ci ne soit pas bloqué par l'attente du signal, le 12Fxxx recoit regulierement des infos et les stocke dans une eeprom (ou autre, je ne sais pas) et le pic principale va chercher l'info quand il en a besoin, ce qui lui permet d'avoir la donnée la plus récente
mais si vous trouvez des pics avec horloge interne pas cher (1 à 2 €, voir 3) avec bus i2c et facilement trouvable en france, je suis preneur
ou une autre approche pour réaliser ce que je veux faire
Salut,
mon conseil:
soit tu implantes les routines assembleur que tu trouveras sur le site MICROCHIP et qui sont fiables, soit tu t'inspires du lien suivant:
http://www.piclist.com/techref/microchip/i2c-eeprom.htm
Dans les 2 cas tu auras besoin d'un PIC avec un minimum de place pour y loger ce code malgré tout conséquent.
Hello,Envoyé par spilz
quel est le volume des données à stocker ? il s'agit juste de conserver la dernière valeur ?
ton PIC devra être master I²C pour dialoguer avec le périphérique et slave I²C pour dialoguer avec l'hôte
pour être slave I²C il faut obligatoirement un MCU avec l'interface intégrée en hardware.
l'autre liaison en master pourra être gérée en soft.
A+,
Bruno
Pour quelles raisons ?pour être slave I²C il faut obligatoirement un MCU avec l'interface intégrée en hardware.
l
A+
Hello,
pour une seule raison : en mode slave un dispositif I²C est à la disposition d'un master, qui peut initier une condition de départ de transmission (non négociable) à n'importe quel moment.
pour ne rater aucune transmission il faut donc que la gestion I²C du slave se fasse par hardware, afin que celui-ci prévienne le soft par interruption qu'une transmission démarre.
A+,
Bruno
Bonsoir
Réponse au Post #6
Je viens de retrouver une commande de mémoire RAM via I2C utilisant un PIC628 qui ne possède rien de spécifiquement I2C
Cette appli est basée sur les Routines écrites par Alain Reboux
J'ai ensuite migré vers du C en utilisant le compilateur FED toujours avec un 628
En plus de la mémoire I2C il y a un processeur stereo I2C, des 8574 I2C pour gérer des platine à boutons et un moteur pas a pas pour un potentiomètre motorisé + une sortie série pour 2 PIC afficheurs
avec un 628 de qq Euros, pas un 648 qui a 4K de Mémoire
Tu ne réponds pas vraiment à ma question puisque tu disais dans un post précedent que l'interface devait être intégrée en hardware, ce qui signifie que le µC doit posséder des registres spécialisés I2C.pour une seule raison : en mode slave un dispositif I²C est à la disposition d'un master, qui peut initier une condition de départ de transmission (non négociable) à n'importe quel moment.
pour ne rater aucune transmission il faut donc que la gestion I²C du slave se fasse par hardware, afin que celui-ci prévienne le soft par interruption qu'une transmission démarre.
C'est complètement différent d'une gestion par interruption qui ne nécessite pas forcément ces registres spécialisés.
A+
Hello,
la réponse à ta question "pour quelles raisons il faut une gestion HW pour le mode slave I²C" est que sans module I²C la gestion des signaux du bus par le PIC ne présentera aucune garantie de fiabilité : il suffit que le maitre commence à transmettre pendant que le PIC fait autre chose pour que la transmission échoue.
la gestion HW du module I²C slave est associée a une interruption, mais pas n'importe laquelle :
lorsque le module I²C du PIC est correctement configuré, le registre à décalage est rempli sans intervention logicielle et une interruption est émise lorsque l'adresse est reconnue.
autrement dit, dans le cadre de ce topic, l'implémentation d'une interface de bufferisation I²C sans interface HW de gestion slave présente un risque de perte d'information.
c'est peut-être déjà pour cette raison que l'opérateur pense qu'il a besoin d'un PIC supplémentaire pour buffériser, auquel cas la bufférisation ne sera d'aucun secours.
A+,
Bruno
je comprends ce que tu veux dire, mais au vu de l'application, en déclenchant une interruption sur variation de SDA ou de SCL, il doit bien y avoir moyen de ne louper aucun bit de la trame.
A+
Sans doute, mais je préfère conseiller à l'opérateur de choisir un MCU adapté, plutôt que de l'inciter à se lancer dans une longue bidouille pour un résultat hasardeux
A+,
Bruno
On est bien d'accord, mais visiblement spilz n'a pas le choix.
A+
pour ca il suffit d'utiliser le port B avec interruption, des qu'il recevra une info, une interruption sera generé tout comme avec un module I²C en hard. C'est largement faisable un I²C en soft, mais il est vrai qu'il est bien plus facile d'utiliser un PIC avec I²C intergré.
Pour info, j'ai deja trouvé sur le net, un type qui a fait un USB en soft sur un 8051, alors l'I²C a coté, c'est du caca. Domage, j'ai plus l'adresse, mais si quelqun le trouve ca m'interresse....
bonne cotinuation........
Salut spilz,
je voudrais savoir si tu as réussi, à faire ton émulation d'i2c esclave.
Je suis actuellement en train d'essayer de faire la même chose sur un pic 16f627.
J'ai déja des problèmes pour repérer le signal de départ (SDA passe à0 et SCL rest à 1). Alors récupérer l'adresse, renvoyer un Ack et récupérer les data... c'est pas gagné, merci pour ton aide!
