API de Comunicaciones Serie Anterior | Siguiente Este API proporciona a los programadores la siguiente funcionalidad:

Una especificacin completa para control y acceso a los puertos serie y paralelo. Esto facilita mucho los desarrollos, ya ue disminuye en gran medida la carga de tra!a"o a reali#ar para el acceso a estos puertos. Control total de todos los par$metros de los puertos serie: %elocidad en !audios, !its de stop, paridad, !its por trama& as' como control manual o autom$tico de las l'neas de control de flu"o. (ormalmente, en )S*+,+, hay dos l'neas de se-al y el resto son l'neas de control& dependiendo del tipo de comunicacin, s'ncrona o as'ncrona, el n.mero de l'neas de control seleccionadas puede %ariar. El API proporciona acceso a las l'neas de control fundamentales. En este momento, es necesario hacer una pe ue-a descripcin para ayudar al lector a entender algo acerca de la paridad y los !its de arran ue y parada. /a paridad fue incorporada a )S*+,+ por ue las l'neas de comunicaciones pod'an ser ruidosas, es decir, si se manda!a el cdigo ASCII 0, ue en he1adecimal es 01,0 2o 00330000 en !inario4, a lo largo de su %ia"e pod'a encontrarse con acciones de campos magn5ticos, por e"emplo, ue hac'an ue alguno de sus !its cam!iasen de %alor. Para e%itarlo, en %e# de mandar 6 !its como ser'a normal, se incluye un !it m$s a la cadena de !its en%iada indicando si la suma total de !its en%iados es par o impar, y... Esa es la paridad. /os !its de arran ue 2start4 y parada 2stop4 fueron a-adidos al protocolo de comunicaciones serie para permitir a los receptores sincroni#arse con respecto a los caracteres ue est$n siendo en%iados. /a paridad, al usar un solo !it, no permite la correccin del error, solamente la deteccin. /as soluciones a este pro!lema %ienen de la mano de protocolos ue forman una capa por encima del API de comunicaciones serie, normalmente utili#ando protocolos de mensa"es con checksums ue permiten la deteccin de errores en grupos muy grandes de !its. Por e"emplo, cuando el lector se conecta son su pro%eedor de Internet so!re PPP, los pa uetes ue se intercam!ian son de 3+6 !ytes por pa uete con chec7sum, ue si coincide en los dos lados, hay una seguridad del 88,8889 de ue lo en%iado es lo reci!ido. :ay casos donde este es uema no funciona& por e"emplo, cuando se en%'an comandos cr'ticos a dispositi%os ue est$n muy, muy le"os 2m$s all$ del sistema solar4. En estos casos se utili#an los protocolos forward correcting, por ue no hay posi!ilidad de retransmisin de los pa uetes y, adem$s, el espacio est$ repleto de ruido electromagn5tico.

Siguiendo con las funcionalidades del API de Comunicaciones ;a%a. Este API utili#a para entrada y salida los streams, un concepto ue de!er'a ser ya familiar al lector. Es importante reutili#ar los conceptos de ;a%a cuando se implementan nue%as funcionalidades o se corre el peligro de ue los APIs resulten posteriormente muy complicados en su mane"o. /os streams pueden e1tenderse para proporcionar control sobre el flujo y los umbrales. Por e"emplo, puede ser necesario lan#ar un a%iso cuando haya 3< caracteres en el !uffer, o cuando solamente ueden 3< espacios %ac'os para almacenar caracteres. El control del flu"o es importante cuando dos dispositi%os conectados a tra%5s de un interfa# no pueden mantenerse uno al otro& sin el control del flu"o, pueden darse condiciones alteradas, tanto por e1ceso como por defecto. En condiciones en ue haya pro!lemas por e1ceso de informacin, se reci!ir$n datos mientras toda%'a se est$n procesando otros, con lo cual ha!r$ p5rdidas de informacin& y en el caso contrario, la

informacin estar$ presente pero no disponi!le. (ormalmente estas condiciones solamente se dan a ni%el hard=are, a ni%el de la USA)> 2Universal Synchronous Asynchronous Receiver Transmitter4, ue es el dispositi%o f'sico ue con%ierte los !ytes a una se-al ondulada coincidiendo con la %elocidad en !audios. El API de Comunicaciones ;a%a utili#a el modelo de e%entos ue ;a%aSoft ha introducido desde el lan#amiento del ;?@ 3.3 para proporcionar informacin de las l'neas de se-al ue %an cam!iando y del estado del !uffer. /os cam!ios de estado se refieren solamente a las se-ales ue est$n !ien definidas en el est$ndar )S*+,+& por e"emplo, la se-al de deteccin de portadora 2Carrier etect4 es utili#ada por los mdems para indicar ue se ha esta!lecido la cone1in con otro mdem, o para indicar ue ha detectado un tono de llamada. /uego el hacer una cone1in o detectar una llamada ser$ un e%ento. /a deteccin de e%entos y la notificacin de cam!ios est$ totalmente implementada en el API. A ahora, es con%eniente tam!i5n, la re%isin de algunas de las cosas ue el API de Comunicaciones ;a%a no hace, para ue el lector tenga idea de lo ue puede o no conseguir con su uso. Este API no proporciona ninguna de la siguiente funcionalidad.

Procesado de las se-ales, control de llamadas o control del mdem. El procesado de se-ales se refiere a procesado adicional de caracteres de entrada o salida& por e"emplo, una opcin muy com.n de post*procesado es la con%ersin de los caracteres de retorno de carro a retorno de carro m$s salto de l'nea, cuyo origen se remonta a los antiguos teletipos, ya ue ahora con las pantallas gr$ficas y las impresoras l$ser, esto tiene menos importancia. El control de llamadas y del mdem se puede reali#ar con aplicaciones adicionales ue tam!i5n se pueden desarrollar con el API de Comunicaciones ;a%a. El control de llamadas, normalmente, es lo ue proporciona un interfa# para los comandos AT de los mdem. Este interfa# suele %enir documentado en los manuales del mdem. Un e"emplo facilitar$ la comprensin de este concepto al lector. Se parte de ue se tiene un mdem conectado al puerto CBC3 y ue se uiere marcar un n.mero de tel5fono. /a aplicacin ;a%a del control de llamadas preguntar$ el n.mero de tel5fono ue se uiere marcar e interrogar$ al mdem& estos comandos son mane"ados por el API, ue no reali#a ninguna interpretacin de ellos. Es decir, para marcar el numero D063+,E<D, el controlador de llamadas en%iar$ un AT y se uedar$ esperando OK, cuando lo reci!a en%iar$ ATDT608123456. Uno de los cometidos principales de estas aplicaciones de control es el tratar los errores y timeouts ue se puedan producir durante la comunicacin.

Un interfa# gr$fico para el control de los puertos serie. (ormalmente, el lector ha!r$ o!ser%ado ue los puertos serie disponen de una %entana de di$logo ue permite su configuracin, pudiendo especificar la %elocidad, paridad, etc. El diagrama ue muestra la figura siguiente descri!e los o!"etos in%olucrados en la lectura o escritura de datos en un puerto serie desde ;a%a.

Soporte para protocolos de mdem, del tipo F, A o G. Estos protocolos proporcionan soporte para la deteccin y correccin de errores.

Principios H$sicos Con demasiada frecuencia, los programadores se in%olucran en un proyecto y codifican interacti%amente con un API a tra%5s del editor sin ha!er refle1ionado suficientemente so!re el pro!lema ue intentan resol%er. Para e%itar confusiones y potenciales pro!lemas, el programador de!er'a recoger la informacin, cuando se trate de comunicacin con dispositi%os serie e1ternos, ue se indica seguidamente antes de iniciar ese proyecto. )ecuerde tam!i5n el lector, ue todos los dispositi%os re uieren en alg.n momento ue se de!a consultar su manual, ue para eso el fa!ricante lo ha escrito& no es suficiente con la intuicin. 3. Coger el manual del dispositi%o y leer la seccin so!re el interfa# )S*+,+ y su protocolo. Cuchos dispositi%os tienen un protocolo ue de!e seguirse, para poder esta!lecer comunicacin entendi!le con 5l. El dispositi%o decodificar$ los datos ue sigan ese protocolo, as' ue hay ue poner atencin en el en%'o y recepcin de datos. Con una iniciali#acin correcta no se asegura ue la comunicacin tam!i5n lo sea, por ello hay ue tomarse el tiempo necesario en hacer las prue!as ue sea menester, incluso haciendo una aplicacin de lo m$s simple, ue escri!a y lea datos a tra%5s del puerto serie usando el API de Comunicaciones ;a%a. +. Consultar los e"emplos ue proporcione el fa!ricante& incluso aun ue se encuentren en otro lengua"e de programacin, siempre resultan .tiles. ,. Huscar o codificar el e"emplo m$s simple posi!le para %erificar la comunicacin con el dispositi%o. En el caso de dispositi%os serie, esto puede resultar altamente frustante cuando se en%'a algo al dispositi%o conectado al puerto serie y no sucede nada. Este es el resultado ue se o!tiene cuando las condiciones de la l'nea son incorrectas. /a regla numero Uno de la programacin con dispositi%os 2a no ser ue se est5 escri!iendo un dri%er4 es asegurarse de ue se puede esta!lecer comunicacin con el dispositi%o. E. Si el protocolo es muy complicado, hay ue considerar el uso de alg.n tipo de soft=are ue analice

la l'nea )S*+,+, el cual permite compro!ar los datos ue se intercam!ian los dos dispositi%os sin interferir en la transmisin. El uso del API de Comunicaciones ;a%a con 51ito en una aplicacin re uiere proporcionar alg.n tipo de interfa# para el control del dispositi%o utili#ando el API como mecanismo de transmisin. En otras pala!ras, con e1cepcin de los dispositi%os m$s simples, se necesita una capa por encima para formatear los datos de forma ue sean entendi!les por el dispositi%o. ?esde luego, el protocolo m$s simple es ninguno, es decir, la no e1istencia de protocolo, en donde los datos se en%'an y reci!en sin ning.n tipo de interpretacin. http:IItoro.itapi#aco.edu.m1IpaginasI;a%a>utIfroufeIparte38Icap38*+.html