Newsgroup: it.comp.lang.c
Titolo: routine per seriale?

mi servirebbe una routine (se esiste) nella libreria standard del cd
per leggere dati dalla porta seriale e dalla porta parallela.
Dovrei leggere l'intera "parola" uscente dalla seriale dopo un tot di tempo
in un loop principale.
Se non ci fosse in C va bene anche un suggerimento in assembler, anche se
so che non è il NG giusto.
Magari un INT del dos (il numero). Un grazie esteso.
Andrea.

Per quanto riguarda l'assembler, l'INT che ti serve e' il 14h
(funzione 00h per configurare la porta, 01h per inviare, 02h per ricevere e
03h per leggerne lo stato, se nn sbaglio)
Se invece sei sotto UNIX puoi usare una semplice open() sul file associato
al device corrispondente...
Ciao!
"Andrea Richiardi" <ari...@NOSPAMinwind.it> ha scritto nel messaggio
news:r9uAa.34705$Ny5.1...@twister2.libero.it...


"Andrea Richiardi" <ari...@NOSPAMinwind.it> ha scritto nel messaggio
news:r9uAa.34705$Ny5.1...@twister2.libero.it...

Trovi un tutorial su 
www.programmando.org
 per la programmazione diretta
della seriale in assembler, ma i principi sono facilmente applicabili in C.
Se, invece, tu volessi utilizzare una funzione bios allora l'interrupt che
ti serve e' il 14h. Dato che c'e' molto da dire su questa funzione bios
contattami in mail privata se vuoi piu' chiarimenti.
Ciao,
Maurizio

> > per leggere dati dalla porta seriale e dalla porta parallela.
Ti scrivo due righe di codice di esempio per accedere direttamente alle
porte, in questo esempio scrivi due byte sulla porta parallela.
Fai attenzione però, la possibilità di accedere direttamente dipende dal
sistema operativo; sotto Linux (l'esempio che ti scrivo è proprio per Linux)
è necessario chiamare la funzione ioperm().
Sotto Dos/Windows 9x non è necessario nessun permesso (Brrr!), basta
chiamare _inp() e _outp(), invece sotto Windows NT/2K non è assolutamente
possibile accedere direttamente, devi scrivere un driver che giri in
anello0.
Ciao,
Paolo
#include <unistd.h>
#include <asm/io.h>
#define ADDRESS 0x378
main()
{
  ioperm(ADDRESS,3,1);
  outb(0,ADDRESS);
  outb(255,ADDRESS);
  ioperm(ADDRESS,3,0);
  return;
}

Scarica dalla rete
"Serial Programming Guide for Posix Operating Systems"
di Michael R. Sweet.
Risolevari tutto con chiamate di sistema,
a partire dalla open che ti hanno gia' suggerito.

 Magari un INT del dos (il numero). Un grazie esteso.
Volevo ancora puntualizzare che nei sistemi operativi successivi al DOS,
tra cui anche windows 98-NT-2000-XP-quelli che verranno
e Linux, l'accesso ai device e' gestito dal sistema operativo che
mette a disposizione dei programmi utente le chiamate
di sistema (API per windows, syscalls per linux) che virtualizzano
l'accesso ad device attraverso i driver forniti dai produttori.
Quindi tu scriverai un unico codice per accedere ad una seriale
"normale", o ad una seriale USB.
Questo vale sia per windows che per linux.
I retaggi dell'accedere direttamente alle porte di I/O tramite
assembler sono,per l'appunto, retaggi del passato quando
la diffusione del DOS, sistema fragile e immaturo, ha
allevato una e piu' generazioni di programmatori a queste
tecniche piu' o meno arrangiate per accedere all'hardware.
Erano ancora i tempi in cui i videogiochi incorporavano i driver
per accedere in modo efficiente alle diverse marche di schede video.

 assembler sono,per l'appunto, retaggi del passato [...]
Questo concetto è sostanzialmente corretto ma non mi trova "idealmente"
d'accordo.
D'altronde la possibilità, e non l'obbligo, di poter accedere in C a risorse
tramite chiamate di sistema equivale a realizzare la stessa cosa in un
linguaggio di livello più alto, un po' come si farebbe con un Basic. Ha il
vantaggio di funzionare sempre ma nel modo predeterminato.
La cosa che mi ha sempre affascinato del linguaggio C è la sua doppia
natura, un linguaggio che non è ne' di alto ne' di basso livello, ovvero è
entrambe le cose.
Ben venga, quindi, l'astrazione ma sempre con la possibilità di tirare
direttamente i fili del meccanismo.
Mi sembra poi il fascino della filosofia Linux, hai tutto pronto ma se vuoi
puoi fare da te.
Ciao,
Paolo.

 d'accordo.
Certo per un "esploratore", inteso anche
come "persona capace", il poter fare
e' meglio del "non poter fare".
Nel mio caso (supervisione di impianti industriali)
e' piu' importante che i 100 pc che do' fuori ogni anno,
si comportino tutti allo stesso modo,
sarebbe una pazzia
(se devi lavorare e quindi vendere e quindi garantire un comportamento)
dover lottare contro ogni nuovo hardware.
Nel caso in esame, ora che e' sempre + difficile trovare pc con due porte
seriale vere, (non parliamo dei portatili)
il fatto che una seriale USB abbia la stessa interfaccia di tutte le
altre seriali, non mi ha rovinato l'esistenza :-)

 ha scritto nel messaggio
news:e092bb...@www.tin.it...


 devo utilizzare l'ambiente posix che hai scritto?
il libretto parla di sistemi operativi (della famiglia Unix)
che aderiscono allo standard Posix.
Linux certamente, per gli altri *nix ti rimando a chi ne sa piu' di me.
Per windows puoi aprire il file di help di windows sdk
del tuo compilatore preferito ,
cercare "BuildCommDCB" che e' l'analogo di tcsetattr,
premere il tastino "group" per farti un'idea delle funzioni della famiglia
della seriale, o premere il tastino "Overview"
per una trattazione piu' esaustiva.

"una comunicazione seriale secondo lo standard RS485"
questo è quello che mi è stato detto.
Di che standard si tratta?
Va bene con l'UART?
"Andrea Richiardi" <ari...@NOSPAMinwind.it> ha scritto nel messaggio
news:r9uAa.34705$Ny5.1...@twister2.libero.it...


 Va bene con l'UART?
[OT]
Sì, RS-485 è uno standard solo a livello elettrico/fisico, il controllo 
è di solito tramite un UART di tipo del tutto standard.
Devi solo tenere conto di un particolare importante, che RS-485 è 
"multidrop", permette quindi l'invio di dati fra più dispositivi, dove 
ciascuno di questi comunica in modo esclusivo sulla linea (half-duplex).
In parole povere: la linea di comunicazione è unica, se qualcuno invia 
dati gli altri non possono fare altro che ricevere (o ignorare) i dati.
Di solito questo meccanismo si attiva in automatico (deve essere 
previsto dalla scheda/adattatore RS-485 che usi) oppure sotto controllo 
della linea RTS -- attivi lo RTS, invii i tuoi dati, disattivi 
(immediatamente!) lo RTS: chi è collegato sulla linea e vuole rispondere 
può farlo solo adesso.
Nota: lo stesso vale sempre anche per te, se qualcuno sta trasmettendo, 
non puoi trasmettere a tua volta finché non ha terminato -- altrimenti 
c'è un conflitto sui dati, che si "mischiano" con risultato imprevedibile.
Come riferimento generico (e assai completo):
 
http://www.lvr.com/serport.htm
Lou