Year: 2006

I2C – Inter Integrated Circuit bus

Reading time: 3 – 5 minutes

Tornant al tema dels busos que poden treballar sobre GPIO aquí teniu un altre bus molt i molt usat en aquest tipus de ports.

Definició

El I2C (“eye-squared-see”) el va inventar Philips cap als anys 80 amb la finalitat de connectar diferents IC (circutis integrats) amb les seves CPUs dintre d’una TV. Bàsicament és un bus pensat per curtes distàncies i poc ampla de banda.

A més I2C és capaç de detectar col·lisions, sincronitzar el rellotge i negociar el master en sistemes on n’hi pugui haver més d’un. El rellotge sempre el genera el master, però els slaves poden mantenir el rellotge parat per generar un estat d’espera.
Sovint el master en un bus I2C és el microcontrolador.

El número màxim de dispositius que es pot connectar en un bus I2C és calcula a partir de la màxima capacitància de la linia (uns 400pF), i el límit d’adreces és de 16k; normalment cada dipositiu té una capacitància d’uns 10pF. Així doncs diposem de 127 adreces disponibles. En principi les adreces de cada IC és assignable pel dissenyador del sistema.

Com funciona

Només es necessiten dos cables per treballar amb I2C, dos cables actius i el terra. Els cables actius són el SDA (Serial Data Line) i el SCL (Serial Clock Line). O sigui, el primer per dades i el segon pel rellotge.

i2c.gif

Només amb aquests dos cables actius en tenim prou per establir comunicacions full-duplex. L’interficie sovint funciona a velocitats baixes, de 100KHz a 400KHz. En un bus I2C, cada IC connectat al bus té una adreça única. Cada dispositiu pot treballar com a receptor i/o transmisor depenent de la seva funcionalitat.

Sobre el tema de l’amplada de banda, escencialment hi ha tres modes de funcionament un estàndard de fins a 100kbps i un de ràpid de fins a 400kpbs. El darrer mode és el High-Speed que pot arribar fins a 3.4Mbps.

Usos

Un dispositiu molt comú que sovint s’usa a través d’un bus I2C són les EEPROMs, també n’hi ha d’altres com els sensors, i els rellotges de temps real. A vegades també s’usen busos I2C només com a línia de senyalització per altres línies de dades, per exemple, en aplicacions multimèdia, on sovint s’usen sintonitzadors RF, codificadors i/o decodificadors de video, processadors d’audio. De fet, el mercat és ple de centenars d’IC que usen el bus I2C com a protocol de comunicacions en els seus busos.

Exemples d’us

Maxim té dintre del seu repositori d’articles tècnics un munt de referències a aplicacions sobre aquest protocol. He trobat molt interessant concretament una aplicació que ens permet controlar una pantalla LCD amb interficie HD44780 (local). Al document s’explica com serialitzar els 11 pins que necessita aquest dispositu per treballar només amb els 2 cables que té el bus I2C.

Un altre ús, jo diria que més que útil, és el que ens permet connectar el bus I2C al port paral·lel del PC. De fet, el circuit que ens ho permet fer és força simple si en voleu més informació: I2C interfacing via PC parallel port.

Fonts

SPI – Serial Peripheral Interface

Reading time: 3 – 4 minutes

Quan parlava de GPIO vaig parlar d’aquest protocol capaç de corre sobre ports d’aquest tipus. Doncs bé aquí en teniu una petita definició del que fa i com funciona aquest protocol.Un lloc on podem trobar sovint busos SPI són PDAs i en telèfons mòbils.

Definició

El bus SPI és del tipus serie i sincron, usa 4 cables i s’usa en molts microprocessadors de periferics. Els ports amb suport SPI suporten un ample de banda mitja/baix (1 megabaud) entre les seves CPUs i els altres dispositius que hi poden haver connectats al bus.

Com funciona

El bus SPI és relativament simple d’implementar per dispositius externs de poca velocitat i no ens calen gaire cables per establir la comunicació. L’interface d’aquest bus la va definir Motorola a l’estàndard de microcontroladors MC68HCxx. Usa un rellotge per marcar el sincronisme de la línia de dades tan d’entrada com de sortida del microcontrolador i la informació es mou en blocs de 8 bits.

El bus SPI usa una inteficie master/slave, com és normal en comunicacions serie síncrones és el master el que marca el rellotge. Un fet interessant en aquest tipus de busos és que podem rebre i enviar informació dels dispositius de forma simultanea, per tant es tracta d’un protocol full-duplex.

Una mica més endintre

Les senyals que usa el bus són:

  • SLCK serial clock, sempre controlada pel master
  • MISO master-in slave-out data
  • MOSI master-out slave-in data
spi.gif

En una aplicació normal haurem de connectar la soritda de SCLK del microcontrolador a la entrada SLCK del convertidor. La MISO al pin DOUT del convertidor, la MOSI al pin DIN. Cada IC (circuit integrat) del bus SPI té una senyal CS (chip-select), cal activar la senyal per tal d’habilitar el dispositiu en el bus. Per tal de fer això podem usar qualsevol de les línies de sortida estàndard del microcontrolador. Cal però que pensem que si tenim n ICs connectats al bus, caldràn n senyals per activar els ICs. A més si compartime la senyal de rellotge i les línies de dades haurem d’habilitar la senyal de CS corresponent en cada cas.

Valoració

Com podeu veure el disseny del bus i el prtocol d’ús són molt senzills. Tan que si fem servir massa dispositius connectats a la mateixa línia de dades la cosa es fa una mica pesada de tractar. Malgrat això per moltíssimes aplicacions és una bona idea usar-lo.

Exemple d’ús

La gent de maxim tenen un document tècnic (local) molt bo on en poques ralles ens explique com comunicar un termometre digital, concretament el DS1620, només amb 3 cables a través d’un bus SPI. L’esquema del sistema és força senzill i us dona una idea de la simplicitat que suposa connectar aquest sensor de temperatura al bus SPI.

Fonts

GPIO – General Porpuse Input/Output

Reading time: 2 – 2 minutes

Aquest acrònim s’acostuma a usar en dispostius incrustats, els dispositius GPIO ens facilitat ports d’entrada i sortida (I/O) que es poden configurar indiferenment com a ports d’entrada o de sortida. Sobre aquests ports podem fer correr protocols de BUS, com per exemple I²C, SPI and SMBus. Sovint el fet d’usar xips GPIO és una solució més econòmica que l’ús de micro-controladors.

Com que aquesta explicació queda molt generècia, el millor és parlar d’un exemple ben senzill de perquè serveix un GPIO en un dispositu embedded. El Linksys WRT54G per exemple, té un GPIO que no usa tots els seus PINs. Per tant, és un dispositiu que tots tenim a l’abast i amb el que a través d’un linux podem començar a jugar amb el GPIO. A comesfa.org hi ha un artícle titulat: Connexió d’un relé a un Linksys WRT54G on s’usa aquest GPIO del que us parlava per connectar-hi un relé a través del qual podem encendre i apagar dispositus.

gpio.jpg

Un petit trick que sovint podem fer amb els pins del GPIO és connectar-hi directament un LED, sovint si configurem el pin com a sortida i connectem l’altre pota del LED la posem a massa n’hi ha prou per fer encendre i apagar el LED quan volguem. De totes formes si no voleu sucarrimar el LED, us recomano mirar amb el tester quina tensió dona el pin en estat activat, ja que mai se sap què hi pot haver. Si mireu l’article anterior que us he dit de comesfa, veureu un tros de codi en C que mostra fins a quin punt serà de senzill controlar que el LED s’ensengui o s’apagui.

winmail.dat en linux

Reading time: 1 – 2 minutes

Més d’un cop he rebut un adjunt als correus que provenen d’usuaris d’Outlook, aquest adjunt del que ús parlo és el winmail.dat. Sovint els he fet re-enviar l’adjunt perquè això és un format que no podia obrir des del meu client de correu (MUA). Avui m’ha tornat ha passat però tenia molt d’interés en saber què hi havia dins d’aquell fitxer (winmail.dat) així que he trobat una eina per linux, el tnef, que em permet desempaquetar aquest format MIME (Multipurpose Internet Mail Extensions) propietat de Microsoft, concretament el format és el ms-tnef (Transport Neutral Encapsulation Format). Perquè ens fem una idea i fent un símil amb el món linux/unix vindria a ser un tar amb algunes funcions més sobretot orientades a incorporar informació RTF (Rich Text Format).

XML-RPC ping – NP_PingPong

Reading time: < 1 minute

technorati.gif

Ja fa uns mesos que em fallaven els pings cap a technorati per tant, els articles que escribia no s’estaben indexant a aquest buscador de tags. Així que gràcies al propi technorati he trobat un plugin pel blogcms que em permet fer-ho de forma més neta que fins ara. Fins ara ho feia amb un programa amb PHP que havia jo mateix, una mica cutre per dir-ho clar. Així que ara uso aquest plugin que es diu NP_PingPong que ho fa de forma integrada en l’entorn del blogcms.

Feedyes – obtenim feeds RSS de sites que no tenen feeds

Reading time: 1 – 2 minutes

feedyes.gif

Sempre m’he volgut sindicar a mini-itx però no disposa d’enllaç a un fitxer XML amb els feeds en format RSS ni ATOM. Així que el meu bloglines sempre ha estat esperant que això passes, de fet, la cosa no ha canviat. Però per fi he trobat un servei web que genera feeds automàticament d’altres sites que no ho tenen i a més gratuït, estic parlant de Feedyes en un 1s m’he donat d’alta i he generat els feeds de la web mini-itx. Així que si algú més s’hi vol sindicar ja ho sap. El sistema és força intuitiu tot i que us recomano que lliu el que diuen els passos per crear un feed sinó potser us passeu 1min com jo pensant on heu d’apretar per seguir, el que fa no llegir les coses.

nova versió del devilspie

Reading time: 1 – 2 minutes

A finals del 2004 vaig parlar del devilspie una eina que em permet llençar les aplicacions als workspaces. Doncs bé la qüestió és que la nova versió del Devil’s pie ha canviat totalment el format de configuració i totes les configuracions que tenia montades per la versió antiga no m’han servit per res.

L’antiga sintaxis es basava en XML l’actual s’assembla més a un algoritme. Abans tot estava en un fitxer de configuració i ara s’han de crear fitxers amb l’extenció .ds dins el directori ~/.devilspie i dins podem veure coses com aquestes:

(if (contains (window_name) "Firefox") (set_workspace 4))

La configuració anterior envia el firefox a l’area de treball 4, un altre idea perquè quedi clar el senzill que és d’usar, carreguem l’asmn perquè estigui present a totes les arees de treball:

(if (contains (window_name) "aMSN") (pin))

Ara uns links cap als manuals de veritat:

SOAP vs XML-RPC

Reading time: 4 – 6 minutes

Abans de començar un detall important sobre el món XML, compte a no acabar com el de la foto:

xml.jpg

Bé doncs ens trobem davant de dos protocols del tipus RPC (Remote Procedure Control), o sigui, que serveixen per intercomunicar dos processos que estan corrent en sistemes dispersos. Si mai ús han donat Sistemes Operatius, segur que us han fet fer la típica pràctica d’RPC d’Unix programada en C. El que acostuma a ser el mal son de tots els alumnes d’informàtica i telemàtica. Doncs bé, tranquils des d’aquella teoria inicial sobre RPC s’ha avançat molt.

De fet, jo fa molt de temps que uso els XML-RPC per implementar web-services senzillets entre les meves aplicacions. Hi ha un protocol que s’usa molt en el món del blogging, es diu ping (no el de tota la vida per mirar si un sistema és viu). Bàsicament el ping el que fa és aprofitar l’XML-RPC per notificar a un altre servei web un event de la nostre web, concretament que hem actualitzat el blog. També s’usa XML-RPC per fer trackback entre articles a diferents blogs. Així podem informar a un altre blog de que hem parlat sobre aquell article que ell ha escrit. Fixeu-vos que tot això és independent del sisteam operatiu, el servidor web, l’aplicació, etc.

Com podeu veure l’XML-RPC esta molt estès i és realment molt útil i senzill d’usar en totes aquestes aplicacions que us comento. Per tant, podriem dir que l’XML-RPC esta orientat a la simplicitat i la senzillesa d’ús, permet passar dades entre processos codificant-les en XML i usant l’HTTP com a protocol de transport. El model de dades que usa l’XML per implementar XML-RPC és molt senzill i si mireu un HTTP-POST que transporti una transacció XML-RPC veureu que és molt senzill entendre les estructures de dades que es monten a partir de les típiques etiquetes.

soap.gif

Llavors ús preguntareu; si l’XML-RPC va tan bé perquè carai vull el SOAP o fins hi tot; què carai és el SOAP. Doncs bé, el Simple Object Access Protocol (SOAP) és un protocol RPC com ja he dit i també es codifica en XML i es transporta sobre HTTP, i encara us diré més també serveix per transportar informació estructurada en el seu interior. La diferència escencial és que és capaç de transportar estructures de dades força complexes i a més permet definir contra quin mètode de quina classe han de ser usades aquestes estructures. Així doncs, el SOAP ens permet oferir infinitat de serveis en un sol biding (publicació) de servei.

Com podeu veure l’escència és la mateixa però la potència és ben diferent. SOAP al suportar models de dades tan complexos fa que quan intentem mirar un XML dels que usa per fer les transaccions ens costi força entendre el que hi ha dintre. Ja que a la mínima que ens compliquem una mica el model de dades a passar pel webservice es fa ben difícil entendre el munt d’etiquetes i d’atributs de les etiquetes que es creen.

A més SOAP disposa de diferents extencions que el fan encara més potent. Bàsicament les més conegudes són SOAP 1.1, SOAP 1.2 i WSDL. Aquest últim és el més usat per implementar WebServices, el seu propi nom ja ens indica aquest fet WSDL: Web Services Description Language. Concretament Microsoft amb .NET, IBM i Sun amb Java fan diverses implementacions del WSDL per tal d’implementar WebServices en les seves arquitectures. Això ens va de perles a la gent que ens agrada el PHP, perquè permet que ens entenguem amb els ASP, JSP, servlets i altres similars des del nostre PHP5 que ja implementa suport de SOAP/WSDL de serie.

Si voleu començar a jugar amb el SOAP i el PHP5, a la pròpia web de Zend podeu trobar aquest document: PHP SOAP Extension. Per una informació més tècnica del WSDL, la gent d’xml.com tenen un munt de documents sobre el tema, concretament us recomano: WSDL first i encara un altre sobre el mateix Examining WSDL. Si ja controleu l’UML és una bona idea que comenceu a veure com es modelen els WSDL des d’UML, un bon document per començar UML for Web Services.

Abans d’acabar l’article si voleu un document seriós que resolgui els vostres dubtes sobre les diferències que hi ha entre XML-RPC i SOAP, sobretot no us perdeu: XML-RPC vs SOAP (local)d’en kate rhodes.

Aprenent UML

Reading time: 2 – 2 minutes

uml.gif

Ja he repetit mil vegades que no sóc informàtic, així doncs, mai havia après UML fins aquest cap de setmana que aprofitant que estava de Rodriguez m’he fotut una marató d’aquelles que feia temps que no feia.Doncs per tal de posar remei a la meva mancança en el tema UML m’he llegit/estudiat el llibre Aprenda UML en 24 Horas (editorial: Prentice Hall. 2001. Autor: J. Schmuller. ISBN: 968444463X. link amazon).

La veritat és que encara estic destrossat de l’esforç però us recomano el llibre. Realment no és res de l’altre món però si com jo teniu un problema i no pas la teoria per plantejar-lo, doncs jo diria que és la millor solució que he trobat per avui dilluns haver-lo pogut afrontar ja amb UML directament. M’ha agradat molt el fet que esta orientat a objectes tot el que explica això ja et permet pensar ràpidament en conceptes que coneixes i que et permeten avançar moltíssim.

Una altre cosa important del llibre és que no comença amb la pesada teoria de l’UML sinó que va directament a ensenyar-te a usar les eines, és a la segona part del llibre on tot això es posa en pràctica en un problema real i llavors et queda ben clar com s’han d’usar totes aquestes eines. Ara com sempre passa quan entres en una matèria que fins ara era nova és que tinc el gusanillo d’aprofundir més en alguns conceptes especialment en temes de Design Patterns.

Fer un business plan sense tenir-ne ni idea…

Reading time: 2 – 4 minutes

Com sabeu jo sóc telemàtic i això dels negocis ho estic aprenent a base de caure i aixecar-me. Doncs bé estic cansat d’escriure plans de negoci sense tenir un patró clar de quins són els punts que aquest ha de contenir. Així que la setmana passada vaig escriure el que sota la meva opinió és el millor que he escrit, encara no m’han donat feedback de que tal esta. Crec que defineix perfectament el que vull que sigui movilpoint i després de molt de temps i molts esforços jo diria que tots els socis hi estem d’acord.

Però bé, jo l’únic que us volia dir als que tingueu la necessitat de fer-ho i com jo només disposeu de l’ajuda del google que a mi em van anar bé quatre documents que a continuació us enllaço. Es tracte de 4 articles no massa llargs i que si els sumem al fet de tenir les idees molt clares sobre el nostre negoci ens ajudaran a tenir una guia de quins són els punts a tocar i explicar en el que s’ha de convertir en el llibre de navegació del nostre negoci.

  • El plan de marketing en la empresa (local) amb aquest document ja teniu per on començar. Té una minidescripció de tots els punts a tocar al vostre business plan. En el meu cas alguns no calia i en faltaven alguns altres. Però en general m’ha estat molt útil.
  • La matriz DAFO y su aplicación en el ajedrez (local) si com jo això de DAFO us ha sonat a japonés, doncs bé resulta que és un dels punts que s’han de posar en un pla de negoci. Així doncs amb aquest petit document podem resumir les vostres: debilitats, amenaces, fortaleses i oportunintats.
  • Estrategias de Marketing – La Matriz RMG I aquest document ja parla de temes una mica més avançats però si en el vostre business plan voleu realment explicar d’on sortiran els diners en la vostre empresa és una bona idea incloure’l.
  • Estrategias de Marketing – La matriz RMG II la segona part del document que comentava avanç. Com podeu veure aquest tema no és trivial, però tampoc és indispensable en molts casos. Així que no us desanimeu.

En el primer dels documents vaig trobar un quadre resum que m’ha ajudat molt a l’hora de no perdrem escribint. Així que per no perdre aquesta eina tan útil aquí teniu l’enllaç.

Scroll to Top