È possibile il controllo a basso livello di RS232 (Com-Port) RTS/CTS/DTR/DSR?

Question

Mi chiedo se e come sia possibile controllare le linee di handshaking RS-232 direttamente da win32 (la vecchia C-API).

Mi piacerebbe interfacciarmi con un componente hardware esterno e due semplici linee di dati sarebbero sufficienti per le mie esigenze.

Quindi, c'è una API per win32 che mi consente di leggere e scrivere lo stato delle quattro righe di stato? Nella normale comunicazione seriale le linee di handshaking sono guidate automaticamente da UART (se l'handshake hardware è abilitato).

Ricordo che era banale sotto DOS. Si doveva solo programmare direttamente la UART. Questa funzionalità è sopravvissuta in Win32 in qualche modo?

Answer 1

È possibile controllare RTS e DTR utilizzando SetCommState(). È inoltre possibile impostare le cose in modo che hardware o il driver gestiscano il controllo del flusso hardware (CTS e/o DSR), oppure è possibile impostare le cose utilizzando SetCommMask() in modo da ottenere eventi quando tali segnali cambiano.

Una panoramica decente è qui: http://msdn.microsoft.com/en-us/library/ms810467.aspx

Nota che l'API di Comunicazione Seriale Win32 e/o driver può essere schizzinoso, quindi preparatevi a fare qualche messa a punto di quello che sta succedendo sul filo.

Answer 2

È ancora possibile eseguire tipi di programmazione simili solo per accedere all'hardware protetto. Sarà necessario implementare un driver di periferica. Presumo che questo sia diventato più facile dagli anni '80, quando stavo facendo lo stesso tipo di lavoro.

Answer 3

Microsoft sta effettivamente eseguendo l'handshaking hardware ora? Per molti anni NT, win2000 e XP non hanno fatto l'handshaking nell'hardware. Invece quando il fifo raggiunse un certo punto, il driver del dispositivo cambierebbe manualmente la linea dei cts. Il che significa che è incredibilmente semplice far perdere dati al driver del dispositivo, afferrare una finestra con il mouse e fare cerchi intorno allo schermo, ad esempio (assicurandosi di togliere quella finestra dalla parte sinistra dello schermo su tutti o alcuni dei passaggi). Alt-enter per prendere un prompt dei comandi da/a schermo intero era un modo semplice per causare una perdita di dati. O qualsiasi altra cosa che causa abbastanza interruzione di latenza. Fondamentalmente, il controllo del flusso hardware dei microsofts non è hardware ma controllo del flusso software, anche se l'hardware ha capacità di controllo del flusso hardware i driver di microsft non hanno impostato quel bit. SeaLevel alla fine ha supportato quel bit, beh, in qualche modo, dovevi mettere le corrette impostazioni indipendenti in SetCommState() per abilitarlo.

Per quanto riguarda il programma che controlla i segnali, utilizzare SetCommState().

Answer 4

Mi sono imbattuto nel tutorial this quando ho dovuto eseguire un progetto per comunicare con la porta RS232. È un esempio completo su come aprire la porta, impostare alcune proprietà tra cui i timeout, leggere/scrivere e chiudere la porta. Anche se il tuo progetto è probabilmente finito ormai, spero che rimarrà utile in quanto rimane negli archivi SO.

Answer 5

Ci sono alcuni adattatori da USB a seriale che non supportano il controllo di flusso DTR/DSR/DCD. Quindi potrebbe essere questo il tuo caso.

http://www.digi.com/support/kbase/kbaseresultdetl?id=588