Dcc++

[msport]

port libre au moment où tu as essayé? oui rien d'autre dessus - pas d'IDE ou de terminal
Par ailleurs, il faut parfois essayer deux fois. plus de deux fois
La comm est bien à 115200 Bds? oui forcé via le gestionnaire de périphériques

Bonjour,
rando courte, de retour aux manettes !
donc deuxième test (VO) sur un portable W7, c'est le COM6 qui s'y colle.
CDM 6.01 donne les deux messages capturés. (+ 3e)
Et curieusement les rails mis sous tension avec la manette se sont mis hors tension après le 2ème (ou 3e) message.
J'ai testé avec YAT sur COM6, la réponse au <s> est immédiate et complète. Il ne semble pas qu'il y ait des caractères parasites avant le <p0>
EDIT : j'ai testé la nouvelle dll : même résultat.
A suivre.

[jpp38]

OK. Là, je ne peux rien de plus.
Avec un telle différence de comportement, à distance, c'est juste impossible.

On va attendre de voir si Xavier rencontre le même problème.

JP

[jpp38]

Si vous voulez regarder de plus près ce qui se passe, voici le ZIP du répertoire de travail.
DDGI_DCCpp.dev à ouvrir sous Bloodshed / Dev-Cpp

DDGI_DCCpp.zip

(96.27 Kio) Téléchargé 38 fois

La fonction d'ouverture est DCPI_GetAsciiVersionInfo() dans le module principal DDGI_DCCpp.c.
On peut rajouter des fenêtres de message (MessageBox), ou décommenter celles qui y sont déjà, pour voir de plus près ce qui transite sur la Data comm.

JP

[msport]

Un début d'analyse :
PC fixe W10 : cannot write = le port n'est pas identifié.
Portable W7 : cannot read = apparemment la commande <s>(?) n'est pas comprise ou pas reçue.
J'ai mis un convertisseur USB FTDI sur le serial d'un arduino avec un TFT 4X20 (COM5, mis à 115400, 8, none? vérifié avec YAT) et ai lancé CDM avec serveur DCC++. J'ai reçu des caractères non affichables.
En attendant, peux-tu dire quel devrait-être le dialogue initial ? (<s> ?) Configure-tu le port virtuel série ? Comment ?
Comme vu sur mon banc de test, j'ai un UNO. Sur le RX/TX, j'ai un module radio que j'ai tenté d'enlever avec CDM, sans succès, mais il est resté présent pour les tests sans CDM, il ne pose donc à priori pas de problème (heureusement, ce serait dommage de se priver des manettes).
Mais on peut attendre Xavier.
EDIT : je regarde la dll.

[Xavier]

Bonsoir,

msport: attention la vitesse n'est pas 115400 mais 115200. Mais ce n'est peut-être pas ça!

JP:

l'exploration de la chaine mériterait d'être accélérée, dans l'avenir

J'ai peut être une solution. En effet j'ai un scan par ms. En remplacant les millis par des micros (voir S88.CPP ligne 19 en commentaire) je peux essayer de faire un scan tous les 0.1ms. Par conter si je me rappelle bien, il y a de la conversion dans l'air!

J'espère pouvoir tester ce week-end: merci pour cette version !

Amicalement,

Xavier

[jpp38]

Bonsoir Xavier,

J'ai peut être une solution. En effet j'ai un scan par ms.

Par ms??? Ca me paraît très court. Pas pour toute la chaîne quand même?
En pratique, sur le FIS88, je fais un scan tous les 100ms (1/10 e seconde), et c'est largement suffisant au niveau du temps de réaction.

Pour la DLL, msport a des problèmes avec: pas moyen de se connecter.

Bonne soirée.

JP

[Xavier]

Bonsoir,

Tu as raison, j'ai dit scan mais ce n'est qu'un pas du scan et il faut 10 pas pour acquérir un bit pour une zone: c'est donc beaucoup plus lent!

Bonne soirée.

[Xavier]

J'ai craqué ... c'était insoutenable !

PC tour sous Windows 7 professionnel SP1 32bits
USB en com 12
Arduino Mega 2560 (clone chinois) + Shield moteur (sans Ethernet)

Et ... les mêmes messages d'erreur

"Aucune interface trouvée sur les ports COM/USB ou IP"

De même avec la Dll avec des tempos allongées pour l'écriture.

Amicalement,

[msport]

Bonkour,

(je crois me souvenir de ce pb pour les port COM > 10)

Ca, c'est un problème résolu depuis longtemps.
J'ai mis au point sur un port 31.

Est-ce que dans la dll on parle de 7bits ou 8bits et de parité ? l’Arduino sur son serial hardware, ne gère que 8 bits, none.

Ne perds pas de temps avec ça. J'ai fait la mise au point avec 8 bits sans parité, qui est la config par défaut de tous les émulateurs de terminal.
Donc ceux que vous utilisez sont configurés comme ça, sauf si vous avez changé explicitement la conf. (ce qui a priori n'est pas le cas).

En fait, ça tourne surement autour des diverses tempos de la Data comm, que j'ai déjà considérablement augmentées par rapport au standard que j'utilise pour toutes les liaisons de ce type (c'est la sixième interface de ce type que je fais: je n'ai encore jamais vu ça).


Voici une autre DLL sur laquelle j'ai encore gonflé toutes les tempos, et qui affiche les ports COM auxquels elle arrive à se connecter, et toutes les réponses reçues pendant la phase de connexion.

DDGI_DCCpp4.dll

(70.55 Kio) Téléchargé 33 fois

Pour vérifier qu'elle est bien chargée, au moment de sélectionner l'interface à lancer, au lieu de cliquer sur OK, cliquer sur "DETAILS". Ca affiche le numéro de version et la date. Celle-ci est la V6.01d (30/03/2018).


JP

[msport]

Nouvelle dll chargée !
J'ai donc bien la tentative de connexion sur COM3 (modem du portable) puis sur COM6 (USB de l'arduino)
Première tentative sans succès (cannot read 0 char.).
Vérification de la com avec l'IDE puis émotion ! 98 char lus avec le welcome de l'arduino, mais c'est reparti sur cannot read puis IMPOSSIBLE ...
Tu es sur la bonne piste ! Pourquoi provisoirement au moins ne pas pouvoir sélectionner son port COM. On gagnerait du temps avant d'arriver au bon. Ou faire le test en commençant par le haut ?
A bientôt