DSPIY 2560 - Proto 1
Re: DSPIY 2560 - Proto 1
Merci beaucoup, je regarde tout ça en détail dans la soirée
Re: DSPIY 2560 - Proto 1
Après presque un an, je profite de ma courte "pause pédagogique" pour me remettre un peu sur le LPC. C'est un peu plus clair, j'ai le SPI qui marche correctement, et un écran oled qui s'allume ! Bon pour l'instant il affiche soit rien, soit tout, soit des pixels aléatoirement quand je rempli pas la ram correctement
Il faut que je regarde un peu plus attentivement comment on rempli la RAM, pour l'instant c'est un peu flou la manière dont elle s'incrémente
Louis
Il faut que je regarde un peu plus attentivement comment on rempli la RAM, pour l'instant c'est un peu flou la manière dont elle s'incrémente
Louis
- thierryvalk
- Administrateur du site
- Messages : 3730
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: DSPIY 2560 - Proto 1
Il y a deux méthodes.
Soit tu écris directement en RAM de l'écran soit tu passe par un buffer RAM dans ton µC.
Dans ce second cas tu peux faire tout ce que tu veux. Par exemple mettre du texte existant en négatif via une fonction de XOR.
Ce qui est impossible si tu utilise directement la RAM de l'écran vu que tu ne peux pas la lire.
Voici un peu de code, mais depuis le temps je ne sais plus comment il fonctionne.
Je sais juste qu'il fonctionne, c'est du bas niveau.
Pour tracer une ligne :
Un point de cette ligne dans le buffer du µC:
Transfert du buffert à l'écran :
Et enfin l'adressage de l'écran : (c'est peut être sur ce point que tu bloque)
Soit tu écris directement en RAM de l'écran soit tu passe par un buffer RAM dans ton µC.
Dans ce second cas tu peux faire tout ce que tu veux. Par exemple mettre du texte existant en négatif via une fonction de XOR.
Ce qui est impossible si tu utilise directement la RAM de l'écran vu que tu ne peux pas la lire.
Voici un peu de code, mais depuis le temps je ne sais plus comment il fonctionne.
Je sais juste qu'il fonctionne, c'est du bas niveau.
Pour tracer une ligne :
Code : Tout sélectionner
void lcd_Line(unsigned char orientation,unsigned char fin)
{
unsigned char n;
if(orientation==Hor)
{
for(n=lcd_x;n!=fin;n++)glcd_Dot(n,lcd_y,XOR);
}
else
{
for(n=lcd_y;n!=fin;n++)glcd_Dot(lcd_x,n,XOR);
}
}
Un point de cette ligne dans le buffer du µC:
Code : Tout sélectionner
void glcd_Dot(uint8_t x, uint8_t y, uint8_t mode)
{
// here 2*1 setup - TODO: for 2*2 setting
uint8_t bitnum, bitmask, yByte;
//if ( (x>=GLCD_RIGHT) || (y>=GLCD_BOTTOM) ) return;
yByte = y >> 3; // / 8
bitnum = y & 0x07;
bitmask = glcd_MaskArray[bitnum];
switch (mode) {
case SET:
glcd_Buffer[yByte][x] |= bitmask;
break;
case CLEAR:
glcd_Buffer[yByte][x] &= ~bitmask;
break;
case XOR:
glcd_Buffer[yByte][x] ^= bitmask;
break;
default: break;
}
}
Transfert du buffert à l'écran :
Code : Tout sélectionner
void lcd_update()
{
unsigned char x;
for(x=0; x!=4; x++)
{
lcd_pageX(x<<3);
lcd_addressY(0);
GPIOSetValue(Port_A0,Pin_A0,1);
GPIOSetValue(Port_CS1,Pin_CS1,0);
if(D01_ECRAN>2)
{SPI_Send(0,1);SPI_Send(0,1);SPI_Send(0,1);SPI_Send(0,1);}
SPI_Send((uint8_t *)glcd_Buffer[x],128);//128);
}
GPIOSetValue(Port_CS1,Pin_CS1,1);
lcd_addressY(0);
lcd_pageX(0);
}
Et enfin l'adressage de l'écran : (c'est peut être sur ce point que tu bloque)
Code : Tout sélectionner
//========================================================================================
// set Y adresse LCD position horizontale [0-63] (auto-incrementee a chaque
// lecture/ecriture)
//========================================================================================
void lcd_addressY(unsigned char adr)
{
//lcd_putcmd(0x10|((adr>>4)&0xf));
//lcd_putcmd(0x0|(adr&0xf));
lcd_putcmd(0x0+adr%16);
lcd_putcmd(0x10+adr/16);
}
//========================================================================================
// set X page LCD position verticale [0-7] (par paquets de 8)
//========================================================================================
void lcd_pageX(unsigned char adr)
{
lcd_putcmd(0xb0 | ((adr>>3) & 0x07) );
//lcd_putcmd(0xb0|(adr>>3));
}
Re: DSPIY 2560 - Proto 1
En fait j'ai déjà ton code pour l'oled du dspiy
J'utilise pas le même écran (et pas le même driver). Le mien fait 256x64 pixels (et le driver c'est un SSD1322), mais c'est sensiblement pareil j'ai l'impression. J'ai déjà regardé ton code (et je m'en suis même inspiré ) mais j'avais pas trop compris la partie lcd_addressY/x, mais en regardant la doc du driver et en reprenant ton code tranquillement ça commence à s'éclaircir ! Merci beaucoup
J'utilise pas le même écran (et pas le même driver). Le mien fait 256x64 pixels (et le driver c'est un SSD1322), mais c'est sensiblement pareil j'ai l'impression. J'ai déjà regardé ton code (et je m'en suis même inspiré ) mais j'avais pas trop compris la partie lcd_addressY/x, mais en regardant la doc du driver et en reprenant ton code tranquillement ça commence à s'éclaircir ! Merci beaucoup
- thierryvalk
- Administrateur du site
- Messages : 3730
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: DSPIY 2560 - Proto 1
Ah oui, ma mémoire n'est plus de qu'elle était.
Re: DSPIY 2560 - Proto 1
En même temps c'était il y a un an et demi je pense
J'ai une petite question, je comprend pas pourquoi ton buffer ne fait que :
Tu es en monochrome, donc 1bits par pixel, donc 8pix/octet ? (Le tableau est déclaré pour un écran de 128x64). L'écran que j'utilise c'est 4bits/pixel donc 2pix/octet car il y a le niveau de gris. Je ne sais pas si je peux le mettre en monochrome, ce n'est pas écrit explicitement en tout cas
J'ai une petite question, je comprend pas pourquoi ton buffer ne fait que :
Code : Tout sélectionner
uint8_t glcd_Buffer[8][128];
Tu es en monochrome, donc 1bits par pixel, donc 8pix/octet ? (Le tableau est déclaré pour un écran de 128x64). L'écran que j'utilise c'est 4bits/pixel donc 2pix/octet car il y a le niveau de gris. Je ne sais pas si je peux le mettre en monochrome, ce n'est pas écrit explicitement en tout cas
- thierryvalk
- Administrateur du site
- Messages : 3730
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: DSPIY 2560 - Proto 1
En effet, mon buffer est trop grand. Ce code avait été écrit initialement pour du 128x64 et l'on avait gardé la possibilité de mettre différents écrans dont un 128x64.
On voit bien dans la fonction de transfert que l'on utilise que 4 pages sur les 8.
Et en effet, un byte fait 8 pixels verticaux. Il y a aussi la configuration initiale qui auto-incrémente le pointeur de mémoire de l'écran.
Niveau de gris, jamais utilisé et aucune idée de comment cela fonctionne.
On voit bien dans la fonction de transfert que l'on utilise que 4 pages sur les 8.
Et en effet, un byte fait 8 pixels verticaux. Il y a aussi la configuration initiale qui auto-incrémente le pointeur de mémoire de l'écran.
Niveau de gris, jamais utilisé et aucune idée de comment cela fonctionne.
Re: DSPIY 2560 - Proto 1
Je commence à avoir un truc plus ou moins fonctionnel. Il faut effectivement que je passe tout en niveau de gris, c'est à dire 4bits/pixel. La solution simple c'est un buffer de 128*64, avec chaque case du tableau deux pixels. Le problème c'est que ça prend pas mal de place dans la RAM. La deuxième solution c'est un tableau monochrome (1 case = 8pixels) et lors de l'envoi vers la RAM de l'écran, on fait une petite conversion pour passer en 4bits/pixel. Mais j'ai peur que cette solution ralentisse fortement le transfert vers l'écran. Dans tous les cas, pour l'instant ce transfert est très lent car pas du tout optimisé, mais c'était pour vérifier que tout marche correctement. Maintenant "plus qu'à" mettre tout proprement
PS : Merci beaucoup Thierry pour la lib, ça m'a beaucoup aidé !
PS : Merci beaucoup Thierry pour la lib, ça m'a beaucoup aidé !
- thierryvalk
- Administrateur du site
- Messages : 3730
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: DSPIY 2560 - Proto 1
La seule chose qui peut ralentir, c'est la fréquence du bus SPI.
Tu peux configurer sa vitesse selon la mas admissible par l'écran tout en veillant à bien garder les délais nécessaires à certaines instructions.
Tu peux configurer sa vitesse selon la mas admissible par l'écran tout en veillant à bien garder les délais nécessaires à certaines instructions.
Re: DSPIY 2560 - Proto 1
Je suis à 10MHz, donc le transfert du buffer de 128*64 devrait se faire en environ 8*128*64*(1/10MHz) secondes soit environ à 150Hz. J'ai pas regardé à l'oscillo mais je "vois" l'écran se rafraîchir, donc je suis clairement très en dessous. Il y a quelque chose qui prend du temps entre les transferts mais c'est un peu le bazars donc ça m'étonne pas
Pour transférer des gros buffers comme ça, je pense que le DMA pourrait être bien pratique, du moins soulagerai pas mal l'µC. On verra si j'ai le courage de mettre le nez dedans
Pour transférer des gros buffers comme ça, je pense que le DMA pourrait être bien pratique, du moins soulagerai pas mal l'µC. On verra si j'ai le courage de mettre le nez dedans
- thierryvalk
- Administrateur du site
- Messages : 3730
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: DSPIY 2560 - Proto 1
Tu dois peut-être simplement sélectionner une option d'optimalisation pour le compilateur.
Mais c'est pas la solution miracle.
Selon le niveau et ton code, le debug peut devenir incertain et même créer des soucis avec variables et boucles.
Mais c'est pas la solution miracle.
Selon le niveau et ton code, le debug peut devenir incertain et même créer des soucis avec variables et boucles.
Retourner vers « DSPiy général »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 8 invités