Eric.D a écrit:Tazz28 a écrit:1 UART est normalement suffisant.
Comme mon truc doit être 100% compatible UGS, l'état des port trig n'étant pas latché et les retours étant également multiplexés, il s'accorde d'un break (repassage au 0v) de la ligne quand l'UGS va faire autre chose.
Si il y avait de la signalisation non sollicité (emergency shut down ou autre) il pourrait attendre que la ligne passe à l'état haut pour envoyer son message.
Coté UGS version Muse, on a le port trigger soit configuré en trigger version Flat (type pulse positif), soit en mode UART (format classique NRZ).
Un moyen de détecter un tel cas serait coté UGS de venir détecter sur sa ligne RX un état bas permanent forcé par le trigger d'en face qui signale ainsi "j'ai besoin de t'envoyer des données".
Quand l'UGS détecte ce cas, il envoi une commande demandant au module esclave d'envoyer les données après avoir préalablement remis son signal à l'état de repos (cad à "1").
Oui, c'est exactement ce que je pensait faire/spécifier, sauf qu'il n'y a même pas besoin de que l'UGS envoie la commande de flush des données. A partir du moment ou il scrute le port (précédemment détecté comme UART "enhanced"), il passe sa ligne TX à 1. Elle passe nécessairement à 0 quand la ligne de trig n'est pas sélectionnée/scrutée (break condition coté carte trig) sur l'UGS original.
Le même protocole peu être adopté sur le muse.