Risoluzione dei problemi di porta di comunicazione comune QuickBasic

Dichiarazione di non responsabilità per contenuto KB ritirato

Il contenuto di questo articolo è riferito a prodotti per cui Microsoft non offre più il supporto. Questo articolo viene pertanto offerto "così com'è" e non sarà più aggiornato.

Riepilogo

In questo articolo vengono descritti i suggerimenti sulla risoluzione dei problemi per l'utilizzo di comunicazione seriale Microsoft QuickBasic versioni 4.0, 4.0b e 4.5, nel compilatore Microsoft Basic versioni 6.0 e 6.0b per MS-DOS e MS OS/2 e in Microsoft Basic Professional Development System (PDS) versioni 7.0 e 7.1.


In questo articolo fornisce un'istruzione aperto COM di esempio che dovrebbe funzionare correttamente. Vengono fornite anche comunicazioni ulteriori suggerimenti di risoluzione dei problemi. Per un articolo correlato, vedere il seguente articolo della Microsoft Knowledge Base:
39386 spiegazioni messaggio di errore quando si utilizza COM1: e COM2:

Ulteriori informazioni

Nel caso di problemi di utilizzo "COM1:" o "COM2:", eseguire l'istruzione seguente aperta, rendendo Basic come tolleranza di errore possibili di problemi hardware:
APRI "COM1:300, N, 8, 1, COLLOCAZIONE, CD0, CS0, DS0, OP0, RS, TB2048, RB2048" COME #1
(Questa operazione, aprire è di RAM). Di seguito è fornita una spiegazione di ogni parametro consigliato in questa istruzione consente di aprire:


  1. Maggiore velocità di trasmissione, aumenta le probabilità di problemi; è pertanto improbabile che offrono problemi 300 baud. 2400 baud è la velocità massima possibile su più linee telefoniche, a causa delle loro capacità ad alta frequenza limitata. 19.200 baud, che richiede una connessione di rete diretta, è probabile che potrebbe causare problemi. (Velocità di trasmissione possibile per QuickBasic sono 75, 110, 150, 300, 600, 1200, 1800, 2400, 4800, 9600 e 19.200.)
  2. Parità in genere non consentono in modo significativo. Per questo motivo, è non consigliabile tentare nessuna parità (N).


    Per le periferiche che richiedono la parità, utilizzare l'opzione PE (consentono di parità) nell'istruzione OPEN COM, è necessario attivare il controllo della parità. Quando l'opzione PE consente di attivare il controllo di parità, un "errore dei / o periferica" si verifica se i due programmi di comunicazione due proseguiranno diversi. (Parità pari, può essere dispari, nessuno spazio o segno). Ad esempio, un "errore di periferica i/o" si verifica quando due programmi tentano di parlare tra loro attraverso una linea seriale utilizzando le seguenti istruzioni COM aperta diverse due:
          OPEN "COM1:1200,O,7,2,PE" FOR RANDOM AS #1
    e
          OPEN "COM2:1200,E,7,2,PE" FOR RANDOM AS #2
    Se l'opzione PE viene rimosso dalle precedenti istruzioni COM aperta, viene visualizzato alcun messaggio di errore.
  3. Nell'esempio precedente utilizza 8 bit di dati e 1 bit di stop. Otto bit di dati non necessario (N), nessuna parità causa del limite di dimensione per i frame di dati comunicazioni Basic (10 bit).
  4. La collocazione (modalità binary) è il valore predefinito. Nota: L'opzione ASC non supporta il protocollo XON/XOFF e i caratteri XON e XOFF vengono passati senza gestione speciale.
  5. Ignorando la sincronizzazione hardware spesso corregge molti problemi. Pertanto, se l'applicazione non richiede la sincronizzazione, si dovrebbero provare a disattivare la seguente riga-verifiche hardware:
    CD0 = attiva off timeout per la riga Data Carrier rilevare (DCD)
    CS0 = attiva off timeout per la linea CTS Clear To Send ()
    DS0 = attiva off timeout per la linea DSR Data Set Ready ()
    OP0 = attiva off timeout per aprire un esito positivo
  6. RS disattiva il rilevamento di richiesta per inviare (RTS).
  7. Per problemi relativi al buffer, provare ad aumentare la trasmissione e la ricezione di buffer di dimensioni sopra il valore predefinito di 512 byte:
    TB2048 = aumenta le dimensioni di buffer di trasmissione ai 2048 byte
    RB2048 = aumenta le dimensioni del buffer di ricezione a 2048 byte
    Un buffer di ricezione maggiore consentono di risolvere base ritardi causati da istruzioni come PAINT, che utilizzano intensamente il processore.
Di seguito sono riportati ulteriori suggerimenti importanti per la risoluzione dei problemi di comunicazione:


  1. Utilizzare la funzione INPUT$(x) in combinazione con la funzione LOC(n) per ricevere tutti gli input da periferica di comunicazione (dove "x" è il numero di caratteri restituiti da LOC(n), ovvero il numero di caratteri nella coda di input in attesa di essere letti. "n" è il numero di file che è stato aperto per "COM1:" o "COM2:").


    Evitare l'utilizzo dell'istruzione INPUT #n l'input da porta di comunicazione poiché INPUT #n tempo di attesa per un carattere (ASCII 13) di ritorno a capo.


    Evitare di utilizzare l'istruzione GET #n per le comunicazioni GET #n attende per riempire il buffer (e sovraccarico del buffer può quindi verificarsi).


    Inoltre, evitare di utilizzare l'istruzione PUT #n per le comunicazioni e utilizzare invece l'istruzione #n di stampa. Ad esempio, nella sintassi di QuickBasic 4.0b e 4.5, in Basic 6.0 del compilatore e 6.0b in base PDS 7.0 e 7.1, utilizzando il PUT #n, $ x per l'invio di una variabile di stringa di lunghezza variabile come terzo argomento della #n il PUT istruzione invia un ulteriore 2 byte contenente la lunghezza della stringa prima della stringa effettiva. Questi byte di 2 lunghezza inviati alla porta di comunicazione possono confondere il programma di destinazione se non è stato progettato per gestirli. Nessun byte di lunghezza vengono inviato con PUT #n, x$ QuickBasic 4.0. (QuickBasic versioni precedenti alla 4.0 non offrono la funzionalità di utilizzare una variabile come terzo argomento dell'istruzione PUT #n.)
  2. Per un esempio di comunicazione dati, fare riferimento al terminale. Programma di esempio BAS fornito nella release dal disco per QuickBasic versioni 4.0, 4.0b e 4.5, per compilatore Microsoft Basic versioni 6.0 e 6.0b e per le versioni di Microsoft Basic Professional Development System (PDS) 7.0 e 7.1. Molti problemi di comunicazione potrebbero essere effettivamente il flusso di controllo e di progettazione del codice sorgente non appropriato.
  3. Molti problemi di comunicazione possono essere visualizzati solo in determinate configurazioni hardware e sono difficili da risolvere o duplicare su altri computer. Si consiglia di sperimentare una connessione diretta (con un cavo null-modem breve) invece che con un telefono/modem di collegamento tra mittente e ricevente per isolare i problemi in una determinata configurazione.
  4. Gli schemi di cablaggio per cavi variano ampiamente. Controllare il cablaggio di pin del cavo. Per le connessioni dirette via cavo, un cavo lungo o ad alta resistenza è più probabile dare problemi rispetto a un cavo breve, basso-resistenza.
  5. Se entrambi "COM1:" e "COM2:" sono aperti, "COM2:" prima di servire. Velocità di trasmissione elevata, "COM1:" può perdere caratteri la competizione del tempo del processore con "COM2:".
  6. Utilizzando l'istruzione GOSUB COM via anziché la funzione LOC(n) di polling per rilevare le comunicazioni input talvolta risolvere di intervallo o il buffer di problemi causati da ritardi in Basic. Ritardi in Basic possono essere causati dalla procedura di garbage collection di spazio di stringa, istruzioni di disegno o altre operazioni che utilizzano pesantemente il processore.
  7. Assicurarsi che le righe di handshake hardware appropriato (ad esempio CS, DS, CD, ecc.) vengono controllate da Basic. Sebbene la disattivazione di questi timeout (impostando il valore corrispondente nell'istruzione OPEN base a zero) è utile per determinare quali righe utilizzate dall'hardware, esso non deve essere considerato un metodo generico per stabilire comunicazioni seriali, poiché ignorando la sincronizzazione hardware può aumentare la possibilità di un problema di temporizzazione che potrebbe causare il blocco.
Utilizzo di programmi comunicazioni commerciali più sofisticate tecniche non trovate in Microsoft Basic e può fornire prestazioni migliori.


Se è necessario migliori prestazioni di comunicazioni che si desidera ottenere tramite Basic, si consiglia di provare Microsoft C. (è possibile chiamare le routine di Microsoft C da Microsoft QuickBasic 4.0, 4.0b e 4.5, da Microsoft base compilatore 6.0 e 6.0b e da Microsoft Basic Professional Development System (PDS) versioni 7.0 e 7.1). Di seguito è riportato un riferimento a un eccellente:
"C del programmatore di comunicazione seriale" da Joe Campbell, pubblicato da Howard W. Sams & società.
QuickBasic 3.0, 4.0, 4.0b e 4.5 implementare comunicazioni dirette interrupt per le righe di input IRQ3 e IRQ4 del chip 8259 controller (invece di richiamare ROM BIOS interrupt).


Il libro seguente fornisce una descrizione eccellente di tecnica, a livello di hardware di comunicazione seriale per PC IBM:
"Programmazione di linguaggio assembler 8088: PC IBM" seconda edizione da Willen & Krantz, pubblicato da Howard W. Sams & Co (1983, 1984). Pagine 92-93 e il capitolo 7 (166 pagine a 188).
Proprietà

ID articolo: 39342 - Ultima revisione: 30 gen 2017 - Revisione: 1

Feedback