Discussion :

[jpwitz]

Bonjour
J'utilise mplab pour simuler un PIC 16F876. Je cherche un plugin (ou autre) pour simuler un programme gérant un afficheur lcd type 2x16 alphanumérique Hitachi.
Pourriez-vous me dire si un tel outil existe et où le trouver ?
Merci

[elecpic]

Bonsoir,

En fait, tu voudrait un code tout fait pour simuler un afficheur 2X16 avec un 16f876a.

Désolé, mais moi aussi, j'ai cherché... et pas trouvé !

Apres reflexion, ça parait normal : ce micro a ses propres registres. Un 2x16 a aussi ses propres registres. Peut-on imaginer un code universel pour parametrer la multitude de micro X la multidue d'afficheur LCD ? Soyons raisonnable (d'autant plus que les broches des ports seraient figées)!

Par contre, je t'invite de chercher sur la toile les Data sheet de tes composants.

J'ai personnellement fait des simu sur MPLAB avec le 16f876a et un afficheur 2X16. Ca ne pose aucun probleme.

je suis ton post par notification et n'hesite pas si tu as des pbs.

Bon courage,

elecpic

[jpwitz]

Bonjour
Merci pour votre réponse...
Moi aussi,je cherche depuis un certain temps sur la toile, et il me semble que je ne suis pas le seul, mais sans succès..
Je cherche un plugin style outils->DMCI ou RTOS (ou autre) qui visualiserait un afficheur 1x ou 2x16 caractères (type hitachi) pour lequel on pourrait définir les connexions (PA0 du PIC -> E de l'afficheur, etc...)
Je m'étonne qu'un tel outils n'existe pas encore. Pour plusieurs raisons:
- les afficheurs LCD basés sur le contrôleur Hitachi HD44780 sont nombreux et leur fonctionnement est bien bien connu
- beaucoup de montages utilisent de tels afficheurs
- pour la simulation, les plugins peuvent être connectés à n'importe quel PIC géré par MPLAB sous réserve de définir la correspondance des pattes. Cela rendrait donc service à bien des développeurs.
- pour un "créateur de plugin", cela devrait pouvoir de faire sans difficultés... enfin... moi je sais pas

Si cet appel pouvait être entendu par un bonne âme (de chez Microchip?), je pense que beaucoup de personne lui en seraient reconnaissants.

[elecpic]

Bonjour,

Je reste un peu etonné par ton post car la mise en oeuvre d'une gestion d'un afficheur reste vraiment tres simple (2x16 ou 4 x16).

je fait ca de memoire : 2 broches de controle (r/w et E), + 4 ou 8 broches de data. Imagine l'occupation des memoires programmes pour un pic 16f83 ?
de plus, les plugins, je ne suis pas forcement pour: ca fait le travail pour toi, et toi t'as rien compris... Je ne dis pas ca pour toi ! (car c'est aussi mon cas : je fait aussi de la programmation sous delphi).

De plus, n'oublie pas d'etre pragmatique :
faire un plugin concernant ces 2 type d'afficheurs demanderait (je suppose) pas loin de 50 lignes de code alors que 10 lignes de codes suffisent.

Des plugin existent concernant les module UART car effectivement, c'est plus compliqué a mettre en oeuvre.

Bon courage,

elecpic

[jpwitz]

Bonjour(re)
J'ai oublié de préciser que je programme en assembleur.
Je ne suis pas sûr que nous parlons de la même chose. Un plugin de MPLAB n'utilise aucune ressource du PIC dont le programme est simulé. Le plugin sert à visualiser de façon graphique les données présentes en entrées et sorties sur les broches du PIC ou dans ses registres... Enfin...il me semble..

Par exemple, le plugin Data Moniteur Contol Interface (DMCI) de MPLAB permet de relier un curseur à une case RAM dont le contenu est amené à varier. Pour la simulation, il est plus facile de faire varier la position d'un curseur que de saisir à longueur de simulation différentes valeurs dans la case mémoire 0x067 'par exemple" de la fenêtre "File Registers" de MPLAB.

En ce qui concerne l'afficheur en question, il est vrai qu'il est facile de voir l'état -par exemple - du bit 0 de PortA (relié à PA0 qui est relié à la broche Enable de l'afficheur) et de faire de même pour les autres signaux. Il est cependant plus difficile de vérifier l'affichage (et son effet visuel) de plusieurs lignes déroulantes avec les positions variables, l'effacement de l'écran, le positionnement du curseur, etc...

Avoir un outil MPLAB permettant d'avoir une fenêtre présentant graphiquement les pixels d'un afficheur et leurs variations par rapport aux valeurs des broches des Ports de sorties du PIC, conformément au protocole HITACHI (par exemple), serait un gros plus pour la simulation des scripts.

[elecpic]

bonsoir,

Je te rassure, moi aussi je programme mes pic en assembleur ! et je pense aussi que ce langage est le plus approprié (gestion du pseudo registre W)

J'ai travaillé avec une version de mplab qui ne gerait que le numerique : je m'en suis toujours sorti.
J'ai updaté et me suis apperçu d'une nouvelle fonction : la gestion de signaux analogique. J'ai donc fait un essai : un potar sur une broche AN. je peux te dire que la theorie et la pratique sont 2 choses differentes... Et je crois que microchip le reconnait !

Pour repondre a ton post, prenons les choses par le bon sens :

- Mplab sert a faire de la programation, pas de la simulation
- microchip ne vend pas un simulateur ou une appli : il fabrique des processeurs
- Par ailleur, as tu entendu parlé du debogage in-situ ? A quoi sert-il ?
- Crois-tu qu'une personne vas faire un plugin pour une chose aussi simple a gerer ?
- enfin et surtout : fais-tu confiance a ton code, pourquoi vouloir visualiser un(des) signal(aux) sachant que la simu n'est pas tres viable ? Pourquoi ne pas faire des protos ?



par ailleurs, erreur de ma part, il y a 3 bits de controle : RS, R/W, E

bon, pour finir, il ma parait plus simple d'ecrire (en assembleur ) un fichier multi-fonction et pourrrait gerer tout les pic et tous les aff. Libre a toi de supprimer le surplus !

La simulation a des limites... La réalite !

pas de probleme pour t'aider

cordialement,

elecpic

[jpwitz]

Bonjour

Il est vrai que la théorie et la réalité sont 2 choses différentes, pas très éloignées cependant. Néanmoins, je pense que le simulateur sont très bien faits et permettent de gagner beaucoup de temps pour les tests.

Je comprends ton point de vue, mais ne le partage pas tout à fait... Nos démarches sont vraisemblablement identiques: script ->simulation -> ecriture dans le PIC -> test sur proto -> correction du script -> PIC -> test proto -> script -> etc... jusqu'à ce que le montage fonctionne komilfo.

Merci elecpic de t'être intéressé à mon problème.

PS: Existe-t-il un endroit qui explique comment faire un plug-in MPLAB?

[elecpic]

Bonjour,

je viens de relire attentivement notre conversation et il me semble tres peu probable que tu trouve ce que tu cherches : en voici les raisons :

- ceux qui programment en assembleur font de l'éléctronique.
- les informaticiens eux programment en c++, pascal, et autres (pardons aux oubliés )
- le langage c est un peu la transition entre tout ça ... mais dedié a l'éléctronique quand meme.

Je ne pense pas qu'une personne (sauf si tu demande a microchip )
se prenne la tete à ecrire un tel programme (gestion multi plateforme pour le pc avec en sortie un code en assembleur).

Si par hasard je me trompe, fait moi signe, je prend de suite

Bon courage pour ta simu, soit attentif a tes sorties pour l'aff, et je persiste et signe : une simu c'est bien, un processeur in situ qui tourne, c'est mieux !

cordialement,

elecpic