Minitel ESP32 - Carte Péri-informatique Wifi / BLE

Ok, c’est bien probable

J’ai deja ajouté une résistance de limitation de courant par rapport à ce que j’ai pu trouver sur le net, mais je suis toujours pas serein avec le Tx provenant du minitel.

J’ai une petite idee de protection supplémentaire à base de transistor PNP à tester, je vous tiens au courant …

Les commandes AT, c’était bien en sortie de l’ESP, vers le smartphone… J’ai pas du être très clair dans mon propos :slight_smile:

1 « J'aime »

Bon en fait, sur le Minitel 1B le Tx est une sortie à collecteur ouvert.
Ce qui veut dire pas de soucis de surtension !
Je comprend mieux pourquoi la zener posait problème sur mon premier schéma …

Bonjour,

J’ai implémenter les dernières modifications sur le pcb, préparer les gerber pour avoir une estimation de coût, Et là, mauvaise nouvelle : le convertisseur buck que j’avais utilisé dans ma v1 est en pénurie.

Attendre ou modifier le convertisseur ? :confused:
+Attendre: estimation prochain arrivage pour juin 2022
+Modifier: bcp de travail car pas trouvé d’équivalent disponible dans le même package, il y a des dispos dans des packages bcp plus grands donc problème de place potentiellement

Hum hum - pénurie vraiment partout ?

==> Serait dommage de mettre en pause ce projet 6 mois pour juste ce détail.

Du coup, j’ai regardé ta vidéo … et je vais aller aussi jeter un oeuil à « freechess ».

J’ai regardé mouser farnell digikey radiospare et j’en passe.

Seul des sites comme aliexpress me propose des résultats, mais j’ai pas envie de m’y risquer pour un composant de ce type (pas standard, complexe, haute frequence, etc …)

Les « géants » quoi … T’as regardé chez les allemands par hasard (je ne sais pas trop qui, mais, certainement, il doit y avoir, même en mode hobbyste ) ?

Sinon, quelles sont les options ?

  • Attendre 6/9 mois (au mieux)
  • Composant alternatif (et plus gros)
  • china.com

==> P’t’et qu’on peut se contenter de l’option #2 pour quelques pièces ? [quitte à faire un sale bricolo et à ne pas changer le PCB ?]

Ayant deja des modifs à faire sur le pcb (ajout connecteur 2.54mm), j’en profite pour partir sur l’option 2 : changement du circuit intégré d’abaissement de tension.
Si tout se passe bien, cela retardera le « batch » d’1 mois environ, le temps de refaire un exemplaire de validation.

1 « J'aime »

Ca me parait raisonnable … As-tu déjà une idée de coût final ?

Mon objectif est de rester dans la fourchette annoncée initialement de 30 à 40 eur l’unité
J’y passe beaucoup de temps, mais ça doit rester accessible !

Bonjour à tous,
Je commence par donner qqs nouvelles avant de solliciter votre opinion !

Les news

Je devrais recevoir la nouvelle version de la carte d’ici 1 semaine,
Et je profite de ce temps pour mettre au propre quelques programmes, et essayer de compléter les exemples d’utilisation. Les sources seront publiés ici: iodeo/Minitel-ESP32 · GitHub

Les exemples de la vidéo arriveront ces jours-ci. ils sont programmés avec Arduino IDE en utilisant le core Arduino-ESP32 et la librairie Minitel1b_Hardware de @eserandour.

De plus, j’ai enfin réussi à établir une session shell via ssh sur l’ESP32 !
Le code est aussi sous Arduino, basé sur LibSSH-ESP32 (github/ewpa) qui est un portage de libssh.
La liaison série avec le minitel est une simple redirection des stdin/stdout vers les broches du minitel, ce qui fonctionne pas trop mal grâce au mode téléinformatique :slight_smile:

En parallèle, j’ai vu pas mal de sources en python autour du minitel,
notamment @cquest @zigazou @hwarin,
et je suis plutôt enthousiaste à l’idée de pouvoir les utiliser sur ESP32.
Alors ça tombe bien, il existe un firmware MicroPython :cowboy_hat_face:
Je fais mes 1er pas dans cet environnement avec Thonny IDE, qui est très accessible.
Le seul bémol est le nombre limité de librairies par rapport à python.

Votre avis ?

  • Est ce que verriez un intérêt à porter des applications pythons sur l’ESP32 ?
  • Et si oui, quelle serait la librairie de référence à porter en MicroPython pour la liaison avec le minitel ?

Bonne nouvelle … !

Quelques réflexions en vrac :

  • mode teleinfo : tu mets de côté tous les m1. Je deconseillerai d’autant que beaucoup d’emulations ne le supportent pas non plus
  • applications à porter : tout dépend des use-case que tu imagines. Pour de moment, je n’en vois que 2 (mais il peut s’en imaginer d’autres certainement)
    Principalement, connecter un Minitel à un serveur videotext moderne en Telnet ou WS … Quelque chose comme PyMoIP-user …
    En second, une interface utilisateur dans le cadre d’une application … X ? On connaît les limites du graphisme videotext mais l’intégration clavier/écran peut avoir son intérêt

J’ai jeté un oeil à PyMoIP-user, ça à l’air top !

Si je comprends bien, ça permettrait d’aller sur un serveur comme HACKER sur un vrai minitel depuis la prise peri-informatique ?

J’ai vu 2 versions, et j’avoue avoir une préférence pour la démarche de la 1ère version, avec une librairie dédiée pour la liaison minitel de zigazou. Je suis loin d’avoir tout les tenants-aboutissants, mais n’est ce pas une approche plus réexploitable pour de futurs applications X ?

Pour l’heure, j’ai fait une 1ère approche pour mieux estimer ce que cela représente comme travail. Je suis parti de la librairie pynitel de @cquest et j’ai pu lancer qqs commandes basiques genre effacement ecran (home), ecrire du texte (_print), récupérer la saisie clavier (get).

C’est assez épatant l’approche interpreteur sur microcontroleur !
D’un côté on peut tester les requêtes en live, très pratique pour dev, et de l’autre on peut uploader un code complet par simple transfert de fichier :flushed:

Le gros du travail est de repertorier les librairies manquantes et de trouver un substitut pour chaque fonctions utilisées

Si on pouvait avoir une librairie micropython qui gère la liaison série avec le minitel, ce serait deja pas mal je pense !

Oui … Hacker, ou n’importe quel autre truc marchant en WebSockets

Oui … La V1 était (en toute logique !) ma première approche … J’ai laissé tomber cette idée au profit de la V2 (en toute logique aussi) … J’explique pourquoi j’ai préférer abandonner la librairie de Zigazou (qui est très bien ceci dit) pour le reste des développements de PyMoIP.

L’idée de PyMoIP c’est :

  • Un serveur videotext multi-voies modulaire en WebSocket [PyMoIP-Server]
  • Une passerelle WebSocket + Telnet ==> WebSocket (+Telnet dans le futur) supportant la redirection [PyMoIP-Gateway]
  • Une interface « appelante » série (Minitel et Hayes) ==> WebSocket [PyMoIP-User]
  • Une interface « recevante » WebSocket ==> série (simulant un Minitel ou un modem Hayes) [pas encore de nom … mais ca viendra j’espère un jour]

Ces 4 bouts de code permettent de faire le lien entre « l’ancien monde » et le « nouveau monde ».

Du point de vue du terminal, on s’en sort avec :

  • L’émulateur de Zigazou est bien le point d’entrée stratégique du « nouveau monde ». Bien que souffrant de quelques lacunes, il est quand même très bon et permet au quidam d’approcher une expérience plutôt juste du terminal et du peu de contenu videotext subsistant en utilisant les navigateurs web supportant HTML5 (pas de java, aucune installation nécessaire, compatibilité avec « tout » [Windows, Linux, Mac, Android]) … bref, l’idéal, mais c’est le seul ! J’y ai apporté quelques modifications pour combler les soucis essentiels (support de la touche ‹ connexion/fin › et réponse à l’ENQ-ROM).
  • D’autres émulateurs plus ou moins faciles d’approche existent, mais uniquement en mode telnet : i-Timtel (#), HyperTerminal, xTerm (#) (jamais essayé) … il y en a eu pléthore sur toute la période 1990-2010 qu’il serait d’ailleurs souhaitable de retrouver.
  • Les terminaux physiques (Minitels) les plus fréquents disposent d’un connecteur série (prise péri-informatique) et nécessitent un programme intermédiaire pour initier une session Telnet ou WebSocket ainsi qu’un câble de liaison spécifique. Quelques problèmes de compatibilité sont à envisager en raison du mode de fonctionnement local versus connecté. (##)(#)(###)
  • Les derniers terminaux physiques (Minitel-phone et Web-phone) … là, c’est plus hard-core car le modem est la seule voie possible (?#) (?##)(###) avec éventuellement un modem local et une ligne PSTN fantôme
    (#) Permet le décodage photo
    (##) Use-case principal que je vois aujourd’hui à ton projet Minitel<=>ESP32
    (###) Approche alternative : Accès via VoIP à une solution Asterisk + SoftModem V23

Du point de vue serveur, c’est pas brillant :

  • Il n’existait pas de serveur videotext multi-voies « moderne » (WebSocket) et, à ma connaissance, aucun code serveur n’est ni ouvert ni supporté : impossible de créer « facilement » un serveur afin de proposer du contenu nouveau en videotext, sauf à utiliser des « vieux machins » principalement mono-voie.
  • Les quelques serveurs existants en WebSocket ont choisi des paramètres mutuellement incompatibles et ils ne se sont pas fédérés autour d’un portail commun (qui de toute façon n’existait pas - hors de la mention sur la page « museeminitel.fr ») … l’âge de pierre quoi !
  • Il n’existait pas de passerelle Telnet ==> Websocket permettant d’utiliser les anciennes émulations.
  • Il n’existe pas (encore) de passerelle Websocket ==> Telnet permettant d’utiliser l’émulation HTML5 (sur le seul/dernier serveur videotext Telnet existant encore).
  • Il n’existe plus (pas encore) de numéro d’appel V23 unique permettant d’accéder à l’ensemble des serveurs videotext (Minitel)

Pourquoi la V1 de PyMoIP-User ?

Je voulais pouvoir utiliser un Minitel normal et sur Hacker, et les autres serveurs subsistant en WebSocket sans avoir à me prendre la tête avec la VoIP (pas de prise téléphonique sous la main, mauvaise qualité de transmission …). J’avais besoin d’une interface utilisateur minimale ‹ vite-fait › pour saisir un code de service (Hacker, Teaser, etc) et j’ai utilisé la librairie de Zigazou. Sauf que (de mémoire) le code est bloquant, ca va bien pour un truc minimal, mais c’est impensable pour un serveur multi-voies. De plus, le comportement de l’éditeur ne me plaisait pas (trop compliqué et/ou incompatible avec le M1) ainsi que le traitement interne en unicode et il y avait tout un tas de fonctionnalités qui ne m’intéressaient pas du tout. Bref, la V1 marche et fait le taff mais ne permet pas de faire exactement ce que je voulais, et le code est môche.

Entre temps, j’ai démarré le projet serveur … blabla … qui marche bien, est modulaire, relativement simple et souple - en WebSocket uniquement et sans unicode ni librairie spécifique, principalement en ASYNCIO. Il y a encore du travail sur les modules, la propreté du code, la doc mais c’est globalement bien avancé et stable. J’ai 3 ou 4 instances de services qui tournent sur le même RPi.

Ensuite, j’ai codé la passerelle qui est capable de recevoir des sessions WS ou Telnet, de les rediriger, de traiter les timeout. Là aussi, c’est plutôt stable maintenant (bien qu’il reste plein d’idées d’améliorations).

Une fois le serveur et la passerelle opérationnels, la V1 de PyMoIP-User n’avait plus de sens (ou du moins, l’éditeur et la librairie de Zigazou). La V2 se contente de faire son boulot : série <=> WebSocket, c’est le serveur videotext qui traite les demandes quelque en soit l’origine et la passerelle qui reçoit la session de l’utilisateur, et qui la redirige au besoin. Par ailleurs, la V2 est plus subtile notamment dans le traitement des pages photo et la gestion du port série/modem Hayes en 7 ou 8 bits.

Bon … pour en revenir à notre affaire après ma longue digression, hormis la librairie PySerial, je ne pense pas qu’il existe une librairie permettant de faire « des merveilles utiles » même si je n’ai pas trop cherché (pas trop le temps pour le moment) … Il faudrait un truc permettant de construire des structures de menus, avec un affichage rapide et compatible avec tous les terminaux, d’y naviguer par suite/retour/envoi/sommaire, permettant l’affichage de formulaires et de champs de saisie contrôlés.

Un machin où tu « dois » appeler Clear() pour effacer l’écran, bof bof, envoyer un 0x0c fait tout pareil. Idem pour le Get() et la saisie au clavier … si tu ne peux pas afficher l’état de la liaison Wifi pendant que tu attends un caractère au clavier … bof bof.

Merci pour toutes ces explications,
Je vais avoir besoin de relire qqs fois je crois :sweat_smile:

J’ai beaucoup digressé …

Le modèle OSI… séparation des couches présentation et application :wink:

… Oui, mais en l’espèce, dans un contexte asynchrone/multi-utilisateurs, soit il faut ‹ tout retourner ›, soit une tâche par bonhomme … Ceci dit, ca ne s’applique pas totalement/nécessairement à ce projet d’ESP32 qui ne connait qu’un clavier/écran …