[Temps-x]

Re

Source du message Pour l'instant je vais couper des pistes et souder des fils

Avant de faire cette bêtise, pourquoi ne veux tu pas essayer de le faire en mode SPI bit bang ?

A+

[Superphénix]

Je viens de regarder de quoi il s'agit et de ce que je crois avoir compris, il s'agit de créé la communication soit même avec le programme et sans utiliser les modules spécifiques. Je crois que ça pourrait me sauver :)

[Temps-x]

Oui, et là je peux t'aider la première chose à faire c'est de définir les broches que tu va utiliser... ça.... que toi peut me le dire

Après je pourrais intervenir, en t'expliquant, tu vas en apprendre un peu plus sur le mode SPI

[Superphénix]

J'ai réussit ! ! !
J'ai plus qu'un problème de contraste trop faible à régler.
Voilà le programme que j'ai écrit :

Code : Tout sélectionner

Add = 0b10010010 ;   // Adresse 49h
    for(l=0 ; l<2 ; l++)
    for(i=0 ; i<3 ; i++)
    {   
        for(k=0 ; k<8 ; k++)
        {
            SCL=0 ;
            __delay_us(5) ;
            SDO = (Add>>(7-k)) & 0b00000001 ;
            __delay_us(5) ;
            SCL=1 ;
            __delay_us(10) ;
        }
        SEL_LCD = 1 ;
        for(j=0 ; j<19 ; j++)
        {   
            for(k=0 ; k<8 ; k++)
            {
                SCL=0 ;
                __delay_us(5) ;
                if(l==0) SDO = (AFF1[i][j]>>(7-k)) & 0b00000001 ;
                else     SDO = (AFF2[i][j]>>(7-k)) & 0b00000001 ;
                __delay_us(5) ;
                SCL=1 ;
                __delay_us(10) ;
            }
        }
        SEL_LCD = 0 ;
    }

Je ne sais pas si ce que j'ai fait avec les délais est correcte comme ça :)

[Temps-x]

Bonsoir Superphénix, et tout le forum,

Source du message J'ai réussit ! ! !

heureusement que tu n'as pas coupé les pistes...

Source du message Je ne sais pas si ce que j'ai fait avec les délais est correcte comme ça :)

Si ça fonctionne, c'est déjà bien, ça sauve ton PCB, maintenant pour affiner ton réglage, il te faut un analyseur logique, après il te faut régler le protocole SPI par rapport au datasheet.

Les temps serons surement à revoir, vu le langage de programmation que tu utilises je peux pas t'aider car je comprends qu'a moitié, mais il y a des personnes sur le forum qui le pourrons.

En ce qui concerne le contraste, surement des valeurs à modifier.

A+

[Superphénix]

Je crois que c'est ça d'ailleurs qui fait mon problème de contraste, puisque la fréquence d'actualisation de mon LCD dépend de la fréquence su SCL et pour un LCD ça change tout.

vu le langage que tu utilises

Oui de souvenirs en assembleur il suffit de compter les instructions pour calculer les délais. En C c'est plus compliqué ^^

Merci en tout cas !

[Temps-x]

Re

Tu t'es donnée du mal, et tu as participé à ton problème, c'est pour cela que j'ai voulu te donner un coup de main, certain ne font aucun effort, et attende qu'on leurs face tout.

Source du message Oui de souvenirs en assembleur il suffit de compter les instructions pour calculer les délais. En C c'est plus compliqué

Code : Tout sélectionner


__delay_us(5)


d’où vois tu la complication ?

Faire des temps en ASM c'est plus compliqué, car il faut tenir compte du quartz, et du nombre d'instruction.

Même si je ne fais pas du C je trouve que tes temps son trop long, je crois que tu as mi 5µs..... c'est trop long généralement c'est plutôt 1µs partout.

De toute façon rien ne t'empêche d'essayer de modifier les temps.....

A+

[satinas]

Bonjour à tous,

Bravo, tu as fait ça vite, il n'y a plus qu'à vérifier que les timings sont respectés, et c'est bon :)
Tu vois à l'oscillo, si les timings sont ok, les delays sont peut être superflus.
Une version avec moins de décalages, et un temps de calcul de SDO constant, bien que non indispensable.

Code : Tout sélectionner

void SendByte(unsigned char data)
{
  unsigned char i = 8;
  while (i) {
    SCL = 0;
    delay
    SDO = (data & 0x80) != 0; data <<= 1;
    delay
    SCL = 1; i--;
    delay
  }


J'aurais plutôt fait ça, avec un delay en moins.

Code : Tout sélectionner

void SendByte(unsigned char data)
{
  unsigned char i = 8;
  while (i) {
    SDO = (data & 0x80) != 0; data <<= 1;
    delay
    SCL = 1; i--;
    delay
    SCL = 0;
  }
}


[Superphénix]

Tu t'es donnée du mal, et tu as participé à ton problème

En même temps c'est pour un projet personnelle. :)

d’où vois tu la complication ?

__delay_us(5) n'est pas hyper précis parce qu'il faut rajouter les délais causés par les autres lignes de codes C autour, dont je ne connais pas en combien d'instructions bas niveau ils vont être divisés. Surtout pour des délais court.

c'est plutôt 1µs partout

C'était pour le test, j'ai mis 1µs maintenant et j'ai supprimé un délai inutile aussi.

Code : Tout sélectionner

        for(j=0 ; j<19 ; j++)
        {   
            for(k=0 ; k<8 ; k++)
            {
                SCL=0 ;
                if(l==0) SDO = (AFF1[i][j]>>(7-k)) & 0b00000001 ;
                else     SDO = (AFF2[i][j]>>(7-k)) & 0b00000001 ;
                __delay_us(1) ;
                SCL=1 ;
                __delay_us(1) ;
            }
        }

Je testerais sans les délais plus tard et surtout quand j'aurais reçu de quoi mesurer une fréquence. (mon oscillo analogique est méga imprécis pour ça)

Le faire avec un while(i) ça a un avantage ?

[satinas]

Bonjour,
Avec le for on incrémente la variable puis on charge la constante 8 et on compare, cela fait beaucoup d'instructions machine. Le compilateur peut simplifier en optimisant.
Le while (i--) est très rapide car le pic décrémente la variable et sait aussitôt par son flag Z si elle est passée à 0. C'est pourquoi il vaut mieux décrémenter vers 0 qu'incrémenter dans les boucles for ou while.
J'ai mis le i-- derrière SCL=1 pour masquer le delay, mais cela reste plus rapide.
En l'occurrence un do { ... } while (i); est encore mieux que le while, car le premier test du while, 8 != 0, est en trop.
Tout cela c'est de la théorie, je sais pas ce que fait derrière un compilateur non optimisé. Et on a encore le droit d'écrire du code lisible :)