blogElectronica.com

Algunos de vosotros ya conocéis la existencia del nuevo módulo GSM/GPRS de Cinterion de nombre TC65i-X, otros muchos no, así que hoy voy a comentar un poco los aspectos más relevantes de este nuevo e interesante módulo.
Como digo el nombre del módulo es TC65i-X y es, básicamente y como puede deducirse de su nombre, un módulo TC65i con algunos cambios. Estos cambios son tanto a nivel de hardware como a nivel de software, todos ellos positivos.

¿Y cuales son los cambios a nivel hardware?

Pues básicamente es cambio es uno y para mi el más importante de todos, incluidos los cambios de software. Como sabéis el módulo gsm/gprs TC65i es programable en Java (J2ME). Este módulo cuenta con unos 400KB de RAM y 1.7MB de Flash. El nuevo módulo TC65i-X aumenta mucho esa capacidad llevando la memoria RAM hasta los 2MB y la memoria flash hasta los 8MB (divididas en 2 particiones de 4MB).

Esto obviamente es importante. Aquellos, entre los que me incluyo, que desarrollamos aplicaciones grandes siempre nos llega un momento en el que tenemos que ir programando con mucha cautela ya que la memoria RAM del TC65i es algo limitada para algunas aplicaciones. Con 2 MB de memoria Ram la cosa cambia mucho y ahora es posible realizar aplicaciones java grandes y complejas sin ningún tipo de problema.  De forma análoga puede ocurrir con la memoria Flash, ahora de 8MB.

¿Y a nivel software, qué cambios tenemos con el nuevo módulo TC65i-X?

Pues bastantes. Voy a poner aquí las que me parecen más relevantes.

1.- Soporte, por fin, para poder trabajar con el Entorno Eclipse y MES con versiones Windows 64 bits. Esto es, Vista 32/64 bits y Windows7 32/64bits. Básicamente es debido a la nueva versión MES 2.7.0.0 ya disponible.

2.- Inclusión de ciertas APIs java para el manejo del GPS (por si conectamos un módulo GPS a uno de los 2 puertos serie del módulo TC65i-X).

Lee el resto de esta entrada »

Hoy voy a hablar de un modulito nuevo de la casa Imsys. Realmente creo que tendría que haber comentado ya algo de esta casa pues que estoy seguro que va a crear cierto interés este tipo de módulos porque muchos de los lectores de blogElectronica.com son usuarios de los conocidos módulos TC65 y XT65 de Cinterion (de los que por cierto, dentro de muy poco, volveré a hablar con noticias agradables).

Como decía, os presento el nuevo módulo Snap Stamp de la casa Imsys. Lo primero de todo, una foto, para que os conozcáis:

Como véis es un modulito muy pequeño, de 29mm de lado (de ahí el nombre Stamp, del tamaño de un sello).  Este módulo está basado, y aquí está lo importante, en el procesador JAVA IM3910.  Es decir, de la misma forma que programamos los módulos Cinterion XT65, TC65i y terminales MTX65 en java (J2ME) se programan estos módulos. Es decir, si ya estás familiarizado con la programación java de los módulos Cinterion y MTX, ya sabes programar el módulo Snap Stamp. Esto, evidentemente, es una ventaja en time-to-market increíble para todos aquellos que tengan que iniciar un nuevo proyecto con un módulo procesador, por el know how y por el aprovechamiento del código y clases java que uno pueda ya tener desarrollado para los módulos Cinterion y terminales MTX.  Es como con éstos últimos, compilas tu programa (en Eclipse o Netbeans) subes tu fichero .JAR al módulo (en este caso no por OBEX, sino por ethernet (ya sea local o remotamente) y a funcionar.

De la misma forma que con los módulos de Cinterion el Snap Stamp tiene un completo stack TCP/IP, pero además servidor web, ftp, telnet, gestor de I/O, …

Aquí están las características técnicas del módulo:

• High performance multi-threaded Java execution
• Certified J2ME-CLDC virtual machine
• Four channel A/D 16-bit 44 ksps converter with optional external reference voltage
• Two D/A 16-bit 44ksps converters
• 2* / 4* / 8 Mbytes Flash memory
• 8 / 32* Mbytes SDRAM
• 10/100Base-T Ethernet MAC and PHY
• Optional 2nd RMII interface
• TCP/IP stack, Web/FTP/Telnet server
• Three serial ports (3.3V levels, 4-wire, 920 kb/s)
• High-speed I2C bus and SPI
• Parallel 8-bit high speed data bus
• 8 to 53 General-purpose digital I/O ports
• MMC / SD card support
• Extensive I/O functions through Java APIs, including PPP, FTP, E-mail, GPIO, Timers
• Enhanced performance for special functions e.g. graphics, crypto, and floating point operations
• Rubus JOS RTOS with failsafe flash file system
• High I/O bandwidth (>650 Mbits/s DMA)
• Real time clock and calendar
• On board Temperature sensor
• 150 / 200* MHz oscillator frequency
• Commercial / Industrial* temp range
• Connection for Imsys JTAG Trace Adapter
• Reference designs available, complete with schematics and firmware for:
Dallas/Maxim 1-wire
CAN
     TFT LCD, Touch panel
       CD quality Audio

Donde pone * indica que es opcional, y se suministran así bajo un pedido mínimo de piezas.

Aquí tenéis también una pequeña comparativa entre el procesador Imsys y distintos procesadores.

Espero que encontréis el modulito de interés. Vamos, conociendo ya a muchos de los fieras que leen este blog estoy seguro que así será y que mañana ya tengo algún email preguntando.

Hoy voy a poner un pequeño post sobre Proguard, un ofuscador para Java. Probablemente muchos lo conozcáis y lo utilicéis ya con vuestras aplicaciones j2me, pero para los que no, os aconsejo dar un vistazo a este articulillo, que os irá bien, sinó ahora, más adelante, en alguna ocasión, con algún nuevo proyecto con módems Cinterion (TC65, XT65) o los terminales MTX.

El uso de un ofuscador para nuestras aplicaciones j2me es interesante, más que por su capacidad de “ofuscar el código”, por la reducción del tamaño final del fichero “.jar” generado. Nunca hay que olvidar (aunque alguno a veces parece que lo haga ) que no estamos programando un procesador Core2Duo, sino que estamos programando dispositivos con un tamaño de memoria RAM y FLASH muy limitada. Por ejemplo un módem GPRS MTX65 dispone de una memoria RAM de unos 400KB y de 1.7MB de memoria FLASH. El uso de un ofuscador nos hará aprovechar al máximo la preciada memoria FLASH y sobre todo la memoria RAM de nuestros módems.

Para hacernos una idea, el nuevo firmware del MTXTunnelv5.0 que saldrá en breve (este mes) ocupa, sin ofuscar, unos 130KB, mientras que ofuscándolo unos 80KB. Podéis ver que la reducción es bastante significativa.

¿Y qué hay que hacer para usar un ofuscador?

Pues lo primero de todo bajárselo.

¿Con el emule?

No, que es gratis.

¿Y dónde está?

Lo encontrarás en este Link: http://sourceforge.net/projects/proguard/files/

Bájalo y descomprímelo dentro de la carpeta del Eclipse, es decir, dentro en:

c:\Eclipse\proguard4.5.1\

Después ves a Window > Preferences > J2ME > Packaging > Obfuscation y selecciona el PATH adecuado tal y como puedes ver en la pantalla siguiente.

Una vez hecho esto ya puedes “compilar” tu aplicación ofuscándola. Para ello en lugar de hacer un “Create Package” hacemos un “Create Obfuscated Package”.

Lee el resto de esta entrada »

Posiblemente en alguna ocasión tengas que hacer un programita en Java para un módem Cinterion TC65 o XT65 en el que tengas que capturar datos (entradas digitales, analógicas, posiciones GPS, capturas realizadas por el puerto serie …) y almacenarlas en un fichero interno de la flash para su posterior envío a un servidor central.

Hoy os cuelgo un pequeño ejemplo en Java para hacer la segunda parte, el envío de los datos por FTP a un servidor central.

Hace ya mucho tiempo puse unos posts con muchos ejemplos java, entre ellos ( http://www.blogelectronica.com/ejemplos-java-j2me-modem-gprs-siemens/ ó http://www.blogelectronica.com/j2me-ftp-cinterion-tc65-xt65-mtx65-tc65t/ ).

En este último también había un ejemplo de FTP. Este de hoy es más elaborado, pues permite subir directamente un archivo almacenado en la memoria flash de nuestro módem a un servidor vía FTP. El proyecto y código fuente del ejemplo lo puedes descargar de aquí­.

Para probarlo sin complicaciones haz lo siguiente paso a paso. Crea un fichero de nombre “datos.txt” con los datos que quieras en su interior y grábalo en la memoria FLASH de tu módem TC65 / XT65 (en el directorio raí­z). Después importa el proyecto de ejemplo desde Eclipse. Abre el fichero FtpHandle.java, en él verás que se leen algunas variables del fichero EjemploFTP.jad

Lee el resto de esta entrada »

Últimamente me han preguntado bastante en relación a la memoria RAM de los módulos gprs TC65 y XT65 (y sus correspondientes terminales) así que voy a poner un pequeño artículo en relación a este tema.

Como sabéis el módulo TC65 tiene un total de 400KB de memoria RAM y 1.7MB de memoria FLASH. Es evidente que la memoria flash, FFS (File Flash System, el sistema de archivos) estará en parte ocupada por nuestra aplicación java (es decir, por los ficheros .jad y .jar) y por todos aquellos archivos extra que necesitemos para nuestra aplicación así como los propios archivos generados por nuestra aplicación java, es decir, ficheros con logs, históricos, etc etc …

Bueno … con 1.7MB puedo hacer un programa inmenso y me sobra ¿para qué me voy a perder el tiempo leyendo esto?

Es cierto que puedes hacer programas bastante grandes pero va a depender mucho de cómo los hagas y de las herramientas que estés utilizando. Si no estructuras bien tu programa puedes llegar a tener problemas serios de memoria.

Lee el resto de esta entrada »

En muchas aplicaciones con módems GPRS es necesario almacenar datos dentro del propio módem. Ya vimos hace un tiempo cómo crear ficheros dentro de la memoria Flash del módem gprs, trabajando como si fuese una unidad de disco.

¿Que qué tipo de aplicaciones? pues por ejemplo una aplicación podría ser un datalogger, ó un tracker GPS, o cualquier otra aplicación que precise de ir guardando un log (un fichero) con ciertos datos capturados periódicamente. Evidentemente si estamos trabajando con módems GPRS es para transmitir los datos en algún momento. Cuando llegue el momento de transmitir vía GPRS los datos almacenados en el módem a un servidor central, en función del tamaño del fichero de datos que estemos manejando, puede ser bastante interesante comprimir los datos antes del envío.

¿Por qué puede ser interesante comprimir los datos?

Pues básicamente por dos motivos. Uno es por el ahorro de tiempo en el proceso de envío. El otro es por cuestiones económicas, pues, recordemos, en la mayoría de los casos los operadores de telefonía facturan por volumen de tráfico, es decir, cuantos más datos transmitamos más pagaremos.

www.blogElectronica.com

¿Y cómo comprimo ficheros con J2ME?

Pues lo primero que se nos suele ocurrir a todos es empezar buscando si J2ME tiene alguna clase que nos facilite esta tarea. Lametáblemente pronto uno se da cuenta de que no, que J2ME no tiene estas clases debido a sus limitaciones (recordemos que j2me está pensado para dispositivos con poquitos recursos). En cambio J2SE (java standard edition) sí que las tiene. Con la edición completa de java basta con usar el paquete java.util.zip. para gestionar fácilmente la compresión de archivos. Viendo esto último, lo siguiente que a uno se le ocurre es “pues venga, voy a ver si puedo adaptar estas clases de J2SE para intentar que me funcionen en J2ME”. Pero tras unas horas gastadas en el intento uno acaba viendo que no va a ser tarea fácil, pues se utilizan ciertas clases nativas de Zlib.

Así que toca ponerse a investigar alternativas … Poca cosa aparece en Internet googleando acerca de la compresión con J2ME y mucho menos si buscamos algo relacionado con compresión y módems GPRS, así que creo que en este post aterrizarán bastantes navegantes. Bueno, tras buscar un rato, uno llega al proyecto JZLib (en la web http://www.jcraft.com/jzlib/) un proyecto de software libre donde han realizado una re-implementación de ZLIB. Podéis obtener toda la información que queráis de esa web, yo no voy a entrar en detalles.

¿Y funciona? ¿Podemos comprimir archivos dentro del módem usando esa librería?

Pues sí, funciona

A continuación os voy a poner un ejemplito java que funciona en un módem TC65 ó MTX65.  Lo podéis descargar haciendo click aquí. El ejemplo básicamente lo que hace es comprimir el texto:  “en la granja de mi tia iaiaooooooooooooooooooooooooo” y guarda el resultado final, es decir, el texto comprimido, en un fichero (en la memoria flash interna del módem) con el nombre “datos.z”.  Si véis el código fuente del proyecto podéis ver que he puesto todos los archivos .java de la librería de compresión en el mismo proyecto. Obviamente se podría haber utilizado como librería pero para que nadie se me pierda y pueda probar el ejemplo sin dificultad lo dejo así.

¡Funciona!  Me ha comprimido el texto en un archivo. Pero si luego saco el archivo comprimido del módem con el MES y me lo llevo a mi PC no soy capaz de descomprimirlo con el WinZip.

No va a funcionar con WinZip puesto que únicamente se ha creado un fichero con los datos comprimidos, es decir, ZLIB comprime el archivo pero si quieres utilizar el winzip tendrás que construir la estructura de los ficheros ZIP, con sus cabeceras y demás. (http://www.pkware.com/products/enterprise/white_papers/appnote.html).

Uff, que difícil lo de las cabeceras ZIP. ¿No se puede descomprimir de otra forma?

Pues sí, con un descompresor ZLib. Pero eso lo pondré en otro post dentro de unos días (el Domingo seguramente). Intentaré poner un programita hecho en VB6 (con código fuente, por supuesto, para que lo podáis utilizar) que sea capaz de descomprimir los ficheros generados por el módem.  De esa manera tendréis todo lo necesario para poder  comprimir un archivo con el módem, enviarlo vía GPRS y descomprimirlo después en nuestro servidor.

Bueno, espero que os haya interesado el post y que os sea útil algún día, me voy a cenar.

Aquí cuelgo para quien lo necesite la versión 1.1 (beta por el momento) del software OTAP para la actualización remota del software java de los módems gprs Siemens / Cinterion, como comentaba en un post anterior.

Lo podéis descargar haciendo click aquí.

He añadido algunas cositas con respecto a la versión previa 1.0.  Por ejemplo, quien quiera probar/usar la aplicación y no tenga un servidor HTTP para poner sus archivos JAD y JAR le dejo usar mi servidor.  Para ello fijáos en la pantalla principal de la aplicación:
 

 
Arriba, a la derecha, puedes ver un botón “Upload”. Si haces click en el aparerá una pantalla como esta:

 
Aquí basta con que selecciones tu fichero JAD y tu fichero JAR y pulses el botón que indica “Subir archivos”.  Los archivos se subirán automáticamente a:  http://www.otap.es/temp/  y será la ruta (URL Jad) que deberás indicar en la aplicación (como puedes ver en la primera imagen de este post).
 
¿Qué no tienes ahora ningún fichero .JAD y .JAR para probar la aplicación?   No te preocupes, aquí te pongo unos. Cuando te bajes los ficheros abre con el bloc de notas el fichero .JAD y fíjate en la ruta del fichero .JAR, te lo comento para que lo tengas en cuenta cuando generes los tuyos, que la ruta al fichero .JAR debe ser correcta.
 
Espero que te sea útil la aplicación.

Puedes comentar este post en el nuevo Foro (click aquí)

- (6) Posts

Si desarrollas aplicaciones en Java para los módems gprs TC65, XT65 (o sus terminales MTX65 o MTX65+G distribuidos por Matrix), tal vez pueda interesarte en alguna ocasión debugar tu aplicación de la manera que te voy a indicar aquí.

Como ocurre (o debería ocurrir) al final del desarrollo de cualquier programa, hay una fase de test, una fase en el que se debe probar a fondo la aplicación en busca de cualquier tipo de error que hayamos podido cometer. Si lo errores en nuestra aplicación son fácilmente reproducibles los encontraremos de manera relativamente sencilla, pero en ocasiones puede haber errores que se deban a un cúmulo de cosas o debido a unas situaciones muy concretas que no se reproducen en el laboratorio y sí en la calle.

Depurar este tipo de problemas puede llegar a ser realmente complicado, ya que si se producen de forma muy ocasional son difíciles de localizar.

  Lee el resto de esta entrada »

En bastantes ocasiones me ha llegado la pregunta de cómo añadir más datos a un fichero ya existente dentro de la memoria flash de nuestros módems TC65 o XT65 (o de los terminales MTX de Matrix). Por ello hoy voy a poner un pequeño programa java para que ayude a quien no sepa cómo hacer esto. Es muy sencillo.

Básicamente consiste en utilizar el objeto OutputStream en lugar de DataOutputStream (DataOutputStream hereda de OutputStream) que seguro visteis en el post donde tengo la mayoría de los ejemplos java.

Vamos con el ejemplillo de hoy. Vamos a suponer que tenemos un fichero en el sistema de ficheros del módem de nombre “A:/fichero.txt” y con el texto “hola“, por lo que si no lo tienes, crea uno y ponlo dentro del módem.

Lee el resto de esta entrada »