blogElectronica.com

No todos los modems del mercado disponen de la funcionalidad OTAP (Over The Air Provisioning). Modems como los Siemens TC65, XT65 o MTX65 (distribuidos en España por Matrix Electrónica) sí disponen de esta característica especial.   Esta es una función muy importante que nos permitirá actualizar el firmware de nuestro modem mediante GPRS o mediante una conexión de datos CSD.
 

Imáginemonos una situación real. Imaginémonos que tenemos 500 modems distribuidos por todo el país con una aplicación embebida en su interior. Llega un día en el que queremos actulizar el firmware, bien porque es necesario introducir nuevas funcionalidades, bien porque hemos detectado un fallo en el firmware que hemos desarrollado y debemos reprogramar todos los equipos. Si estos equipos no pueden ser reprogramados a distancia, el coste de la reprogramación será enorme pues será necesario desplazar a técnicos a cada ubicación para realizar dicho proceso in situ. Modems como los comentados anteriormente de Siemens sí contemplan estas situaciones y es posible reprogramarlos a través de un simple proceso llamado OTAP.

¿Y qué se puede hacer mediante OTAP?

OTAP  es un mecanismo que nos permite instalar, actualizar y borrar nuestras aplicaciones embebidas java a través de GPRS o CSD. Esta funcionalidad puede ser controlada vía comandos AT o bien a través de mensajes SMS. En ambos casos necesitaremos contar con un servidor HTTP, donde alojaremos nuestros ficheros.
 

¿Cómo actualizar el firmware mediante OTAP y comandos AT?

El comando AT que hay que utilizar es el propietario de Siemens AT^SJOTAP. Podría explicar cada parámetro pero para eso ya tenéis la documentación aquí, por lo que es mejor que le deis un vistazo . Lo mejor que puedo hacer yo aquí es poner un ejemplo real y que funcione, para que lo podáis probar vosotros.

Para cargar un programa en un módem TC65, XT65 o MTX65 basta, primero, con enviar este comando AT:

AT^SJOTAP=”blogElectronica”,
“http://www.blogelectronica.com/TEMP/HelloWorld.jad”, “a:”,,,”gprs”,”airtelnet.es”,”vodafone”,”vodafone”,”080.058.000.033″,

Después, una vez configurado el OTAP, lo ejecutamos. Para ello enviamos el comando AT (el mismo que antes pero sin parámetros):

AT^SJOTAP

Y si queremos ver lo que está pasando, os recomiendo que inmediatamente, tras ejecutar el comando anterior, ejecutéis el comando AT:

AT^SCFG=Trace/Syslog/OTAP,1

De esta manera podremos ver (a través de datos enviados por el puerto serie) un LOG de lo que está sucediendo. Así sabremos si está funcionando bien o mal.

Aquí tenéis una captura de pantalla del hyperterminal, donde podéis ver que todo ha ido bien:
 

¿Cómo actualizar el firmware mediante OTAP y SMS? 

El proceso también puede iniciarse a través de SMS, es decir, podemos enviar un mensaje SMS a nuestro módem para que inicie la actualización de firmware. También es posible eliminar ficheros.
Para subir un programa básicamente hay que enviar un mensaje SMS con una serie de datos, no todos son obligatorios, (consultar el manual) después de configurar el modem con el parámetro AT^SJOTAP :

OTAP_IMPGN
PWD:blogElectronica
JADURL:http://www.blogElectronica.com/TEMP/HelloWorld.jad
APPDIR:a:
BEARER:gprs
APNORNUM:airtelnet.es
NETUSER:vodafone
NETPWD:vodafone
START:install

No olvidar incluir un LF, es decir, un \n, o lo que es lo mismo, un final de línea en cada línea de los parámetros, incluída la última. El mensaje SMS tiene que estar codificado en PDU. Tener en cuenta que el parámetro PWD, que en el ejemplo es “blogElectronica”, es un password que debe estar siempre en el mensaje SMS y que debe coincidir, lógicamente, pues está para eso, con el configurado en el comando AT^SJOTAP.

Por supuesto, también resulta útil para las pruebas con SMS ejecutar el comando AT:

AT^SCFG=Trace/Syslog/OTAP,1

como hicimos en el caso anterior.
 
 
No funciona con mi modem Siemens TC65.  ¿Qué puede pasar?

Después de mirar el PIN de la SIM, la cobertura GPRS, mira qué versión de firmware tienes. Para ello ejecuta el comando ATI. Comprueba que la versión de firmware del equipo. El TC65 tiene que tener como mínimo la versión 2.0, que es una versión de hace ya más de un año. Con el XT65 (versión con GPS) y el MTX65 no hay problemas de versiones.
 
 
Me funciona el ejemplo de blogElectronica, pero no con mi programa  ¿Qué puede pasar?

¿Está puesto dentro del JAD la ruta URL correcta al fichero JAR? ¿Tengo los parámetros MIDlet-Name, MIDlet-Version, MIDlet-Vendor especificados dentro del JAD? ¿Es correcto el tamaño del fichero JAR que está especificado en el parámetro MIDlet-Jar-Size del fichero JAD?
 

Espero que encontréis de utilidad este post.

Se acaban las vacaciones para todos. Muchos decimos, “ufff, vuelta a madrugar, vuelta a trabajar … a ver si tengo suerte y me toca la lotería … “. De hecho la recaudación por loterías aumenta siempre en Septiembre de forma cosiderable. Hoy me han enviado un email con un link a un flash de esos que no dejan indiferente. Lo podéis ver aquí. Tras ver ese flash uno puede darse cuenta realmente de la suerte que tiene por tener que madrugar, por tener que trabajar … en definitiva la suerte que tenemos de haber nacido donde hemos nacido y de lo insignificantes que realmente son la mayoría de nuestros problemas y pequeños sacrificios cotidianos en comparación con esa tragedia. Espero y deseo que algún día Internet pueda llevar el conocimiento gratuito a toda esa gente, que es la base imprescindible para poder prosperar.

En fin … volviendo al temas más mundanos, hoy voy a empezar una serie de artículos relacionados con módulos embebidos (o embedded modules) bajo Linux embbeded. Los iré alternando con otros artículos de temática diversa. Como hay que basarse en algo, lo voy a hacer en módulos embebidos de Digi, concretamente en los modelos ConnectCore9C, ConnectCore9P o ConnectCoreWi9C. A aquellos que vayan a utilizar otra marca creo que también les puede servir, pues los conceptos son muy parecidos. Evidentemente a quien use los módulos de Digi (de los que he de reconocer que ha mejorado mucho la documentación) les resultará más útil e interesantes todos estos post. De hecho para estos capítulos me voy a basar en la documentación oficial de Digi.

¿Qué diferencias hay entre aplicaciones para PC convencional o para sistemas embebidos?

No es lo mismo desarrollar aplicaciones para un PC convencional que para un sistema embebido. El desarrollo de aplicaciones para sistemas embebidos implica tocar bastantes elementos además de la propia aplicación, como son el Sistema Operativo y sus posibles personalizaciones, los drivers, el sistema de ficheros, entre otros. Como he dicho antes nos vamos a basar en el S.O. Linux Embedded, muy extendido hoy en día en este tipo de dispositivos debido a la propia naturaleza de Linux, disponible para muchas arquitecturas de hardware que lo hacen un buen candidato para estos menesteres. Veamos algunos conceptos.
 

Cross-compilation  (compilación cruzada).

Siempre que desarrollemos el software para un dispositivo embebido en una plataforma con una arquitectura de procesador diferente, es necesario utilizar un entorno de desarrollo cruzado. Un compilador cruzado es un compilador que se ejecuta en el sistema de desarrollo, es decir, en  nuestro PC portátil o de sobremesa (Intel x86, por ejemplo) donde desarrollamos la aplicación para el módulo embebido, pero que el código que genera se ejecuta en otro procesador. En nuestro caso de los módulos de Digi, en procesadores ARM.
 
 
Boot loader.

El boot loader es un pequeño software que se ejecuta justo al encender un ordenador. Si hablamos de nuestro PC de sobremesa, este pequeño programa que reside en el MBR (Master Boot Record) de nuestro disco duro, se ejecuta una vez que la BIOS del ordenador ha inicializado todo el sistema. El boot loader entonces pasa información del sistema al Kernel, es decir, la partición del disco duro donde se montará la root y finalmente se ejecuta el propio kernel.

Pero si hablamos de sistemas embebidos esto es más complicado, ya que estos sistemas NO tienen BIOS que inicialicen el sistema y la inicialización del microprocesador, de los controladores de memoria, y en definitiva de todo el hardware de la placa debe hacerlo el programita de la boot antes de que se ejecute el Kernel del sistema.

Como mínimo el boot loader debe inicializar el hardware, especialmente los controladores de memoria y arrancar el sistema operativo con los parámetros adecuados, aunque también puede tener funcionalidades adicionales, como la lectura y escritura en memoria, y todas aquellas funcionalidades que permiten poder actualizar el firmware (sistema operativo, aplicaciones, …) en la memoria flash del equipo vía serie o ethernet.
 
 
El Kernel

El Kernel es la parte fundamental del sistema operativo, el núcleo del sistema. Es el responsable de la gestión de los recursos y las comunicaciones entre el harware y el software, proporcionando una abstracción de hardware y proporcionando una manera segura de acceder al sistema de memoria. También es el responsable del control de las interrupciones y de todas las operaciones de E/S (Entrada/Salida).
 
 
Modulos del Kernel.

Los módulos del kernel son pequeños programitas que son cargados y descargados por el kernel del sistema en función de las necesidades. A modo de ejemplo, un driver de un dispositivo lo podéis ver como un módulo del kernel, el cual permite a dicho kernel poder acceder al hardware conectado al sistema. Si no hubiera módulos tendrían que implementarse en el propio kernel y éste sería terriblemente largo y poco abierto. De esta manera cuando modifiquemos un módulo no tendremos la necesidad de recompilarlo todo de nuevo.
 
 
Root File System.

Como sabéis los Sistemas Operativos manejan ficheros y directorios.  El Root File System digamos que está en el techo del árbol de directorios y ficheros. Éste contiene ficheros y directorios críticos para las operaciones del sistema como pueden ser los programas de inicialización del sistema.
 
 
Aplicaciones.

Esto es lo que más conocéis todos, pues son los programas que utilizan los recursos de un procesador para realizar tareas. Las aplicaciones hacen uso de los dispositivos hardware, como hemos dicho a través de los drivers, los cuales son parte del kernel.
 
 
Espero que os haya resultado interesante esta primera introducción.

Tal vez en alguna ocasión hemos tenido que diseñar algún circuito en el que entre en juego el uso de la línea telefónica convencional. Un ejemplo puede ser un sistema de seguridad para llamadas de voz. Por ejemplo, imaginemos que queremos diseñar un equipo que nos permita realizar llamadas de voz utilizando la línea telefónica convencional y, automáticamente, en el caso de la caída de esta, que las llamadas de voz salgan a través de la línea GSM. Aplicación también útil para sistemas de alarmas, por ejemplo.

Hay dos formas de llevar a cabo esta aplicación. Una sería el diseño por nosostros mismos de los circutos de telefonía, lo que requiere de ciertos conocimientos específicos en la materia, de tiempo de diseño de los circuitos, de los pcb, de las pruebas, de las certificaciones, en definitiva, de una cantidad de requerimientos que se traducen en tiempo y dinero.

Y la otra forma, la más fácil y rápida, es utilizar dispositivos que existen ya en el mercado para estos menesteres, como son los interfaces de línea. Silver Telecom dispone de dichos interfaces. Podríamos clasificarlos en dos grupos. Por un lado tendríamos los SLIC, que serían unos dispositivos que digamos emularían la línea telefónica y por otro lado los COIC, que emularían a lo que serían los teléfonos conectados a la línea telefónica.

Hoy voy a comentar rápidamente los SLIC, otro día hablaré de los COIC y finalmente pondré un circuito ejemplo real de aplicación del uso combinado de ambos dispostivos.

El SLIC más utilizado de Silver Telecom es el ag1170. Podéis verlo en la fotografía superior.  Es un pequeño dispositivo que como decía anteriormente emula lo que sería la línea telefónica. Es decir, genera, a partir de los 5V (o 3.3V) de alimentación, todas las tensiones que genera la línea telefónica, generando por tanto el tono de espera, el ring (75V), etc …

Estas señales pueden generarse fácilmente a través de los pines de entrada del dispositivo (ver datasheet), que pueden ser controlados fácilmente desde cualquier microprocesador básico. También convierte de los dos hilos con los que digamos emula la línea telefónica (llamados TIP y RING) y a los cuales podríamos conectar cualquier teléfono convencional que tengamos por casa (o a una distancia de hasta 3Km ), a cuatro hilos. Dos serían de entrada de audio y dos de salida de audio. Por supuesto, todo el tema de adaptación de impedancias puede programarse y es muy simple de implementar, pues basta utilizar unos pocos componentes externos, siguiendo las instrucciones del fabricante.

Todo el tema de protecciones también lo tiene resuelto el ag1170 de Silver Telecom. Por ejemplo, protecciones térmicas para el caso de cruce de las líneas TIP y RING, caso en el que el conversor interno DC/DC del dispositivo se encargaría de limitar, o protecciones contra sobrevoltajes.

Cuando hablemos del coic y veáis un ejemplo de aplicación final, seguro que quedará todo más claro y veréis mejor la utilidad. Y es que desde mi punto de vista hoy en día la tendencia es a utilizar cada vez más módulos ya diseñados, pues el tiempo de colocación de un producto en el mercado es crucial. Nadie se pone a diseñar hoy en día un módem GSM (ni uno analógico) se compran módulos hechos y los integramos en nuestros diseños. Con los interfaces de línea ocurre cada vez más.

Espero que os pueda resultar interesante en algún momento este post.

En los próximos días voy a empezar a hablar de los módulos embebidos de Rabbit Semiconductor (distribuidos en España por Matrix Electrónica). De todos los módulos procesados embebidos que conozco éstos son, los que más me gustan (y con diferencia). ¿Por qué? Pues por su versatilidad, por su potencia, por la extraordinaria facilidad de uso y por los cientos y cientos de ejemplos que hay que hacen que casi para cualquier desarrollo que quieras hacer haya un ejemplo disponible, sino igual, bastante parecido, que siempre es un buen punto de partida. Todo ello permite implentaciones rápidas y sin dolores de cabeza.

No he comentado lo que es un módulo microprocesado embebido, y como tal vez algún lector no lo sepa, lo comento muy rápidamente. Un módulo microprocesado embebido (en este caso de Rabbit) consiste en una pequeña placa (PCB) donde está montado pricipalmente un microprocesador, las memorias (RAM, FLASH, …) y todos aquellos componentes necesarios para poder trabajar con el micro (como los relojes, y otra serie de componentes externos). Estas pequeñas placas cuentan con conectores (en el caso de Rabbit tienen 1 ó 2 conectores de inserción) para poder incorporarlos en nuestros diseños. Una explicación mucho más precisa de un sistema embebido la podéis encontrar aquí.

Pero antes de hablar de los módulos embebidos de Rabbit es necesario hablar de los microprocesadores que montan estos módulos. Hay  que decir que normalmente los usuarios de Rabbit utilizan sus módulos, más que sus micros directamente, ya que los módulos embebidos son una solución acabada, probada y muy económica. Muy difícil es que diseñemos una placa similar a uno de sus módulos y que nos salga más económico, pues Rabbit vende cientos de miles de módulos al año, con lo que el precio lo tiene muy ajustado.

¿Y cuales son los modelos de micros de Rabbit?
 
 
Rabbit 2000

Este es el microprocesador de Rabbit de menores prestaciones. Es un microprocesador de 8 bits pero que supera en cuanto a prestaciones a muchos microprocesadores de 16. Trabaja a 5V a una velocidad máxima de reloj de 30Mhz. Dispone de 4 puertos serie de alta velocidad (hasta un maximo de la velocidad de 460800 bps) y un bus de direccionamiento de 20bits. Dispone de 40 pines I/O de proposito general, RTC, Watchdog y permite trabajar en bajo consumo (32KHz)
 
 
Rabbit 3000

Evolución de la familia Rabbit 2000. Es también un micro de 8bits de altísimas prestaciones. La tensión de trabajo es de 1.8-3.6V, pero es también tolerante a 5V (muy útil cuando trabajamos con otros compomentes que trabajan a este voltaje). La frecuencia máxima de reloj es de 55Mhz. Cuenta con 6 puertos serie de ata velocidad (hasta un maximo de 460800bps), un bus de direccionamiento de 20 bits (lo que le permite direccionar hasta 1MB), 10 timers de 8 bits y 1 timer de 10bits, RTC y 56 pines de I/O de propósito general. También es posible trabajar en modo bajo consumo (32Khz) y ultrabajo consumo (16,8,2 KHz).
 
 
Rabbit 4000

El último diseño de Rabbt, evolución del Rabbit 3000. Como características principales decir que sigue siendo un micro de 8 bits (pero de altísimas prestaciones). La tensión de trabajo es 1.8 voltios, aunque las I/O también pueden trabajar a 3.3 voltios (en este caso ya no es tolerante a 5v). La frecuencia de trabajo es de hasta 60Mhz y ya viene integrado con un controlador Ethernet (cosa que para los anteriores modelos es necesario utilizar un chip externo de Realtech). En este caso el bus de direcciones es de 24 bits (frente a los 20 de la serie 3000). También dispone de 12 timers (diez de 8 bits, uno de 10 bits y otro de 16bits), 8 canales DMA, 40GPIOs de propósito general y permite trabajar también en modo bajo consumo (32Khz) y ultrabajo consumo (16,8,2 KHz).
 
 
Si quereis más información la podéis encontrar en http://www.rabbitSemiconductor.com.  Aunque desde hace unos meses también es posible acceder a la web a través de http://www.Rabbit.com. Como curiosidad os puedo decir que Rabbit desembolsó una importante cantidad de dinero para comprar ese dominio, antes ocupada por una web con otro tipo de contenidos, os lo podéis imaginar …   (Por cierto, y aunque no tenga nada que ver con la electrónica, pero seguro que a más de uno (y de cien) le resulta muy interesante, os paso el siguiente link:  http://www.archive.org/web/web.php . En él podréis ver el pasado de un dominio, es decir, qué había en una determinada web en una deteminada fecha. No tiene desperdicio, es un link para guardarlo en favoritos, como blogElectronica ).
 
 
Bueno, y volviendo al tema … en los siguientes posts publicaré algún artículo de módulos embebidos de Rabbit vistos en profundidad (especialmente de la serie 3000 que son los que más conozco. Seguramente será el modelo más usado, el RCM3700), así como también veremos el entorno de desarrollo que se utiliza con ellos (el Dinamyc C) del cual intentaré poner algún video para que lo veáis. Veréis lo amigable que resulta trabajar con estos módulos.
  

Espero que os resulte de interés este post

Hace unos días hablaba acerca del protocolo VRRP.  Recordemos que, en pocas palabras, las redes que utilizan routers que implementen VRRP pueden tener routers de backup, por lo que si nuestro router ADSL convencional falla, la red automáticamente selecciona otro router (por ejemplo, uno UMTS) por el cual saldrá todo el tráfico hacia Internet hasta que el problema con el router principal se haya solucionado.

Pues bien, un router que implementa en su firmware VRRP y que además es UMTS / HSDPA es el 3-GAT de uSyscom, el cual es distribuido en España por Matrix Electrónica.

Al igual que la mayoría de los routers ADSL, este router UMTS / HSDPA dispone de un switch integrado de cuatro puertos, lo que permite que varios equipos puedan conectarse diréctamente, sin necesidad de utilizar un switch o hub adicional. La interfaz de configuración es web y es muy sencilla y rápida de utilizar.
  

¿ Y cuáles son las características más importantes de este Router?
 

• IP aliasing.
  Permite diferentes subredes lógicas bajo un mismo segmento físico de red. Es decir, al router se le puede conectar de forma simultánea más de una subred, lo que permite que diferentes subredes de nuestra empresa puedan utilizar un mismo router.
   
• NAT
  Al igual que en los routers ADLS, podremos routear el tráfico proviniente del exterior por uno o varios determinados puertos TCP o UDP hacia diferentes direcciones IP y puertos de la red interna.
   
• VPN-IPSec.
  Permite realizar conexiones seguras VPN-IPSec.
   
• Firewall IP.
  Pueden introducirse reglas de tráfico IP para sólo determinado tráfico pueda circular por el router, impidiendo entradas o salidas no deseadas.
   
• Servidor DHCP.
  Dispone de servidor DHCP para asignar direcciones IP dinámicamente.
   
• VRRP.
  Como decíamos al inicio de este post, una característica destacable de este router es que implementa el protocolo VRRP.
   
• 4 puertos ethernet 10/100.
  Pueden conectarse de forma directa hasta 4 equipos IP sin necesidad de ningún switch o hub adicional.
   
   

¿Y para qué puede resultar interesante un router como éste?

Pues puede servir para conectar pequeñas redes bien a internet o a intranets corporativas a través de UMTS. Especialmente indicado para pequeñas redes móviles, instaladas en trenes, autobuses, furgonetas, barcos… en las que no sea posible la utilización de líneas fijas ADSL

Como router de back-up. Como decíamos, gracias al protocolo VRRP podemos utilizar este dispositivo como backup.

Transmisión de vídeo. El router 3-GAT, permite la conexión directa de las nuevas cámaras Ethernet de video, permitiendo el acceso on-line desde cualquier localización. Ideal para cámaras de televigilancia en lugares en los que no haya otro medio de transmisión de la señal, como invernaderos, plantas fotovoltáicas, etc etc …
 
 
Espero que os haya resultado de interés este post.