Discussion :

[Artemus24]

Salut à tous.

Dans ce didacticiel où il est question de port série et de Raspberry Pi 4B, on fait l'usage de "minicom".
--> Utiliser le port série du Raspberry Pi 4 et Pi 400.
(Voir le test à la fin du didacticiel).

Afin de tester l'utilitaire "minicom", on place une résistance de 1K ohms entre la broche 8 (GPIO14 : TxD) et la broche 10 (GPIO 15 : RxD).
Lorsque l'on se met en mode écho (CTRL-A E) et que l'on fait l'usage à la frappe du caractère "é", celui-ci est interprété en retour différemment "Ã".

Quand j'ai fait ce test, mon clavier est configuré en "utf-8" et plus précisément en "fr_FR.UTF-8".
Jusqu'à présent, je n'ai jamais rencontré de problème de configuration avec ma Raspberry Pi.
Il me semble qu'il doit y avoir une interprétation en "ISO-8859-1" quelque part.
Sauf que je ne sais pas où comment corriger cela.

J'avais déjà relié une de ma raspberry Pi 4B à mon ordinateur Asus (Windows 10 Pro) avec un cordon USB-TTL, les accents étaient bien gérés.
De même, j'avais configuré une Raspberry Pi Zero en mode TTL, en faisant du bare metal.
Afin d'avoir les résultats à l'affichage, j'ai fait usage de la console. Aucun problème d'accents !

Comment ce fait-il que les caractères avec accents sont mal interprétés avec "Minicom" ?

Cordialement.
Artemus24.
@+

[Delias]

Bonsoir Artemus

Problème classique d'encodage.
Le RS232 ne transmet que des octets, sans en définir la signification. Un terminal va appliquer un code-page pour transformer cela en caractères.
Le problème c'est que l'encodage UTF-8 ne se limite pas à un octet par caractère.
J'ai bien envie de dire que à est le caractère de la page de code que minicom utilise correspondant au premier octet de é en UTF-8.

Mais vu la doc inexistante de minicom, il ne reste que la rétro-ingénierie du code pour comprendre.

Coder un terminal qui travail en UTF c'est théoriquement possible (on met en attente la réception d'un octet ne commençant pas par 0, jusqu'à avoir eu les octets nécessaire à l'affichage du caractère), mais cela pose problème, on fait quoi quand un octet commençant par 11 est reçu sans un autre à la suite.

Delias

[Artemus24]

Salut Delias.

Un terminal va appliquer un code-page pour transformer cela en caractères.

Ou est définie ce code-page ? Est-ce dans Minicom ? Dans le terminal ? Ailleurs ?

Dans le mode écho, le caractère d'entrée est mal interprété. Le caractère de sortie est correcte.

J'ai bien envie de dire que à est le caractère de la page de code que minicom utilise correspondant au premier octet de é en UTF-8.

Rectification, le "é" est interprété par "é" à l'affichage en entrée.
En UTF-8, le caractère "é" se code sur deux octets.
Soit "11000011 10101001" ce qui donne en hexadécimal "C3 A9".

La codification de cette section de l'UTF-8 correspond aux caractères de l'ISO-8859-1.
La correspondance donne :
--> C3 : Ã
--> A9 : ©

Ton interprétation est correcte.

Mais vu la doc inexistante de minicom, il ne reste que la rétro-ingénierie du code pour comprendre.

J'ai regardé la documentation mais je n'ai pas trouvé comment adapter le caractère en entrée dans mminicom.
Par contre, j'ai trouvé comment adapter le caractère en sortie, saif que ce n'est pas lui le problème.

Tout se passe comme si mon clavier envoyait de l'UTF-8 mais interprétait les octets en ISO-8859-1.
Comment mettre mon clavier en UTF-8 ?

Il n'est pas relié à la raspberry. C'est le clavier de mon ordinateur Windows.

Merci pour tes explications.

Cordialement.
Artemus24.
@+

[Artemus24]

Salut à tous.

Je n'ai pas précis dans mon test que j'utilise minicom en circuit fermé, ce qui sort est réinjecté en entrée.

Ne sachant pas si le problème est d'ordre général ou juste spécifique à l'usage que je fais de ce minicom, il n'est toujours pas résolu.
J'aimerai bien avoir début de solution pour clôturer le sujet.

Cordialement.
Artemus24.
@+