Possibile 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 API C).

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

Quindi - esiste un'API per win32 che mi permette di leggere e scrivere lo stato delle quattro righe di stato? Nella normale comunicazione seriale le linee di handshaking sono guidate automaticamente dall'UART (se l'handshaking hardware è abilitato).

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

Answer 1

Puoi controllare RTS e DTR usando SetCommState () . Puoi anche impostare le cose in modo che l'hardware o il driver gestiscano il controllo del flusso hardware (CTS e / o DSR), oppure puoi impostare le cose usando SetCommMask () in modo da ottenere eventi quando questi segnali cambiano.

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

Nota che l'API e / o il driver di comunicazione seriale Win32 possono essere pignoli, quindi preparati a fare un po 'di debug di ciò che sta succedendo sul filo.

Answer 2

Mi sono imbattuto in questo tutorial quando dovevo fare 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 probabilmente il tuo progetto è ormai terminato, spero che questo rimarrà utile come rimane negli archivi SO

Answer 3

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

Answer 4

Microsoft sta attualmente eseguendo l'handshaking hardware? Per molti anni NT, win2000 e XP non hanno eseguito l'handshaking nell'hardware. Invece quando il fifo ha raggiunto un certo punto il driver del dispositivo cambierebbe manualmente la linea cts. Ciò significa che è stato incredibilmente semplice far perdere dati al driver del dispositivo, prendere una finestra con il mouse e fare cerchi attorno allo schermo, ad esempio (assicurandosi di togliere quella finestra dal lato sinistro dello schermo su tutti o alcuni dei passaggi ). Alt-invio per portare un prompt dei comandi a / da schermo intero era un modo semplice per causare una perdita di dati. O qualsiasi altra cosa che causi abbastanza una latenza di interruzione. Fondamentalmente il controllo del flusso hardware di microsoft non è hardware ma controllo del flusso software, anche se l'hardware ha capacità di controllo del flusso hardware i driver di microsft non stavano impostando quel bit. SeaLevel alla fine ha supportato quel po ', beh, hai dovuto mettere le giuste impostazioni non correlate in SetCommState () per abilitarlo.

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

Answer 5

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

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