Bonjour,
Je fais tourner un afficheur LCD avec un 18f452, il tourne niquel !
Mais quand je le fais tourner sur un 18f252, il pante à l'initialisation (pour ceux qui connaissent : il est toujours occupé : LCDBusy )
Je voulais savoir si c'est possible que ça soit une erreur dû au changement de PIC. Pourtant c'est casiment les mêmes.
"Mon PIC18f452 est sur le PICDEM 2 Plus de Microchip et le PIC18f252 tourne sur une plaquette semblable mais faite maison(mais elle fonctionne)"
Il manque quelques informations, comme la fréquence utilisée (la même sur les 2), le port utilisé pour commander l'afficheur par chacun des PICs, utilisation du même logiciel sur les 2 PICs (si non quels sont les différences?).
Il plante sur la phase d'initialisation de l'écran? à quel moment? (référence de l'afficheur) comment fait tu la connection entre l'afficheur et le 18f252? deux écrans différents ou reprise de celui du PICDEM2? (vérifie qu'il ne te manque pas de résistance de pullup ou ce genre de truc sur ton montage)
Bonjour,
Oui la fréquence est la même et elle est de 4Mhz,les ports, je les ai oubliés tient ! le logiciel, c'est le même, les deux LCD sont identiques (compatible HD44780).Pour la connection entre l'afficheur et le 18f252, c'est le même que le PICDEM2.
Bon bah je vais changer les port de l'afficheur déja
Et ben j'ai encore de la route pour être un pro
Merci encore
A bah voila !
Encore merci umfred (le sauveur des débutant)
Mais j'ai encore une petite question :
Un NOACK peut être activé par quoi ? Car mon programme écrit, il y a pas de probléme, mais quand il vien lire la mesure qu'a effectuer le capteur, à la fin de l'envoi de l'adresse, l'esclave envoi un NOACK, donc erreur.
Le NOACK, je suppose, correspond à un état haut de la ligne SDA après l'émission de l'adresse?
si c'est ca, le NOACK est "généré" par un esclave (en fait il ne fait rien) quand il ne reconnait pas l'adresse reçue (dans ton cas) ou qu'il n'est pas en mesure de répondre (il est peut être occupé à une autre tâche).
Si l'adresse est correcte, tu as peut être configurer trop tôt le SDA du PIC en réception (RCEN=1).
Si le NOACK c'est au contraire un état bas de la ligne SDA, c'est normal, l'esclave signale qu'il est présent sur le bus I2C et qu'il a reconnu son adresse. ensuite il faut que le maitre passe en "écoute" pour lire la donnée réponse de l'esclave.
Bonjour,
Bah le ACK est toujours à 0 c'est quand il passe à 1 que c'est un NOACK.Par contre j'ai trouvé le probléme c'était bien le temps nécessaire entre l'écriture et la lecture (delay 100µs) Par contre je retrouve le NOAK sur l'instruction suivante maintenant.
Mais je vais regarder la DOC de l'EEPROM 24xx comme tu me l'as conseillé!
Merci
si tu parles toujours de la lecture (après l'envoi de l'adresse en lecture, l'esclave envoie ses données), c'est au maitre d'envoyer un ACK, si il veut lire plus d'une donnée , sinon il envoie un NOACK suivi d'un PSTOP.Envoyé par error2
Bonjour,
Par contre je retrouve le NOAK sur l'instruction suivante maintenant.
Re !
Oui oui, mais dans le protocol du MSU235, ils envoi 2 adresses:la première celle de l'esclave et la deuxiéme celle du registre choisi (adresse de Commande, adresse de l'octet de réponse1, adresse de l'octet de réponse2).
C'est le ACK de cette deuxiéme adresse qui s'acctive pas.
Je vais faire un tour sur la DOC de l'EEPROM 24xx
Dans ce cas, il faut:
- envoyer l'adresse du composant en écriture (bit R/W=0),
- envoyer l'adressse du registre,
- générer un START répétitif,
- envoyer l'adresse en lecture (bit R/W=1),
- lire la donnée envoyé par le composant.
Je te remercie mais mon stage touche à sa fin et aujourdh'ui était mon dernier jour
Donc je pense que je ne reviendrais plus ici, sauf si j'arrive à trouver du matos pour programmer de chez moi
En tous cas je te remercie pour toutes tes réponses souvent trés bénéfiques.
Bonne continuation !
A+
En tous cas, ils ont au moins un point commun : Ils étaient tellement buggés que microchip ne les fabrique plus.Bonjour,
Je fais tourner un afficheur LCD avec un 18f452, il tourne niquel !
Mais quand je le fais tourner sur un 18f252, il pante à l'initialisation (pour ceux qui connaissent : il est toujours occupé : LCDBusy )
Je voulais savoir si c'est possible que ça soit une erreur dû au changement de PIC. Pourtant c'est casiment les mêmes.
"Mon PIC18f452 est sur le PICDEM 2 Plus de Microchip et le PIC18f252 tourne sur une plaquette semblable mais faite maison(mais elle fonctionne)"
De mon temps, l'espèce humaine savait écrire sans faute d'orthographe en fin de 6ème primaire
Mais je suppose que cela n'est vraiment pas intéressant et que cela n'a pas de rapport avec l'intelligence? L'homme descend du singe ou y retourne ?
Salut Thm,
qu'est-ce que Microchip ne fabrique plus, les 18F452 et 18F252 ou le PICDEM2?
Parceque le 18F452 fonctionne bien, j'en utilise sans soucis.
Par contre je ne connais pas le PICDEM2, j'utilise l'ICD2.
@+
Salut, Hulk
Ben non,
tu vois le 18f452 dans la liste des µC sur le site de microchip? moi pas..
Et tu as lu les "erratas" de ce µc? Je me demande comment ils pouvaient "fonctionner" (à peu près une erreur pour chaque module) ?
amicalement
thierry
De la bonne lecture; à pleurer (de rire)
http://ww1.microchip.com/downloads/e...Doc/80058h.pdf
th.
Cette errata concerne le PIC18C452 et non le PIC18F452.
L'errata du PIC18F452 concerne le Timer1 (un problème lié à l'implantation du timer apparement) et touche plusieurs familles.
Au moins Microchip signale les problèmes rencontrés sur leurs puces.
Merci de l'info je n'étais pas au courant.
Ah ? tu as sûrement du passer la première page qui parle du CPU ??
Le problème, c'est qu'il y en a souvent et beaucoup qui ne sont pas "anodins".
th.
Salut,
Le 18Fx52, n'a qu'un "problème" très ciblé avec l'utilisation du timer1 en horloge externe et en utilisant le prédiviseur...
Il y a "juste" un risque de "perdre" une incrémentation lors de l'écriture dans le timer; cependant comme on parle d'écriture dans le timer, dans 99.999% des cas, cela ne prête pas à conséquence vu que l'on est occupé à modifier le timer....
De plus, le fait d'écrire dans le timer "reset" le prédiviseur, ce qui est bien plus dommageable que de "perdre" une incrémentation du compteur...
Je rappelle que l'écriture dans le timer peut provoquer une perte allant j'usqu'à huit coups d'horloge si le programme est mal écrit (par ex. en rechargeant le timer à un moment quelconque...)
Conclusion, à partir du moment où l'on utilise le prédiviseur, le reset du prediviseur va provoquer une erreur bien plus importante qu'un simple coup d'horloge si le programme est mal conçu...
Si l'on n'utilise pas de prédiviseur, l'errata donne la solution pour s'affranchir de la perte de ce coup d'horloge...
Par contre, Thm à raison, le 18Fx52 doit être remplacé par son équivalent le 18F4x20 qui est 100% compatible mais avec de meilleures performances et sans le bug sur le timer1 du 18Fx52.
Pour terminer, je préfère à 1000% la politique de Microchip qui rapporte tous les bugs de ces puces en y apportant la solution (la plupart du temps il suffit de faire attention à la manière de programmer ni plus ni moins...) que de chercher des jours et des jours pourquoi un programme bug quand on a pas eu d'errata relatant ce bug...
A partir du moment ou il y a un bug, ce n'est jamais anodin, quoi que l'on pense...
David.
Salut à tous,
renseignements pris, DavidDB à parfaitement analysé le soucis sur le PIC18F452 qui est centré sur Timer1 en horloge externe.
Microchip préconise l'emploi du 18F4520 pour les nouveaux développements et en plus il est moins cher.
Salut, HULK
Si tu fais une recherche de "PIC18FXX2 errata" sur le site microchip, tu verras qu'il y a 5 documents, et pas rien que le timer qui est concerné....
th.
Salut,
Pour les autres errata, ils ne sont d'application qu'à la condition d'avoir un µC d'une des quatre séries mentionnées en première page datant d'une production de l'année 2002...
De plus, au survol de ces errata, je remarque que tous ce qui est soulevé dans ces errata est valable pour la majeure partie de la famille 18F et est la référence en matière de programmation depuis bien longtemps (utilisation de BSR, GIEL, démarrage sur RESET)
Le reste, étant relatif aux spécifications électriques et n'ayant aucune incidence sur la programmation.
Donc, le seul bug qui mérite attention est l'utilisation du timer1 en horloge externe, les cinq errata mentionnés par thm résultent de la politique de transparence sur les µC Microchip vu que ce qui y est mentionné (niveau programmation bien entendu) est la norme de programmation depuis bien longtemps...
David.
Salut, David
Bon, ça va, j'abandonne..
thierry
Allez,
Même si Microchip te donne de l'urticaire, tu as le mérite d'aller sur leur site et de faire des recherches pour ton argumentation!
David.
