[paulfjujo]

en Fin de compte l'écran fonctionne bien à grande vitesse, c'est la vitesse SPI qui n'arrive pas à suivre par rapport au données Usart

... débrider la sortie SPI
voir registre
SLRCONC.SLRC5 = 0; // No slew rate limiting si RC5 SPI Out

SLRCONC=0;
SPI1CLK = 0; // CLKREF =0 ->FOSC=64MHz
// SPI1BAUD = 3; // SPI Speed 64MHz / (2x(3+1)) = 64/8 = 8MHz ..OK!!
SPI1BAUD = 0; // SPI Speed 64MHz / (2x(0+1)) = 64/2 = 32MHz OK

[/quote]

Source du message ouvrir un post specifique sur ce sujet ?
Le post tu veux l'ouvrir en C ou ASM ou en terain neutre

en terrain neutre, on pourra mixer les solutions ASM et C

quoique se taper des calculs de sinus ou cosinus en flottant et en asm ....
mais on peut toujours utiliser 360 couples de valeurs sin cos précalculés en dur stockés en tableau RAM
( 360 * 4 * 2= 2880 bytes ..jouable avec le 18F27K42) ou en Flash

[venom]

]un petit coucou vite fait... semaine encore bien charger de mon coté
Bravo ça rend bien sur vos écrans rond j'adore le résultat.

:-D Bon celui-là tu sais qui sait....

Gérard.jpg

A+

J'ai pas eu le temps de répondre Gerard a etait plus vite que moi

Le branchement reste identique que l’écran rectangle ?






@++

[Temps-x]

Bonsoir paulfjujo, venom, et tout le forum,

Je réponds que maintenant, car je n'avais pas la force d'allumer mon ordinateur hier, trop fatigué.

Source du message débrider la sortie SPI
voir registre
SLRCONC.SLRC5 = 0; // No slew rate limiting si RC5 SPI Out

SLRCONC = 0 ça change rien, toujours aussi lent, SPI1CLK, SPI1BAUD, n'existe pas dans ce Pic 18F26k22

Ce qui est bizarre, c'est qu'un fichier BMP 24 bits arrive à passer à 500 000 bauds, alors qu'un fichier hexadécimal, ou fichier BMP RGB565 ne passe pas à cette vitesse, si je diminue la vitesse à 250 000 bauds, tous les formats passent.

La lecture d'un fichier BMP 24 bits nécessite 3 octets pour 1 pixel, tandis qu'un fichier RGB565, ou hexadécimal nécessite 2 octets pour 1 pixel.

Mais dans un fichier BMP 24 bits, on traite que 2 octets à envoyer, temps d'attente plus court, car le 3ème octet n'est pas envoyé, mais il est utils pour assembler le format RGB565.

Petite question, peut-on lire les pixels sur cet écran

Source du message Le branchement reste identique que l’écran rectangle ?

VCC = identique
GND = identique
CS = identique
RESET = identique
AO = identique
SDA = identique
SCK = identique
LED = identique

Oui les branchements sont identiques, et de plus tu peux tout alimenter en 3.3 volts, surtout ne pas alimenter en 5 volts

Par contre la configuration est différent, mais on peu très bien prévoir dans le programme un bouton à pouser pour passer d'un écran à l'autre.

Avant que les prix flambent dû à la taxe qui va être mise en place en juin, je vais en commander 2 autres avec la carte SD.

Si tu en commandes, assure-toi que les broches ont les mêmes emplacements que ton petit écran SPI, si tu n'es pas sûr, fais-nous voir le lien.

Source du message J'ai pas eu le temps de répondre Gerard a etait plus vite que moi

Que veux-tu ... Il est rentré de vacances, maintenant il peut nous surveiller, faudra attendre ses prochaines vacances.


A+

[paulfjujo]

bonjour,

...Oui les branchements sont identiques, et de plus tu peux tout alimenter en 3.3 volts, surtout ne pas alimenter en 5 volts
...

j'ai par erreur, alimenté mon montage PIC + OLED GCA9A01 en 5V ( 4.98V exactement)
et là, l'OLED n'affichait RIEN !
en baissant l'alim <3.9V ,l'affichage etait à nouveau OK
=> alim <3.9V sur mon modele ..

On ne peut pas lire l'etat de du buffer RAM OLED ....
c'est rapé pour avoir de jolies aiguilles ..mais peut etre jouable avec des aiguilles = simple vecteur lineaire
il faut simplement avoir un buffer ( 3 aiguilles) pour stocker le fond d'image sous les aiguilles
mais risque de prendre pas mal de temps X?

si aiguille troteuse de 110 pixel de long (en laissant les graduations sur le pourtour)
aiguille troteuse 110 x 2=220 bytes 220 multiplications de flottants (360 sin et 360 cos precalculés= >720x4 =2880 bytes (en RAM ou Flash ?))
aiguille heure 100x2=200 bytes
aiguille minute 105x2=210 bytes

à voir :
precalculer les premiers 90 vecteurs de position finale de la troteuse,
les autres en utilisant les symetries !
Heure et min etant des sous multiples
table resultante de 90 entier = 90x2 = 180 bytes (x1,y1)
le point de depart etant toujour le centre x0=109, y0=109
on a besoin que de l'arrivée et demander à Brensham de tirer le trait.avec la coordonnées calculé x1,y1


alors ,partant pour ouvrir un post sur ce sujet
montre analogique GC9A01 avec PIC 18F27K42 ou 47K42 ou ..avec beaucoup de flash et Ram

[Temps-x]

Bonsoir paulfjujo, et tout le forum,

Source du message j'ai par erreur, alimenté mon montage PIC + OLED GCA9A01 en 5V ( 4.98V exactement)

Le mieux c'est de ne pas tenter le diable.

Un fichier hexadécimal (RGB565 - 16 bits (Taille de 115 266 octets)) peut loger dans un Pic18F27K42 car ce Pic a 131072 octets de mémoire programme, ce qui nous laisse 15806 octets pour écrire le programme, plus que faisable en ASM, reste à voir avec le C

Créer un tableau, pratiquement obligé pour gagner du temps et de la vitesse, une fois ce tableau créé, il servira pour toute sorte d'écran
sans dépasser la limite d'une aiguille énormément grosse

Source du message alors ,partant pour ouvrir un post sur ce sujet
montre analogique GC9A01 avec PIC 18F27K42 ou 47K42 ou ..avec beaucoup de flash et Ram

C'est pas l'envi qui me manque, et ont peut toujours commencer à le faire, après c'est surtout le temps qui va me manquer, je vais travailler seulement 2 à 4 heures par semaine dessus, sans compter qu'il va falloir réfléchir avant d'agir.

En premier lieu, il faut voir à quelle vitesse est redessiné un bout d'écran où les aiguilles se trouvent, c'est primordial si on veut que ça fasse joli

J'ouvre le post avant fin de semaine

A+