Problème avec un PIC16F690 et LCD

[verbalinsurection]

Merci pour vos réponses.

@Vede : je fais mes tests cablé sur la platine low pin du picKit2
@Qristoff et Vede : je ne peux pas faire les tests dans la journée, je vois ça ce soir et vous tiens au courant.
Merci en tout cas
-----

[verbalinsurection]

Alors ok avec le hex, ça marche par contre avec le code ça ne compile pas
Je n'ai pas de .inc sauf dans MPLAB mais ça ne fonctionne pas, forcement c'est de l'asm.

identificateur "PortB" indefini

--> remplacé par PORTB mais autre erreur

une struct/union requis

[invite7a49d0d5]

Salut,

tentes de remplacer mes PortB.RB6 par RB6 "tout court"...

c'est juste un "problème" de "nommage" des ports,
qui peut changer selon le compilo, cf 16F690.inc...

vede
;O]
_________
...

[verbalinsurection]

Merci encore pour ta réponse et désolé pour le retard de la mienne, un projet vient de me tombé sur le coin du cerveau et vu comment il fonctione ça l'aide pas

ok pour le nommage, mais la fonction Delay_ms() est inconnu par mon compilo, du moins avec l'include existant. J'ai ajouté : #include "delay.c" et c'est ok en changeant Dealy_ms() en DelayMs().
Donc j'ai une tempo qui est aux petits oignons avec ce delayms, mais je me pose 3 questions (pas taper, pas taper) :
- Comment faire pour utiliser un délai inférieur à 1ms comme ça a l'air d'être le cas pour l'init du LCD dans le datasheet ?
- La frequence de l'oscillo interne du PIC est réglé par OSCCON = 0b1100000; . Ok, mais comment comprendre cette valeure binaire ? si je vex passer l'oscillo en 2Hz par exemple ? comment dois-je procéder ?
- La fonction delayms est une fonction de mon compilo :

/*
 *	Delay functions
 *	See delay.h for details
 *
 *	Make sure this code is compiled with full optimization!!!
 */

#include	"delay.h"

void
DelayMs(unsigned char cnt)
{
#if	XTAL_FREQ <= 2MHZ
	do {
		DelayUs(996);
	} while(--cnt);
#endif

#if    XTAL_FREQ > 2MHZ	
	unsigned char	i;
	do {
		i = 4;
		do {
			DelayUs(250);
		} while(--i);
	} while(--cnt);
#endif
}

Mais vu le nom de la fonction le paramètre s'exprime ne ms... ok, mais ce devrait pourtant petre proportionnel à la fréquence de l'oscillo du pic non ?
(ça se voit tant que ça que je susi en train de me paumer ???)

Merci encore

[invite7a49d0d5]

Salut,

pour OSCCON c'est texpliqué dans la datasheet:
http://ww1.microchip.com/downloads/e...Doc/41262E.pdf
page 48 ou section 3.2
2Hz impossible...

pour atteindre ce genre de fréquence, avec précision (µs), il faut utiliser les timers... conseillé...

pour la fonction delayMs, regardes, elle utilises une fonction delayUs...
pour la précision, faudrait calculer, et voir la valeur de la variable cnt...
et le contenu de la fonction delayUs...

bon après c'est vite vu, @4Mhz, une instruction = 1µs...
asm : nop; // 1µs

vede
;O]
____________
...

[verbalinsurection]

Merci pour toutes ces précision Vede

Ok pour la fonction delayUs mais qu'es-ce ?

Bon, je vais me replonger là dedans et tanter au moins un init du lcd avec clignotement du curseur. Ca me fera ma première étape.

[invite7a49d0d5]

ps :

pour le LCD, le coup de moins de 1ms m'étonne...
car habituellement ça a un comportement type "esclave"...
donc c'est le "maître" qui envoie les ordres à la vitesse qu'il veut...
tant qu'il respecte le protocole... comme I2C...

la preuve... tu peux écrire manuellement sur un LCD...
avec un BP et une série de 9 inverseurs(data/command)...
j'ai déjà testé en 8bits... ça fonctionnait... mais faut être patient ;O]

[verbalinsurection]

en fait pour le moins de une seconde ce n'est pas une obligation si j'ai bien compris, mais entre certaines instructions le lcd est paré à la prochaine commande au bout de 56µs, donc tant qu'à faire...

j'ai bien vu que t'étais patient, la preuve avec moi...

[invite7a49d0d5]

re ;O]

pour DelayUs faudrait trouver son code...
ça devrait ressembler à:

DelayUs() { ;} // fait rien...

// mais déjà au moins 2µs @ 4Mhz...

[verbalinsurection]

ok, docn j'en reviens à ma question, vu que la fonction elle bouge pas, si je cale mon oscillo à 8Mhz, le DelayUs sera de 1µs non ?

[invite7a49d0d5]

bon ben pour faire un delai d'environ 60µs @ 4Mhz tu fais:

char i=60;
while(i) i--;

et voilà...
vu que une instruction / µs...

[invite7a49d0d5]

ok, docn j'en reviens à ma question, vu que la fonction elle bouge pas, si je cale mon oscillo à 8Mhz, le DelayUs sera de 1µs non ?

re re ;O]
théoriquement...

mais moi je mesure toujours...
pour savoir ou je met les pieds...

théoriquement si tu fait :
RB6 = 1;
DelayUs(50);
RB6 = 0;
DelayUs(50);

tu devrais trouver une fréquence très proche de 10Khz sur ta sortie RB6...
quelque soit FOsc, mais définie dans XTAL (because c'est basé la dessus ces fonctions de m...;O])...

[verbalinsurection]

oui mais vérifier à l'oeil pour moi va être difficile (il est pas bien réglé le bougre !)
je n'ai rien pour vérifier cela, à mon grand desespoir

[invite7a49d0d5]

re re re ;O]

de toute façon faut utiliser les timers
pour espérer "sérieusement" ce genre
de précision...

[verbalinsurection]

les ... t... timers... mais bien sur... bon faut que je retrouve mes guides là dessus moi

[invite7a49d0d5]

sans ça, de toute façon, faudrait se pencher sur
le code "assembleur" pour espérer approcher une
telle précision (µs)...

pour les timers, cherches "vede timer interruption" ici...
j'ai déjà passé l'hiver à tenter d'expliquer de façon claire les principes...

sinon il y a les cours du grand chef : MONSIEUR BigOnOff...
c'est gratuit, en français, ya tout, et détaillé...

[verbalinsurection]

merci bien, je suis sur les cours de Mr. BigOnOff depuis peu, je lis petit à petit mai je n'ai pas énormément de temps à y consacrer en ce moment, mais ça me donne une raison de plus pour m'y pencher plus souvent.
Ok pour la recherche sur le forum, je vais faire ça aussi.

[invite7a49d0d5]

last :

bon après on sait que delayms est basé sur delayus...
donc on peut faire un test sur une "longue durée"...
pour évaluer la précision...

et ce avec un code style :

RB6=1;
delayms(100);
RB6=0;

s=60
m=60

while(m)
{
while(s)
{
delayms(1000);
s--;
}
m--;
}

RB6=1;

au bout d'une heure exactement (max 100ms d'écart),
la led doit se rallumer...

si tu "trouves" 10s... ou +/-...
c'est qu'il y a un gros souci...

[invite7a49d0d5]

c'est un moyen "simple" d'évaluer des timings
(en les multipliant) ce avec un simple chrono...
à défaut de fréquencemètre...
mais c'est plus long...
;O]

[invite7a49d0d5]

Edit: erreur dans l'exemple :
cad ne pas oublier de remettre s(econdes) à 60, ce chaque minute...

RB6=1;
delayms(100); // eclair led start 
RB6=0;

s=60
m=60

while(m)
{
  while(s)
  {
    delayms(1000);
    s--;
  }
  s=60;
  m--;
}

RB6=1;

[verbalinsurection]

ok, je vais effectuer ce test pour voire, c'est interessant. Je te tiens au courant dès que j'ai un résultat.
Merci encore

[verbalinsurection]

Bonjour !

Désolé pour ce très très long délai... j'ai du abandonné suite à quelques petits soucis perso.

Mais je ne reviens pas les mains vides. J'ai repris hier soir, et j'ai réussi à initialiser le LCD !
J'arrive à déplacer le curseur clignotant sur le LCD !
Mais forcement, impossible d'écrire et là je sèche

Voici donc le code qui me permet tout ceci (un petit mélange des samples fournis par HI-TECH le compilo, et de choses trouvés sur le net)

void main(void)
 {
	OSCCON=0b1100001;
     ANSEL = 0;                                 // Disable adc
     CM1CON0 = 0;                            //Turn off Comparator 1
     CM2CON0 = 0;                            //Turn off Comparator 2  

         
     TRISB = 0;                                // PORTB all outputs
     TRISC = 0;                                // PORTC all outputs
         
     lcd_init();
	lcd_puts("Hello");
     lcd_goto(0x40);                                // select first line

     for(;;);
 }

#ifndef _XTAL_FREQ
  // Unless specified elsewhere, 4MHz system frequency is assumed
  #define _XTAL_FREQ 4000000
 #endif
 
 
 #include <htc.h>
 #include "lcd.h"
 
 #define    LCD_RS RC4
 #define    LCD_RW RB5
 #define 	LCD_EN RC5
 
 #define 	LCD_DATA    PORTC
 
 #define    LCD_STROBE()    ((LCD_EN = 1),(LCD_EN=0))
 
 /* write a byte to the LCD in 4 bit mode */
 
 void
 lcd_write(unsigned char c)
 {
     __delay_us(40);
     LCD_DATA = ( ( c >> 4 ) & 0x0F );
     LCD_STROBE();
     LCD_DATA = ( c & 0x0F );
     LCD_STROBE();
 }

/* write a string of chars to the LCD */
 
 void
 lcd_puts(const char * s)
 {
     LCD_RS = 1;    // write characters
     while(*s)
         lcd_write(*s++);
 }
 
 /* write one character to the LCD */
 
 void
 lcd_putch(char c)
 {
     LCD_RS = 1;    // write characters
     lcd_write( c );
 }

/* Go to the specified position */
void lcd_goto(unsigned char pos)
{
	LCD_RS = 0;
	lcd_write(0x80+pos);
}

void pulse()
{
	LCD_EN = 1;
	__delay_ms(5);
	LCD_EN = 0;
}     

/* initialise the LCD - put into 4 bit mode */
void lcd_init()
{
	LCD_DATA = 0b00000011; // 4bit function
    pulse();
	LCD_DATA = 0b00000011; // 4bit function
    pulse();
	LCD_DATA = 0b00000011; // 4bit function
	pulse();

	//lcd_write(0x28);                         
	lcd_write(0b00101110);					// Set interface length
	lcd_write(0b00001101);                  // Display On, Cursor On, Cursor Blink
	lcd_clear();                            // Clear screen
	lcd_write(0x06);                        // Set entry Mode
}

Donc l'init, le goto fonctionne, mais pas le puts. Si je fais un puts, le curseur ne s'affiche plus jusqu'à refaire un goto...
Bizare, j'ai cru que c'était mon RS qui ne se mettait pas à 1 mais je ne vois pas pourquoi et surtout je ne vois pas comment vérifier

Est-ce que le fait d'avoir le RS et EN sur le même port que celui utilisé pour les data peut poser problème ?