Communication entre un PIC16F84 et un motorola hc05 avec protocol i2c

[LABTOOL48]

salut tlm
je suis un debutan et j'ai besoins de votre aide

comment je peux changer le contenu de l'eeprom intern de hc05 via un pic16f84, en protocol i2c disent que chaque composents i2c a une address slave je l'ai pas trouvé dans le datasheet ch05

et par exemple si je veux changer la valeur 4D qui se trouve dans l'adresse 04'h dans l'eeprom intern est-ce qu'il faut envoyer a l'adresse 04'h ou 0304'h car dans le datasheet hc05l28 les données de l'eeprom intern commence par l'adresse 300 et voila le fichier pdf
pour hc05l28
http://codedradio.info/museum/MCU/MC...-705L28_TD.pdf

merci d'avance pour votre aide
-----

[Jack]

je l'ai pas trouvé dans le datasheet ch05

Elle est définie dans le registre MADR

Pour le reste, tu es sur de bien savoir ce que tu veux faire? Pour modifier l'eeprom interne du hc05 par l'I2C, il faudra que dans le HC05 il y ait un programme qui détecte l'arrivée d'une trame I2C envoyée par le pic, en extrait l'adresse à laquelle il faut programmer l'eeprom et la donnée qu'il faut y mettre. Le HC05 devra donc également avoir un bout de code capable d'écrire dans son eeprom.

Pour les adresses de l'eeprom, il est clair qu'elles commencent bien en $300.

A+

[polo974]

Il faut que le code du hc05 mette l'i2c en slave et réponde au requêtes i2c.

En gros un hc05 pas codé pour ne répondra pas (sauf si... (voir PS))

Dans ton appli, il faut que le code du hc05:
mette l'i2c en slave et positionne l'adresse de base du hc05 sur le bus i2c puis
interprète les données reçues suivant un protocole à définir pour écrire en eeprom...

Bref, tout sauf direct...

PS: s'il s'agit de programmer l'eeprom juste une fois de temps à autre (paramétrage, configuration initiale...) alors que le code du hc05 est inaccessible, il faut regarder coté rambootloader pour faire ce qui a été dit ci dessus, mais c'est encore plus lourd...
source d'inspiration:
http://www.freescale.com/files/micro...34.pdf?fsrch=1

industrialisé ici:
http://www.etlweb.com/prod_prog_mc68hc05l28.html
avec même le soft et la doc, donc une bonne lecture et analyse et ça roule...

PPS: de la même façon, il est possible de lire la rom pour essayer d'y trouver le routines "qui le feraient", mais ça commence à ressembler à "comment déplomber un truc-bidule"...

édit: oups, dépassé par jack pendant que je fouillais

[LABTOOL48]

Elle est définie dans le registre MADR

ça veut dire que l'address slave définie par l'utilisateur dans le registre MADR donc l'adresse soit de 00'h a FF'h ou meme pas car le bit 0 de resistre MADR rest toujour a zero et si c'est le cas est-ce que je peux envoyer au hc05 les 255 adresses poussible et tester le bit ACK ??

Pour les adresses de l'eeprom, il est clair qu'elles commencent bien en $300

ce cas quand l'on doit programmer l'eeprom avec un programmateur mais pas comme vous avez dis ici

il faudra que dans le HC05 il y ait un programme qui détecte l'arrivée d'une trame I2C envoyée par le pic, en extrait l'adresse à laquelle il faut programmer l'eeprom et la donnée qu'il faut y mettre. Le HC05 devra donc également avoir un bout de code capable d'écrire dans son eeprom.

donc la ça depon le programme qui détecte l'arrivée d'une trame I2C envoyée par le pic et ce programme a surement des routines pour lire/ecrire dans l'eeprom intern et est-ce que dans ce cas le premier octet le l'eeprom intern se trouve a l'adresse 00'h comme le pic16f84 ???

[A voir en vidéo sur Futura]

[LABTOOL48]

Il faut que le code du hc05 mette l'i2c en slave et réponde au requêtes i2c

pas moi qu'il a fait le code du hc05 mais comme vous avez dis qu'il faut que le code du hc05 mette l'i2c en slave,donc comment je peux communiquer avec ce code si le hc05 n'est pas encore en mode slave et pour quoi je serais besoin de ce code si le hc05 peut communiquer en mode master ??

[Jack]

ça veut dire que l'address slave définie par l'utilisateur dans le registre MADR donc l'adresse soit de 00'h a FF'h ou meme pas car le bit 0 de resistre MADR rest toujour a zero et si c'est le cas est-ce que je peux envoyer au hc05 les 255 adresses poussible et tester le bit ACK ??

Tout dépend du code dans le HC05. Si le programmeur n'a pas prévu de gérer l'I2C en mode slave, le HC05 ne renverra jamais le moindre ack

ce cas quand l'on doit programmer l'eeprom avec un programmateur mais pas comme vous avez dis ici

Je ne comprends pas ce que tu veux dire.

ce programme a surement des routines pour lire/ecrire dans l'eeprom intern

rien n'est moins sur.

est-ce que dans ce cas le premier octet le l'eeprom intern se trouve a l'adresse 00'h comme le pic16f84 ???

Je ne connais pas bien les pics, mais c'est plutôt la rom programme (la flash pour les version PICxxxFxxx) qui commence à l'adresse 0 et pas l'eeprom. Dans le HC05, ne pas confondre l'eeprom avec la USER ROM dans laquelle on met le programme.

donc comment je peux communiquer avec ce code si le hc05 n'est pas encore en mode slave

Tu ne pourras pas.

pour quoi je serais besoin de ce code si le hc05 peut communiquer en mode master ??

Sa son I2C est configurée en master, c'est lui qui décidera de commencer une transmission, pas le PIC.

A+

[polo974]

Bon, il est clair que le programme du HC05 est inconnu et non modifiable.
Que le but est de modifier l'EEPROM interne (ça sent le déplombage de mobile ).

Donc:
Essayer d'envoyer des trame i2c risque:

• pas de réponse (ouf, rien de cassé!)
• réponse inattendue (effacement par exemple de paramètres de calibrage de l'appareil contenus dans un coin de l'EEPROM, argh, c'est foutu...)

Donc, ne pas jouer avec ça (en tout cas pas tout de suite, comme ça à froid).

L'eeprom n'est pas liée à l'i2c, ce n'est pas une 24c04 (par ex), ce n'est pas parce qu'il y a les 2 sur le micro, qu'ils "marchent ensemble".

Question adresses:
l'adresse sur le bus i2c n'a rien a voir avec l'adresse interne du micro (c'est un peu comme si on cherchait une relation entre les numéros du bvd Maréchal Leclerc et ceux de la place de l'Etoile).

Rien ne prouve qu'il est prévu dans le code actuel et inconnu du hc05 d'écrire dans l'eeprom depuis le bus i2c (j'ai l'impression de me répéter...).

Il reste donc le PS et PPS de mon message précédent pour ouvrir une voie... mais inutile de passer par l'i2c dans ce cas.

[LABTOOL48]

Tout dépend du code dans le HC05. Si le programmeur n'a pas prévu de gérer l'I2C en mode slave, le HC05 ne renverra jamais le moindre ack

Je ne comprends pas ce que tu veux dire.

rien n'est moins sur.

Je ne connais pas bien les pics, mais c'est plutôt la rom programme (la flash pour les version PICxxxFxxx) qui commence à l'adresse 0 et pas l'eeprom. Dans le HC05, ne pas confondre l'eeprom avec la USER ROM dans laquelle on met le programme.

Tu ne pourras pas.

Sa son I2C est configurée en master, c'est lui qui décidera de commencer une transmission, pas le PIC.

A+

je suis d'accord avec tous ce que vous dis et que le code du hc05 celui qui tourne le hc05 en mode slave pour laisser les autres maitres communiquent avec lui et dans mon cas la le hc05l28 connecté au resau multimaitre utilisent meme bus i2c et le code du hc05 gérer le bus i2c en mode slave , je veux seulement un connaisseur qu'il a deja fait la programmation des hc05 et utilise la partie i2c parce que le code du hc05 pour recever les données qui vient du l'exterieur n'est pas compliquer pour un connaisseur car ce code liér a des registres qui a des adresses fix et des passages obligatoir comme par exemple dans les routines de pic pour lire/ecrire dans la memoire intern, et tous ça est indiquer dans le datasheet et l'utilisateur na pas besoin que des quelques variabes pour sauver la donnée qui vient du bus i2c et puis il la transfirer dans l'eeprom intern et dans meme adresse comme induqué dans le datasheet c'est tout et que ce soit le mechanisme de code du hc05 il ne doit jamais sauter un passage obligatoire ni changer une aldresse d'un registres ou de l'eeprom intern


desolé pour la langue

[LABTOOL48]

Bon, il est clair que le programme du HC05 est inconnu et non modifiable.
Que le but est de modifier l'EEPROM interne (ça sent le déplombage de mobile ).

oui et le bit de security de hc05 est active et impossible de lire la rom

Donc:
Essayer d'envoyer des trame i2c risque:

pas de réponse (ouf, rien de cassé!)
réponse inattendue (effacement par exemple de paramètres de calibrage de l'appareil contenus dans un coin de l'EEPROM, argh, c'est foutu...)
Donc, ne pas jouer avec ça (en tout cas pas tout de suite, comme ça à froid).

je suis la ni pour jouer ni presser mais je suis la pour chercher de l'aide et pour ne pas faire ce travaill a froid

L'eeprom n'est pas liée à l'i2c, ce n'est pas une 24c04 (par ex), ce n'est pas parce qu'il y a les 2 sur le micro, qu'ils "marchent ensemble".

merci tlm le sait que ce n'est pas une eeprom 24cxx et merci encore de ne pas parler de rien si tu na pas une idée

[LABTOOL48]

s'il vous plais regarder le register (MADR) sur la page 86
et aussi le bit de MAAS dans register (MSR) sur la page 88

je pense qu'il disent que si le hc05 recever meme adresse définie dans le registre (MADR) le bit MAAS dans le register (MSR) se diclanche automatiquement pour selectionner le mode slave

[polo974]

s'il vous plais regarder le register (MADR) sur la page 86
et aussi le bit de MAAS dans register (MSR) sur la page 88

je pense qu'il disent que si le hc05 recever meme adresse définie dans le registre (MADR) le bit MAAS dans le register (MSR) se diclanche automatiquement pour selectionner le mode slave

On a vu tout ça, le problème est qu'on ne sait pas ce que fait le hc05 sur le bus i2c.
On ne peut pas le deviner, on ne peut à priori pas le lire.
Il faut donc faire SANS LUI.

Donc LA SEULE SOLUTION est de télécharger une bootstrap dans la ram pour pouvoir accéder à l'eeprom.
Et je répète donc:

PS: s'il s'agit de programmer l'eeprom juste une fois de temps à autre (paramétrage, configuration initiale...) alors que le code du hc05 est inaccessible, il faut regarder coté rambootloader pour faire ce qui a été dit ci dessus, mais c'est encore plus lourd...
source d'inspiration:
http://www.freescale.com/files/micro...34.pdf?fsrch=1

industrialisé ici:
http://www.etlweb.com/prod_prog_mc68hc05l28.html
avec même le soft et la doc, donc une bonne lecture et analyse et ça roule...

Ce n'est pas une mince affaire
et je ne parle pas pour rien, sauf si personne n'écoute, bien sûr...

[LABTOOL48]

On a vu tout ça, le problème est qu'on ne sait pas ce que fait le hc05 sur le bus i2c.
On ne peut pas le deviner, on ne peut à priori pas le lire.
Il faut donc faire SANS LUI.

je vais essaier de t'expliquer mieux pour que tu puiss deviner ce qu'il fait le hc05 sur le bus i2c, je connais quelques amis de net qui ont a fait déja ce travaille, donc on est maintenant sur que le hc05 est programmé avec les deux routines lire/ecrire dans l'eeprom interne et aussi pour communiquer sur le bus i2c en mode slave et d'autres code biensur pour faire une relation entre bus i2c et les deux retines lire/ecrire, c'est la le problem car moi je n'ais jamais fais la programmation des hc05,et la je suis daccord avec toi qu'on ne peux pas imagine le code du hc05 et peut étre que si j'envoyer l'adresse sur bus i2c pour l'accer a l'eeprom le code du hc05 lire catte
adresse pour executer d'autre chosse , je sais tres bien tous ça et daccord a100% avec vous , je veux quel qu'un qui connais bien les registre du bus i2c de hc05 pour me donner des bonnes etapes a suive

1 > est-ce que dans ce cas la je peux envoyer les 255 adresses poussible et tester le bit d'ACK ??

2 > est-ce que le registre (FDR) n'est pas utiliser que en mode master car le pic celui qui génère le signal d'horloge sur SCL ??

Donc LA SEULE SOLUTION est de télécharger une bootstrap dans la ram pour pouvoir accéder à

l'eeprom.
Et je répète donc:

non tu ne peux pas booter le mcu si le bit de securty est active et meme si tu peux le booter tu dois perdre tous les données de l'eeprom interne

Ce n'est pas une mince affaire
et je ne parle pas pour rien, sauf si personne n'écoute, bien sûr...

maitenant je vous ecoute bien et je me sens que tu me parle serieux

[polo974]

Ok, donc ce hc05 est une boite noire, dont on sait qu'il y a un moyen pour accéder à l'eeprom.
Toute la doc interne du hc50 ne sert donc à rien.
Il faut "juste" deviner le protocole mis en place pour accéder à cette eeprom.

Et bien, bon courage, car les possibilités sont très nombreuses même pour un protocole sans la moindre sécurité, alors si en plus, ils ont mis un embryon de système de sécurité, c'est quasi impossible. Il faudrait commencer par pouvoir observer des communications existantes afin d'en déduire le protocole adopté.

[LABTOOL48]

merci pour la repose

j'ai fai un petit code dans la pic16f84 avec switchdip connecté au "PORTB" pour enter les 255 adresses plus led pour voir si le bit d'ACK est OK j'ai testé et j'ai touvé l'adresse slave et j'ai changé apres le code du pic pour fixé l'adresse slave et decaler le switchdiP pour le deuxieme octet exemple

1: "1101000x"b ; adresse slave
2: "xxxxxxxx " ; movf portb,w et w>to>i2c
3 "00000100" ; 04'h adresse pour l'eeprom interne
2 "00000000" ; 00'h l'octet a envoyer dans l'eeprom

mais ça prond de temps et je ne sais meme c'est s'il me faut seulement un octet pour faire l'appelle de la routine d'ecrire ou plus,
et dans le pic16f84 je n'ai qu'un seul port de huit bits si tu peux m'aider pour faire deux conteur avec 256 *256 boucle a la place de switchdip et de faire le teste a chaque boucle

car les possibilités sont très nombreuses même pour un protocole sans la moindre sécurité

oui mais je sais ce qu'il ya dans les premiers adresses de l'eeprom interne et si on fait les deux conteur soit pour lire l'eeprom et tester le contenu de l'eeprom sur l'adresse 00'h et c'est si le contenu de l'adresse 00'h est ok on sauvegarde l'adresse d'acces a l'eeprom

voici le contenu de l'eeprom sur la premiere ligne 00.06.01.09.4D