Newsgroup: it.comp.programmare
Titolo: programmare la porta seriale

Qual'è la differenza pratica fra trasmissione sincrona e asincrona?
Nella sincrona i bit buoni per il ricevitore sono quelli dopo il 
carattere o i caratteri di sincronismo, mentre per la trasmissione 
asincrona i bit si prendono dal primo bit dopo i bit di stop. Giusto? 
Altre differenze?
Non ho capito poi come si gestisce la comunicazione tra due computer con 
la seriale, usando gli interrupt. Come faccio a sapere che posso 
inserire un altro dato in DATAOUT senza provocare un overrun nel 
ricevente (perchè ancora non ha letto il byte da DATAIN)?
Grazie

 ricevente (perchè ancora non ha letto il byte da DATAIN)?
Ma devi proprio usare gli interrupt? In genere ci si appoggia a chiamate 
del sistema, dove tu non ti devi occupare troppo dei dettagli: non è
necessario preoccuparsi di sapere se puoi o non puoi mandare un carattere
alla seriale, in genere la comunicazione è bufferizzata e ci pensa l'OS
a gestire la comunicazione; a te resta solo da gestire adeguatamente il
risultato di una read o una write.
Ciao
  Andrea

 ricevente (perchè ancora non ha letto il byte da DATAIN)?
Non lo sai e non ti interessa saperlo.
C'e' un protocollo da rispettare.
Il remoto si presume segua il protocollo.
Tu mandi i dati alla velocita' prevista e l'altro li riceve.
Ma perche' inventarsi l'acqua calda nel 2007?

Roberto Montaruli ha scritto:

Per studio?
Sto scrivendo per un esercitazione all'uni una parte di un sistema 
operativo (in assembler) per motorola m68000, in un ambiente di 
simulazione chiamato ASIM (dell'università di Napoli).
Il problema nasceva per il driver della usart (che ho scritto). Ho 
risolto poi perchè ho capito che il problema era la velocità della 
seriale cheera troppo alta, quindi il processore non faceva a tempo a 
leggere il byte in DATAIN. Banale si, ma in un primo momento credevo di 
dover implementare un handshake per ogni byte inviato :-).
Ciao

 dover implementare un handshake per ogni byte inviato :-).
No, l'handshake e' gia' qualcosa di relativo al protocollo: non dovrebbe 
avere a che fare col driver.
In teoria una trasmissione seriale potrebbe essere tutta quanta 
monodirezionale, senza ack, senza handshake, senza niente.
Poco raccomandabile dal punto di vista pratico, ma funzionante dal punto 
di vista teorico.

 asincrona i bit si prendono dal primo bit dopo i bit di stop. Giusto? 
No. Nella trasmissione sincrona ci sono altre linee per il controllo 
del flusso (dts-rts) nell'asincrona no. Il bit di inizio si chiama 
bit di start.
-- 
IBM: Illustrious Bankruptcy Malenfactor
News 2002 [v 2.07] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 
Non credo. DTR, DSR, CTS e RTS ci sono in entrambi i casi. E' vero il 
fatto del bit di start (che sarebbe lo 0).
Ciao

 di vista teorico.
L'handshake c'è all'inizio con i segnali DTR, DSR, CTS e RTS. Da quello 
che ho capito non sono indispensabili, ma si utilizzano per   verificare 
che dall'altra parte ci sia qualcun'altro.

 fatto del bit di start (che sarebbe lo 0).
Credi male.
La trasmissione seriale asincrona non ha bisogno delle linee di 
controllo... Altrimenti sarebbe sincrona...
-- 
Never test for an error condition you don't know how to handle.  - Steinbach


 
Ti sbagli tu. Sai di cosa stiamo parlando, sai programmare la usart?

 Ti sbagli tu. Sai di cosa stiamo parlando, sai programmare la usart?
lol.
Stiamo parlando di una BANALE rs323. Ora gradirei che tu spiegassi 
all'ilare pubblico come programmeresti le linee CTS, DTR, etc... su 
un collegamento a tre fili: RX - TX - GND
-- 
IBM: I've Been Mangled


 asincrona? 
AFAIK nella trasmissione seriale sincrona (SPI, I2C) viene trasmesso 
anche il segnale di clock. In quelle asincrone (RS232, RS485, CAN) la 
lunghezza del bit è nota a priori e i ricevitori hanno un loro clock 
usato per campionare il dato in ingresso.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 
Si vede che parliamo di cose diverse. L'usart con cui ho a che fare io, 
ha anche CTS, DTR, TSR, RTS.
Il pubblico forse sta ridendo di te, che sei così convinto.

 Il pubblico forse sta ridendo di te, che sei così convinto.
Allora: sei partito male fin dall'inizio con la funzione 
sincrona/asincrona da te erroneamente attribuita alla presenza o meno
di bit di start e stop mentre, come ha spiegato meglio un altra 
persona nel thread, la sincronia si ottiene unicamente con la 
presenza di un (o più) segnale di clock aggiuntivo alla linea di 
ricezione e trasmissione. In un PC la trasmissione seriale è sempre 
asincrona tant'è vero che è necessario impostare PREVENTIVAMENTE 
sulle apparecchiature la velocità di scambio dei dati (baud rate) dal
momento che non essendoci alcuna *sincronizzazione* dei segnali 
sarebbe impossibile colloquiare qualsiasi cosa. La lettura dei bit in
ricezione avviene in virtù del segnale di clock interno a ciascun 
dispositivo ed in presenza di un clock interno sballato (magari 
perchè si è impostato un baud rate diverso tra i dispositivi) la 
comunicazione non può avvenire, neppure infilando nel segnale miriadi
di bit di controllo. I segnali che abbiamo citato realizzano una 
sorta di sincronizzazione artificiosa (non è un reale segnale di 
clock) permettendo alla trasmissione ASINCRONA (che tale poi in 
realtà rimane) di interrompersi/riprendersi a fronte di una richiesta
specifica su tali linee. Linee che possono tranquillamente essere 
ignorate se i due dispositivi non hanno problemi a trattare il 
segnale seriale (ovvero se non rischiano di perdersi i bit per strada
a causa di ritardi INTERNI nella gestione dei dati stessi).
-- 
How do I set my laser printer on stun?
News 2000 [v 2.06] - 
http://www.akapulce.net/socket2000

Due di Picche <mega...@TOGLISPAMaruba.it> wrote in
news:epsc53$iur$
1...@tdi.cu.mi.it
: 

Solo due note veloci (non prendetevela a male).
1. Mi sembra che ci sia una notevole confusione di termini nel 
vostro scambio di opinioni.
Per seriale sincrona si intende (come giustamente riporti) un 
collegamento dove viene trasmesso anche il clock (non conosco 
protocolli con più clock diversi).
I segnali di controllo servono a diversi scopi. 
Capire che il device dall'altra parte della comunicazione è "vivo", 
capire che il cavo è collegato, e gestire il controllo di flusso 
(quella che tu chiami "sincronizzazione artificiosa").
La comunicazione seriale asincrona RS232 può considerare tutti quei 
segnali (evitando di trasmettere quando dall'altra parte non c'è 
nessuno, riconoscendo la connessione del cavo e al remoto, 
segnalando che non si è momentaneamente in grado di ricevere dati ed  
è meglio interrompere la trasmissione per evitare un overrun in 
ricezione).
2. In realtà la configurazione a priori del baud rate è una 
questione di "comodità" più che un requisito indispensabile.
Ci sono protocolli di comunicazione che prevedono una fase iniziale 
di sincronizzazione del baud rate in cui il trasmettitore sceglie il 
baud rate e trasmette una sequenza fissa e il ricevitore varia il 
suo baud rate fino a che non riesce a ricevere correttamente quella 
sequenza. Altri protocolli hanno la possibilità di cambiare 
dinamicamente il baud rate dopo aver stabilito la connessione con un 
baudrate fisso (di solito molto basso).


 baudrate fisso (di solito molto basso).
Ma non è uno standard, è un PROTOCOLLO che dovrebbe essere 
implementato SIA nel ricevitore SIA nel trasmettitore. Ed in ogni 
caso sarebbe una sorta di handshake. In una trasmissione sincrona 
invece è il clock che determina la cadenza di trasmissione ed è un 
segnale HARDWARE. Da qui il nome di sincrono: "che si muove, agisce, 
funziona in maniera coordinata col muoversi, l’agire o il funzionare 
di un altro elemento".
-- 
When we write programs that "learn", it turns out we do and they don't.


 funzionare di un altro elemento".
E io cosa ho detto all'inizio del thread?
Sottolineavo anche che quella che tu chiamavi "sincronizzazione 
artificiosa" si chiama "controllo di flusso" e può essere utilizzato a 
prescindere dal fatto che la comunicazione sia sincrona o asincrona 
(pui avere un segnale di busy anche via SPI perchè è solo uno dei due 
device che normalmente controlla il clock).


 device che normalmente controlla il clock).
Beh, cosa che avevo però puntualizzato nel messaggio stesso:
"I segnali che abbiamo citato realizzano una sorta di 
sincronizzazione artificiosa (non è un reale segnale di 
clock) permettendo alla trasmissione ASINCRONA (che tale poi in 
realtà rimane) di interrompersi/riprendersi a fronte di una richiesta
specifica su tali linee."
-- 
Remember the good old days, when CPU was singular?


 richiesta specifica su tali linee."
Non dicevo che esprimevi un concetto sbagliato. Dicevo che lo chiamavi 
"sincronizzazione artificiosa" invece che usare "controllo di flusso" 
che è il nome comunemente usato. Visto che la discussione verteva sul 
diverso significato che attribuivate a seriale sincrona/asincrona 
aggiungere un altro termine impreciso avrebbe peggiorato la situazione 
:)


Due di Picche ha scritto:

Allora, cercherò di definire cosa intendo, perché così mi hanno 
spiegato, per comunicazione sincrona e asincrona.
Trasmissione asincrona:
trasmettitore: una volta abilitato il trasmettitore, attivato i segnali 
DTR e RTS e ricevuto i segnali DSR e CTS, il trasmettitore comincia ad 
inviare sempre 1, fino a quando il processore non inserisce un dato da 
trasmettere in DATAOUT. A questo punto il trasmettitore trasmette il bit 
di stop (uno zero), poi i bit di dati, poi il bit di parità, poi uno o 
due bit di stop. Se a questo punto il processore ha inserito un altro 
dato in DATAOUT ricomincia a trasmettere (inviando prima un bit di start 
0) come prima.
Trasmissione sincrona.
trasmettitore: una volta abilitato il trasmettitore, attivato i segnali 
DTR e RTS e ricevuto i segnali DSR e CTS, il trasmettitore comincia ad 
inviare i caratteri di sincronismo (uno o due, a seconda 
dell'impostazione data), poi, comincia ad inviare il dato che il 
processore ha inserito in DATAOUT (se non l'ho inserito si verifica un 
underrun). Alla fine della trasmissione del dato, invia eventualmente il 
bit di parità, e poi invia subito l'altro dato (se è disponibile, 
altrimenti underrun).
I ricevitori non scrivo cosa fanno, tanto è banale.
Capito adesso cosa intendo io per trasmissione sincrona e asincrona?

 
Come viene trasmesso pure il clock? Ma se le linee sono due (a parte le 
altre 4, DST, DTR, RTS e CTS), cioè Rx e Tx, come fai a trasmettere il 
clock?

 Capito adesso cosa intendo io per trasmissione sincrona e asincrona?
Si, ma non è corretto.
-- 
System going down at 5 pm to install scheduler bug.


 clock?
Appunto.
-- 
My computer's sick.  I think my modem is a carrier.


 
E come mai non è corretto?
Ti dico solo che quella è la terminologia usata dal mio professore di 
calcolatori elettronici II.

 
Quindi vuol dire che la trasmissione non può essere chiamata sincrona in 
nessun caso?

 nessun caso?
Stante il significato di sincrono č cosě, anche perchč non puň essere
un semplice bit nello stesso flusso di dati a poter diversificare una
trasmissione sincrona da una asincrona.
-- 
User: A harmless drudge.


 trasmettere il clock?
Infatti le seriali RS232 sono sempre e comunque asincrone.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non č valido)

 di calcolatori elettronici II.
Beh, se si va per titoli, io ho a malapena la licenza media e quindi mi 
arrendo.
Però IMVHO il secondo meccanismo descritto usa un controllo di flusso 
(e infatti si parla di underrun) ma non è sincrono o, perlomeno, non lo 
è a livello hardware.
Se lo scopo del tuo prof. era simulare una trasmissione sincrona su un 
PC (che ha solo seriali asincrone), può essere una soluzione di  
compromesso.
Le seriali sincrone in termini di hardware sono quelle (SSP, SPI, I2C 
etc.) dove viene trasmesso anche il clock. Il master, non generando il 
clock, ferma la trasmissione. Ci possono poi essere, in alcuni casi, 
(I2C, ad esempio) anche configurazioni multimaster.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)