RS 232 Signal Break

Michael Burr description de la façon de briser les œuvres sont exactes. Souvent, les "casser" les signaux sont envoyés depuis largement plus d'un personnage le temps.

Ces jours-ci, "Pause" est rarement utilisé dans la série comms, mais l'utilisation la plus courante est comme un "pas cher" façon de fournir la synchronisation des paquets. "Pause" peut être envoyé avant un paquet commence, pour alerter le récepteur, un nouveau paquet est sur le chemin (et de permettre la remise à zéro de tampons, etc.) ou à la fin d'un paquet, pour signaler que plus aucune donnée n'est prévu. C'est une sorte de "méta-caractère" dans la mesure où il vous permet de garder la gamme complète de 8 ou 7 bits de valeurs pour les paquets de contenu, et vous inquiétez pas sur la façon de début ou de fin de paquet sont délimitées.

Pour envoyer une pause, généralement vous appelez SetCommBreak, attendre un laps de temps approprié (par exemple, autour de 2 millseconds à 9600 bauds) puis d'appeler ClearCommBreak. Pendant ce temps, vous ne pouvez pas envoyer quoi que ce soit d'autre, bien sûr.

Donc, en supposant que le protocole exige que "briser' au début du paquet, je le ferais (désolé pour le pseudo-code):-

procedure SendPacket(CommPort port, Packet packet)
{
    SetCommBreak(port)
    Sleep(2);  // 2 milliseconds - assuming 9600 baud. Pro-rata for others
    ClearCommBreak(port)

    foreach(char in packet)
        SendChar(port, char)
}

Pseudo-code pour un récepteur est plus difficile, parce que vous avez à faire une charge d'hypothèses sur les paquets entrants format et les appels de l'API utilisée pour recevoir des pauses. Je vais l'écrire en C cette fois, et supposons l'existence d'un imaginaire de la fonction. WaitCommEvent est probablement la clé de la manipulation entrant Pauses.

bool ReadCharOrBreak(char *ch); // return TRUE if break, FALSE if ch contains received char

Nous supposerons aussi fixe-longueur 100 octets des paquets avec "break" envoyé avant chaque paquet.

void ReadAndProcessPackets()
{
  char buff[100];
  int count;

  count = 0;

while (true)
{
  char ch;
  if (ReadcharOrBreak(ch))
    count = 0; // start of packet - reset count
  else 
  {
     if (count < 100)
     {
       buff[count++] = ch;
       if (count == 100)
         ProcessPacket(buff);
     }
     else 
       Error("too many bytes rx'd without break")
  } 
} 

AVERTISSEMENT - totalement non testé, mais devrait vous donner l'idée...

Pour un exemple d'un protocole à l'aide de Pause, découvrez la DMX-512 d'éclairage d'étape de protocole.

Le début d'un paquet est signifié par
une Pause suivie par une "marque" (un
logique) connue comme la "Marque Après
Pause" (MAB). La pause des signaux de fin de
un paquet et le début de la prochaine.
Il provoque les récepteurs à démarrer
de la réception. Après la pause jusqu'à 513
les fentes sont envoyés.

OriginalL'auteur Roddy

"Pause" a été prévu pour quand la synchronisation est devenu complètement mélangé.

Je suis censé quitter pour chaque octet de données que j'ai envoyer. Ou envoyer un octet de données, puis de basculer.

Essayer d'envoyer une belle et longue "pause" du signal (500 ms?) puis attendre un peu (50 ms?) ensuite, l'envoi de vos données.

OriginalL'auteur Marsh Ray

Vous devriez être en mesure de voir les données que le port d'envoi. Vous aurez besoin d'un câble null-modem, un ordinateur avec un port série (ou un serial-dongle USB) et un programme de terminal (tel que HyperTerminal sous Windows -- pas inclus dans Vista). Si vous configurez votre programme de terminal de manière satisfaisante (bonne vitesse, nombre de bits de données, le réglage correct de la start-stop, et le port correct) toutes les données s'affichent à l'écran.
Parfois, il est nécessaire d'appuyer sur la touche entrée pour commencer à voir les données. Vous pouvez modifier le réglage pour le programme de terminal au cours de l'essai pour voir si quelque chose change ("bruit" pour les données).

OriginalL'auteur Edmundo