[gwion]

Le CH340 est lent, rien à faire pour augmenter la vitesse. Il faut tabler sur un débit moyen plus proche de 0,5Mbit/s que de 1Mbit/s. C'est aussi le moins cher, comme par hasard.
Les FT232R/RL sont beaucoup plus rapides, à condition que ce ne soit pas des fakes chinois. Eux posent des problèmes, notamment l'obligation d'utiliser de vieilles versions de driver. Avec les originaux on peut compter sur 3Mbit/s stables.
Le FT232H original lui grimpe à 12Mbit/s, là il faut que l'UART suive.

[paulfjujo]

avec mon cordon prolific CH340G , j'atteinds facilement 921.6 Kbds sur UART1 18F27K42
Attention toutefois aux erreurs sur le contenu transmis si on utilise FOSC Interne 64MHz
le FOSC depend aussi de la tension d'alim. entre 3,3 et 5V
et de la temperature ambiante ... Hiver/été
il pourrait etre necessaire de corrriger via OSCTUNE ( +-3%)

ce qui est inutile à 9600 bds..

YAT terminal
propose une vitesse maximale de 12 Mb/sec sur port COM

[Temps-x]

Re

Source du message Le CH340 est lent, rien à faire pour augmenter la vitesse.

Je ne parle pas de la vitesse de transmission qui s'exprime en Baud, je parle de la vitesse que met l'ordinateur à transmettre les données.

Exemple : Avec une vraie prise RS232 à 38400 bauds et 40960 octets de données à envoyer, je mets 10 secondes
. Avec des émulateurs de ports série pour 38400 bauds et 40960 de données à envoyer, je mets 40 secondes

Les données sont envoyées sans aucune connexion au Pic

Ce que j'appelle émulateur de prise série sont des modules Ch340, FT232R/RL... etc


Tu ne lis pas tout ce que j'écris !! Sur mon vrai Port Com, la vitesse est 4 fois plus rapide. Comment expliques-tu cela ? Je rappelle que tous les essais sont faits à une vitesse de 38400 bauds


Regarde le fichier, tu vas comprendre tout de suite, il n'y a pas que la valeur hexadécimale brute....

16 valeurs hexadécimales par ligne pour une image de 40960 octets = 2560 lignes

Source du message avec le ficher TAB resultant
et dans quel sens sens explores-tu le fichier
de gauche à droite et en descendant d'une ligne
0 à 127
128 à 255
...etc ..

De gauche à droite, 0 à 128 et je descends d'une ligne 0 à 160

Source du message un truc m'interpelle
image de 120x160 => 19200 pixels
65Kcolors => 19200 x2 = 38400 bytes

(128x160)*2 = 40960


Voici l'image BMP en 24 bits téléchargement ICI

A+

[paulfjujo]

Tu ne lis pas tout ce que j'écris !! Sur mon vrai Port Com, la vitesse est 4 fois plus rapide. Comment expliques-tu cela ? Je rappelle que tous les essais sont faits à une vitesse de 38400 bauds

sur les PC XP , l'UART et le port Parrallele sont encore en acces direct possible .... un VRAI com port.
alors que non , depuis win8 ..WIN10
et tu dois alors avoir un Convertisseur USB/TTL pourri, ou un fake ? ou qui necessite un vieux driver.


Tes valeurs sont directement accessibles en C ...

// 1 ligne data =16 bytes = 8 pixels
const unsigned char Image_128x160[40960] = // ligne 5 à # ligne 2565 = 2560 2560*16= 40960 bytes
{[b]

0xD6, 0xB9, 0xDE, 0xF9, 0xDE, 0xFA, 0xDE, 0xFB, 0xDE, 0xDB, 0xD6, 0xDA, 0xD6, 0x9A, 0xCE, 0x79,
0xBE, 0x37, 0xB5, 0xF5, 0xAD, 0xD4, 0xAD, 0xB4, 0xAD, 0xD4, 0xB5, 0xF5, 0xBE, 0x16, 0xC6, 0x57,
0xC6, 0x57, 0xCE, 0x78, 0xCE, 0x78, 0xCE, 0x98, 0xCE, 0x79, 0xCE, 0x99, 0xD6, 0xDA, 0xD6, 0xDA,
0xDE, 0xDA, 0xDE, 0xFA, 0xDE, 0xFB, 0xDF, 0x1B, 0xE7, 0x3C, 0xE7, 0x3C, 0xE7, 0x3C, 0xE7, 0x3C,
0xEF, 0x5D, 0xEF, 0x5D, 0xEF, 0x5D, 0xEF, 0x5D, 0xEF, 0x5D, 0xEF, 0x5D, 0xEF, 0x5D, 0xE7, 0x3C,
0xE7, 0x3C, 0xE7, 0x3C, 0xE7, 0x3C, 0xE7, 0x1C, 0xE7, 0x1C, 0xE7, 0x1B, 0xE7, 0x1B, 0xE7, 0x1B,
0xDE, 0xDA, 0xD6, 0xB9, 0xD6, 0xB8, 0xD6, 0x98, 0xC6, 0x57, 0xBE, 0x36, 0xBE, 0x16, 0xB5, 0xF5,
0xC6, 0x75, 0xD6, 0xD8, 0xDE, 0xF8, 0xDE, 0xD8, 0xDE, 0xF7, 0xDE, 0xF8, 0xDE, 0xF8, 0xDE, 0xF8,
0xDE, 0xF7, 0xDE, 0xF7, 0xDE, 0xF9, 0xE7, 0x39, 0xE7, 0x18, 0xDE, 0xF8, 0xDE, 0xF9, 0xEF, 0x5C,
0xEF, 0x9D, 0xEF, 0x7D, 0xEF, 0x5D, 0xEF, 0x5D, 0xE7, 0x3C, 0xE7, 0x3C, 0xE7, 0x5C, 0xE7, 0x3B,
0xCE, 0xB8, 0xC6, 0x96, 0xC6, 0x74, 0xBE, 0x51, 0xBE, 0x92, 0xB6, 0x30, 0xAE, 0x10, 0xAE, 0x10,
...etc ...
0x29, 0xC7, 0x21, 0xA6, 0x2A, 0x07, 0x2A, 0x07, 0x29, 0xE7, 0x29, 0xE7, 0x29, 0xE7, 0x21, 0xE7,
0x21, 0xE7, 0x21, 0xC6, 0x21, 0xC6, 0x19, 0xA6, 0x19, 0xA6, 0x21, 0xC6, 0x19, 0xC6, 0x19, 0xC6,
0x21, 0xC6, 0x31, 0xE7, 0x42, 0x29, 0x4A, 0x4A, 0x5A, 0x8B, 0x52, 0x6A, 0x4A, 0x29, 0x29, 0x86,
0x21, 0x04, 0x3A, 0x07, 0x3A, 0x47, 0x42, 0xC7, 0x3A, 0xA6, 0x32, 0x64, 0x21, 0xE4, 0x21, 0xA4,
0x19, 0x43, 0x19, 0x42, 0x19, 0x82, 0x11, 0x82, 0x11, 0x82, 0x11, 0x82, 0x11, 0xA2, 0x19, 0xE2
};


Merci pour l'image !

[/quote]

[Temps-x]

Source du message { //alors que 120x160=19200 *2 = 38400 (was 40960)

ce n'est pas 120 c'est 128 ce qui explique tes erreurs

A+

[paulfjujo]

Source du message { //alors que 120x160=19200 *2 = 38400 (was 40960)

c'est pas 120 c'est 128 ce qui explique tes erreur

A+

bien vu

[Temps-x]

Les valeurs du fichier hexadécimale son RGB565 = 16 bits 128x160, l'image est en 24 bits, 128x160.

A+

[gwion]

Pour répondre à Temps-x, je n'ai pas parlé de vitesse mais de débit.
Par ailleurs, relire la définition du baud. Même si dans les transmissions séries dont on parle on peut dire par abus de langage que 9600 bits par seconde = 9600 baud, puisqu'on a un bit transmis par symbole codé (valence=2), son utilisation n'est absolument pas rigoureuse. D'autant plus que le signal en question n'est pas modulé.

[Temps-x]

Bonjour gwion, et tout le forum,

Source du message je n'ai pas parlé de vitesse mais de débit.

On n'est pas dans un fleuve pour parler de débit même si ce terme est couramment utilisé, je ne l'aime pas beaucoup.

Maintenant, dans l'usart il y a 1 start-bit. Ensuite viennent les bits qui vont servir à créer un octet de donnée et enfin 1 stop-bit

Le premier et le dernier prennent effectivement beaucoup de temps, par exemple pour 9600 bauds

start-bit = 104 µs, ce qui représente avec un microcontrôleur qui tourne comme le mien (1 intruction = 62.5ns) 104 / (62.5/1000) = 1664 instructions

Largement de quoi envoyer 1 pixel à l'écran, ce qui prouve qu'il y a un problème dans les émulateurs de port série.

D'autre par : 9600 bauds = 960 octets, on ne compte pas le start-bit et le stop-bit.

J'ai demandé à ChatGPT pourquoi il y avait un temps aussi long, elle m'a répondu que c'est normal sur un émulateur de port série.
sans rentrer dans les détails qu'elle m'a expliqués.

Si tu es curieux, demande à ChatGPT.

A+

[paulfjujo]

9600bauds à 10 moments (start+ 8bits data +stop ) soit 10bit * 104 = 1040µS
1 000 000 / 1040 => 961 bytes/sec

on peut effectivement effectuer 166 NOP ...
tu negliges les temps necessaires à manipuler , tranferer les datas

J'ai remarqué aussi ,que le gros Chat racontes pas mal de conneries ..

il faut utiliser un fichier binaire à envoyer à L'uart , au lieu d'un fichier ascii representant les données en hexadecimales
le byte reçu par l'uart pouvant alors etre directement envoyé dur le registre SPI TX

sinon il faut decoder l'ascii pour pouvoir l'utiliser (au fil de l'eau)
0XD6 ascii -> binaire pur 11010110