<?xml version="1.0" encoding="ISO-8859-1"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Uso correcto de la Flash de los módems Cinterion TC65 y XT65</title>
	<atom:link href="http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/</link>
	<description>Blog personal sobre alta tecnología y dispositivos electrónicos avanzados</description>
	<pubDate>Wed, 10 Mar 2010 08:55:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tobias</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-14988</link>
		<dc:creator>Tobias</dc:creator>
		<pubDate>Wed, 28 Oct 2009 17:43:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-14988</guid>
		<description>Buenas tardes! 
Soy brasileño .... 
Artículo muy bueno, pero tiene una duda, este mismo procedimiento puede ser 
hacer uso de RMS, que ya tiene un índice. Si es posible tener un montón de cambios 
la filosofía de desarrollo más allá de las específicas para trabajar con RMS</description>
		<content:encoded><![CDATA[<p>Buenas tardes!<br />
Soy brasileño &#8230;.<br />
Artículo muy bueno, pero tiene una duda, este mismo procedimiento puede ser<br />
hacer uso de RMS, que ya tiene un índice. Si es posible tener un montón de cambios<br />
la filosofía de desarrollo más allá de las específicas para trabajar con RMS</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blogElectronica</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-12826</link>
		<dc:creator>blogElectronica</dc:creator>
		<pubDate>Sun, 23 Aug 2009 17:58:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-12826</guid>
		<description>Hola Pablo,

sinceramente no lo se. No se a nivel físico qué es lo que hace el método truncate con la memoria. Si lo averiguo te cuento.

Salu2.</description>
		<content:encoded><![CDATA[<p>Hola Pablo,</p>
<p>sinceramente no lo se. No se a nivel físico qué es lo que hace el método truncate con la memoria. Si lo averiguo te cuento.</p>
<p>Salu2.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pablo</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-12330</link>
		<dc:creator>Pablo</dc:creator>
		<pubDate>Thu, 06 Aug 2009 15:45:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-12330</guid>
		<description>Una pregunta, si no borro ninguno de mis ficheros, pero sí que los trunco (función .truncate() ) para que tengan tamaño 0 y vuelvo a escribirlos ¿Es correcto? Técnicamente no los estoy borrando pero no sé si es correcto a nivel físico de la memoria. ¿Es correcto o tendré problemas a la larga?</description>
		<content:encoded><![CDATA[<p>Una pregunta, si no borro ninguno de mis ficheros, pero sí que los trunco (función .truncate() ) para que tengan tamaño 0 y vuelvo a escribirlos ¿Es correcto? Técnicamente no los estoy borrando pero no sé si es correcto a nivel físico de la memoria. ¿Es correcto o tendré problemas a la larga?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blogElectronica</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-10773</link>
		<dc:creator>blogElectronica</dc:creator>
		<pubDate>Tue, 23 Jun 2009 17:37:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-10773</guid>
		<description>Hola Ulises,

no veo ningún problema al uso de RecordStore.

Salu2.</description>
		<content:encoded><![CDATA[<p>Hola Ulises,</p>
<p>no veo ningún problema al uso de RecordStore.</p>
<p>Salu2.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ulises</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-10537</link>
		<dc:creator>Ulises</dc:creator>
		<pubDate>Thu, 18 Jun 2009 12:35:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-10537</guid>
		<description>Hola Blog, yo estoy usando la clase RecordStore  y quiero saber si me conviene seguir usando esta Mini Base de Datos en mi aplicacion. Yo tb voy creando, agregando, modifiando y eliminando registros, y viene funcionando muy bien.
Que me aconcejas?</description>
		<content:encoded><![CDATA[<p>Hola Blog, yo estoy usando la clase RecordStore  y quiero saber si me conviene seguir usando esta Mini Base de Datos en mi aplicacion. Yo tb voy creando, agregando, modifiando y eliminando registros, y viene funcionando muy bien.<br />
Que me aconcejas?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blogElectronica</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-10183</link>
		<dc:creator>blogElectronica</dc:creator>
		<pubDate>Thu, 11 Jun 2009 19:04:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-10183</guid>
		<description>Hola aldanajaramillo,

cuando hablo de machacar en ningún sitio estoy hablando de sobreescribir físicamente una posición de memoria interna de la flash, entre otras cosas, porque desde java no puedo especificar usar una determinada posición de memoria concreta dentro del FFS, de eso se encargan los algoritmos internos del módem.

Cuando hablo de machacar me refiero a los registros del archivo, no a posiciones de memoria concretas. ¿Si no porqué ahí arriba digo que el borrado se hace por sectores de 64KB? ¿Qué sentido tendría poder borrar si pudiese sobreescribir un único byte físico con 0xFF?  Por otro lado te puedo decir que cuenta con algoritmos para escribir de forma homogénea toda la memoria, supongo que es lo que tú llamas desgaste parejo.

La estrategia de machacar los registros dentro de un archivo en el FFS no lo digo porque sí. Por mi trabajo estoy directamente relacionado con el personal técnico de M2M de Siemens / Cinterion, con quien trato bastante a menudo, y son ellos quienes recomiendan esa esta técnica de sobreescribir registros en ficheros en lugar de borrar ficheros y crear nuevos y te aseguro que ahorra problemas. Lo veo cada día entre quienes usan una técnica u otra, pero bueno, cada uno es libre de utilizar las técnicas que quiera, por supuesto.

Salu2.</description>
		<content:encoded><![CDATA[<p>Hola aldanajaramillo,</p>
<p>cuando hablo de machacar en ningún sitio estoy hablando de sobreescribir físicamente una posición de memoria interna de la flash, entre otras cosas, porque desde java no puedo especificar usar una determinada posición de memoria concreta dentro del FFS, de eso se encargan los algoritmos internos del módem.</p>
<p>Cuando hablo de machacar me refiero a los registros del archivo, no a posiciones de memoria concretas. ¿Si no porqué ahí arriba digo que el borrado se hace por sectores de 64KB? ¿Qué sentido tendría poder borrar si pudiese sobreescribir un único byte físico con 0xFF?  Por otro lado te puedo decir que cuenta con algoritmos para escribir de forma homogénea toda la memoria, supongo que es lo que tú llamas desgaste parejo.</p>
<p>La estrategia de machacar los registros dentro de un archivo en el FFS no lo digo porque sí. Por mi trabajo estoy directamente relacionado con el personal técnico de M2M de Siemens / Cinterion, con quien trato bastante a menudo, y son ellos quienes recomiendan esa esta técnica de sobreescribir registros en ficheros en lugar de borrar ficheros y crear nuevos y te aseguro que ahorra problemas. Lo veo cada día entre quienes usan una técnica u otra, pero bueno, cada uno es libre de utilizar las técnicas que quiera, por supuesto.</p>
<p>Salu2.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: aldanajaramillo</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-10171</link>
		<dc:creator>aldanajaramillo</dc:creator>
		<pubDate>Thu, 11 Jun 2009 14:43:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-10171</guid>
		<description>Lo que se debe hacer si se necesita implementar una especie de backlog GPS o alguna otra funcionalidad en la que se deban almacenar datos temporalmente en flash mientras estos son utilizados es implementar un algoritmo de desgaste parejo para nuestra memoria flash. Averiguen bien porque me supongo que los Cinterion deben tener dicho algoritmo ya implementado y sino en la red se encuentra info acerca del tema de desgaste parejo.

Si quieren saber si el modem tiene dicha funcionalidad de desgaste parejo implementada deben hacer la sgte prueba. Cojan un modem nuevo y hagan un sencillo programa que en un ciclo infinito coja y escriba en una posición de memoria un número de un contador, luego lo lea, si hay match incrementa el contador y de nuevo empieza a guardar y así sucesivamente. Cuando no haya match, si el contador empezó en 0 entonces el último valor del contador que se almacenó equivale al número de veces que se logró sobreescribir la misma posición de memoria flash. Esta prueba se les va demorar por ahí 1 mes si el modem tiene desgaste parejo así que cuando hagan el programita tengan en cuenta que el modem podrá reiniciarse durante la prueba (el contador no debe empezar en 0 cada vez que el modem se reinicie, se debe cargar de flash el último valor escrito y arrancar con el valor leido).

Sí el número es mucho mayor a 100.000 (he obtenido valores de 40.000.000) significa que el modem tiene algoritmos de desgaste parejo para su memoria flash. Si éste es el caso ese modem ya ha quedado con TODA su memoria flash mala o gastada.

Yo he hecho la anterior prueba para varias marcas de modem y en todos he logrado escribir y leer un bloque de memoria de 30KBytes más de 20.000.000 de veces (veinte millones de veces).

Saludos.</description>
		<content:encoded><![CDATA[<p>Lo que se debe hacer si se necesita implementar una especie de backlog GPS o alguna otra funcionalidad en la que se deban almacenar datos temporalmente en flash mientras estos son utilizados es implementar un algoritmo de desgaste parejo para nuestra memoria flash. Averiguen bien porque me supongo que los Cinterion deben tener dicho algoritmo ya implementado y sino en la red se encuentra info acerca del tema de desgaste parejo.</p>
<p>Si quieren saber si el modem tiene dicha funcionalidad de desgaste parejo implementada deben hacer la sgte prueba. Cojan un modem nuevo y hagan un sencillo programa que en un ciclo infinito coja y escriba en una posición de memoria un número de un contador, luego lo lea, si hay match incrementa el contador y de nuevo empieza a guardar y así sucesivamente. Cuando no haya match, si el contador empezó en 0 entonces el último valor del contador que se almacenó equivale al número de veces que se logró sobreescribir la misma posición de memoria flash. Esta prueba se les va demorar por ahí 1 mes si el modem tiene desgaste parejo así que cuando hagan el programita tengan en cuenta que el modem podrá reiniciarse durante la prueba (el contador no debe empezar en 0 cada vez que el modem se reinicie, se debe cargar de flash el último valor escrito y arrancar con el valor leido).</p>
<p>Sí el número es mucho mayor a 100.000 (he obtenido valores de 40.000.000) significa que el modem tiene algoritmos de desgaste parejo para su memoria flash. Si éste es el caso ese modem ya ha quedado con TODA su memoria flash mala o gastada.</p>
<p>Yo he hecho la anterior prueba para varias marcas de modem y en todos he logrado escribir y leer un bloque de memoria de 30KBytes más de 20.000.000 de veces (veinte millones de veces).</p>
<p>Saludos.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: aldanajaramillo</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-10168</link>
		<dc:creator>aldanajaramillo</dc:creator>
		<pubDate>Thu, 11 Jun 2009 14:24:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-10168</guid>
		<description>Hola,

Según tengo entendido cuando uno escribe en una memoria flash lo que se hace es cambiar el estado de los bits que están en 1 y ponerlos a 0. (los bits que antes estaban en 1 y que luego de la escritura  siguen en 1 no se tocan).

Ej. Posición de memoria 0x100 que está en blanco osea libre para escribir. Sí está en  blanco el valor de la posición asumiendo una arquitectura de 8 bits sería 0xFF (0b11111111). Si en esa posición yo escribo el valor 0x30(0b00110000) lo que se hace es cambiar el estado de los bits 0,1,2,3,6 y 7 a 0. Estos bits que se han cambiado a estado 0 NO podrán ser modificados nuevamente hasta que se realice una operación de borrado sobre esa posición de memoria. Así que lo de sobreescribir la posición de memoria flash sin haberla borrado antes si es posible pero el valor que quedará almacenado no es el deseado. De modo que de acuerdo a lo anterior y según mis conocimientos la recomendación de MACHUCAR que dan acá no es muy válida que digamos.

Saludos,</description>
		<content:encoded><![CDATA[<p>Hola,</p>
<p>Según tengo entendido cuando uno escribe en una memoria flash lo que se hace es cambiar el estado de los bits que están en 1 y ponerlos a 0. (los bits que antes estaban en 1 y que luego de la escritura  siguen en 1 no se tocan).</p>
<p>Ej. Posición de memoria 0&#215;100 que está en blanco osea libre para escribir. Sí está en  blanco el valor de la posición asumiendo una arquitectura de 8 bits sería 0xFF (0b11111111). Si en esa posición yo escribo el valor 0&#215;30(0b00110000) lo que se hace es cambiar el estado de los bits 0,1,2,3,6 y 7 a 0. Estos bits que se han cambiado a estado 0 NO podrán ser modificados nuevamente hasta que se realice una operación de borrado sobre esa posición de memoria. Así que lo de sobreescribir la posición de memoria flash sin haberla borrado antes si es posible pero el valor que quedará almacenado no es el deseado. De modo que de acuerdo a lo anterior y según mis conocimientos la recomendación de MACHUCAR que dan acá no es muy válida que digamos.</p>
<p>Saludos,</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Miguel</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-9575</link>
		<dc:creator>Miguel</dc:creator>
		<pubDate>Fri, 22 May 2009 10:07:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-9575</guid>
		<description>Hola.

Sobre el tema hay algo a lo que estoy dándole vueltas ... con la escritura afectas a los bytes que escribes PERO será de una forma mucho más continuada y en las mismas posiciones -&#62; llevará a un degradado mucho más rápido de esas posiciones.

El problema es que se tendría que implementar un mecanismo de comprobación (grabas la información, la lees para verificar que esas posiciones siguen siendo válidas, ... si no son válidas a crear otro fichero y vuelta a empezar).

Por supuesto SALVO que se disponga de un controlador de "posiciones defectuosas".

Saludos y gracias por la respuesta.</description>
		<content:encoded><![CDATA[<p>Hola.</p>
<p>Sobre el tema hay algo a lo que estoy dándole vueltas &#8230; con la escritura afectas a los bytes que escribes PERO será de una forma mucho más continuada y en las mismas posiciones -&gt; llevará a un degradado mucho más rápido de esas posiciones.</p>
<p>El problema es que se tendría que implementar un mecanismo de comprobación (grabas la información, la lees para verificar que esas posiciones siguen siendo válidas, &#8230; si no son válidas a crear otro fichero y vuelta a empezar).</p>
<p>Por supuesto SALVO que se disponga de un controlador de &#8220;posiciones defectuosas&#8221;.</p>
<p>Saludos y gracias por la respuesta.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blogElectronica</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-9563</link>
		<dc:creator>blogElectronica</dc:creator>
		<pubDate>Thu, 21 May 2009 18:28:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-9563</guid>
		<description>Hola Miguel,

efectivamente es distinto la grabación que el borrado por el tipo de memoria.  Castigas mucho más con el borrado que con la escritura. Con la escritura sólo afectas a los bytes que escribes, con cada borrado afectas a 64KB.

Salu2.</description>
		<content:encoded><![CDATA[<p>Hola Miguel,</p>
<p>efectivamente es distinto la grabación que el borrado por el tipo de memoria.  Castigas mucho más con el borrado que con la escritura. Con la escritura sólo afectas a los bytes que escribes, con cada borrado afectas a 64KB.</p>
<p>Salu2.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Miguel</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-9562</link>
		<dc:creator>Miguel</dc:creator>
		<pubDate>Thu, 21 May 2009 17:34:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-9562</guid>
		<description>Perdón ... se me olvidó ...

Si los registros no tienen tamaño constante, la solución existe pero es más complicada (almacenar para cada registro su tamaño, meter separadores, ...).

Saludos.</description>
		<content:encoded><![CDATA[<p>Perdón &#8230; se me olvidó &#8230;</p>
<p>Si los registros no tienen tamaño constante, la solución existe pero es más complicada (almacenar para cada registro su tamaño, meter separadores, &#8230;).</p>
<p>Saludos.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Miguel</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-9561</link>
		<dc:creator>Miguel</dc:creator>
		<pubDate>Thu, 21 May 2009 17:33:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-9561</guid>
		<description>Hola.

Buen post ... que nos llama la atención sobre el tema que existe aunque pensemos que no nos afecta.

Mi solución pasó por retardar el tiempo lo máximo posible (30-60 minutos) y "confiar" en que los dioses sean "magnánimos".

Para (Pedro) poder escribir en una posición aleatoria del fichero puede valer este código (ojo que no lo he probado, pues escribo al final del fichero):

com.siemens.icm.io.file.FileConnection fichero= (com.siemens.icm.io.file.FileConnection) javax.microedition.io.Connector.open(rutaFichero);
java.io.DataOutputStream dos= new java.io.DataOutputStream(fichero.openOutputStream(posicionDondeEscribir));
dos.objDataOutputStream.write( datos, inicio, tamano);

La solución que se podría dar es:
- Crear un fichero con X*ctd registros máximos a almacenar.
- En otro fichero almacenar el puntero del primer y último registro (como una lista circular). Estos datos habría que actualizarlos para cada operación.

Yo no empleé esta solución pues pensé que también castigaría la memoria Flash para cada una de las actualizaciones. Según entiendo del artículo esto no es así ¿VERDAD?, el daño viene por el borrado y no por el sobreescribir los datos.

Saludos.</description>
		<content:encoded><![CDATA[<p>Hola.</p>
<p>Buen post &#8230; que nos llama la atención sobre el tema que existe aunque pensemos que no nos afecta.</p>
<p>Mi solución pasó por retardar el tiempo lo máximo posible (30-60 minutos) y &#8220;confiar&#8221; en que los dioses sean &#8220;magnánimos&#8221;.</p>
<p>Para (Pedro) poder escribir en una posición aleatoria del fichero puede valer este código (ojo que no lo he probado, pues escribo al final del fichero):</p>
<p>com.siemens.icm.io.file.FileConnection fichero= (com.siemens.icm.io.file.FileConnection) javax.microedition.io.Connector.open(rutaFichero);<br />
java.io.DataOutputStream dos= new java.io.DataOutputStream(fichero.openOutputStream(posicionDondeEscribir));<br />
dos.objDataOutputStream.write( datos, inicio, tamano);</p>
<p>La solución que se podría dar es:<br />
- Crear un fichero con X*ctd registros máximos a almacenar.<br />
- En otro fichero almacenar el puntero del primer y último registro (como una lista circular). Estos datos habría que actualizarlos para cada operación.</p>
<p>Yo no empleé esta solución pues pensé que también castigaría la memoria Flash para cada una de las actualizaciones. Según entiendo del artículo esto no es así ¿VERDAD?, el daño viene por el borrado y no por el sobreescribir los datos.</p>
<p>Saludos.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pedro</title>
		<link>http://www.blogElectronica.com/cinterion-ficheros-java-flash-tc65-xt65/#comment-9554</link>
		<dc:creator>pedro</dc:creator>
		<pubDate>Thu, 21 May 2009 07:26:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.blogElectronica.com/?p=468#comment-9554</guid>
		<description>Buen post, es algo que si no lo tienes en cuenta luego te llevas sorpresas desagradables.

Tengo dos preguntas, a ver si me puedes guiar con ellas:
- Cuando escribo en un fichero puedo hacerlo de dos maneras: o escribo desde el principio o añado al final. Cómo se hace para escribir directamente sobre el registro X?
- Cómo controlas que tienes 5000 registros en un fichero?</description>
		<content:encoded><![CDATA[<p>Buen post, es algo que si no lo tienes en cuenta luego te llevas sorpresas desagradables.</p>
<p>Tengo dos preguntas, a ver si me puedes guiar con ellas:<br />
- Cuando escribo en un fichero puedo hacerlo de dos maneras: o escribo desde el principio o añado al final. Cómo se hace para escribir directamente sobre el registro X?<br />
- Cómo controlas que tienes 5000 registros en un fichero?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
