Windows XP intégré - Problèmes RS485

Question

Nous avons un système sous XP intégré, COM2 étant un port matériel RS485.

Dans mon code, je configure le DCB avec RTS_CONTROL_TOGGLE . Je suppose que cela ferait ce qu'il est dit ... désactiver RTS en mode noyau une fois que l'interruption d'écriture vide survient. Cela devrait être pratiquement instantané.

Au lieu de cela, nous voyons sur un oscilloscope que le PC pilote le bus de 1 à 8 millisecondes de plus que la fin du message. Le périphérique auquel nous parlons répond dans environ 1 à 5 millisecondes. Alors ... les corruptions de communication à gogo. Non, il n'y a aucun moyen de changer le temps de réponse de la cible.

Nous avons maintenant connecté le port RS232 et connecté la portée aux lignes TX et RTS, et nous voyons la même chose. La ligne RTS reste élevée entre 1 et 8 millisecondes après l'envoi du message.

Nous avons également essayé de désactiver la FIFO ou de définir la profondeur de la FIFO sur 1, sans effet.

Des idées? Je suis sur le point d'essayer de contrôler manuellement la ligne RTS depuis le mode utilisateur avec la priorité REALTIME pendant la procédure "SendFile, clear RTS". cycle. Je n'ai pas beaucoup d'espoir que cela fonctionnera non plus. Cela ne devrait pas être fait en mode utilisateur.

Answer 1

RTS_CONTROL_TOGGLE ne fonctionne pas (dispose d'un délai variable de 1 à 15 millisecondes avant de l'éteindre après la transmission) sur notre plate-forme XP intégrée. Il est possible que je puisse le réduire si je modifiais le délai quantique à 1 ms en utilisant timeBeginPeriod (1), etc., mais je doute que ce soit fiable ou suffisant pour avoir de l'importance. (L’appareil répond parfois à 1 milliseconde)

La solution finale est vraiment moche mais cela fonctionne sur ce matériel. Je ne l'utiliserais sur aucun matériel dont le matériel n'est pas figé.

Fondamentalement:

1) définissez les FIFO de la page du gestionnaire de périphériques du port série sur off ou sur 1 caractère

2) envoyez votre message + 2 octets supplémentaires à l'aide de ce code:

int WriteFile485(HANDLE hPort, void* pvBuffer, DWORD iLength, DWORD* pdwWritten, LPOVERLAPPED lpOverlapped)
{
  int iOldClass = GetPriorityClass(GetCurrentProcess());
  int iOldPriority = GetThreadPriority(GetCurrentThread());
  SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
  SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

  EscapeCommFunction(hPort, SETRTS);

  BOOL bRet = WriteFile(hPort, pvBuffer, iLength, pdwWritten, lpOverlapped);

  EscapeCommFunction(hPort, CLRRTS);

  SetPriorityClass(GetCurrentProcess(), iOldClass);
  SetThreadPriority(GetCurrentThread(), iOldPriority);

  return bRet;
}

WriteFile () est renvoyé lorsque le ou les derniers octets ont été écrits sur le port série. Ils ne sont pas encore sortis du port, d'où la nécessité d'envoyer 2 octets supplémentaires. L'un ou l'autre d'entre eux seront mis à la corbeille lors de la réalisation du projet CLRRTS.

Comme je l'ai dit ... c'est moche.

Answer 2

  

Des idées?

Il se peut que le DDK contienne un code source pour le pilote de port série, ce qui vous permettrait de voir comment cette option est supposée être mise en œuvre: c'est-à-dire au niveau des interruptions, au niveau de DPC ou pire.

D'autres possibilités incluent la réécriture du pilote; en utilisant un pilote tiers RS485 si vous en trouvez un; ou en utilisant du matériel RS485 tiers avec son propre pilote (par exemple, au moins dans le passé, les tiers utilisaient pour créer des "cartes de port série intelligentes" avec 32 ports, des mémoires tampons profondes et son propre microprocesseur; été résolu par quelqu'un).

8 millisecondes semble être un temps décevant; Je sais que XP n'est pas une RTOS mais je m'attendrais à ce qu'il fasse (généralement) mieux que cela. Une autre chose à vérifier est de savoir s'il existe d'autres threads de haute priorité pouvant interférer. Si vous avez renforcé les priorités de certains threads dans votre propre application, vous devriez peut-être plutôt réduire les priorités des autres threads.

  

Je suis sur le point d'essayer de contrôler manuellement la ligne RTS depuis le mode utilisateur avec la priorité REALTIME pendant la procédure "SendFile, clear RTS". cycle.

Ne laissez pas ce fil devenir incontrôlable: un tel thread peut, s'il est erroné, préempter indéfiniment tous les autres threads en mode utilisateur.