Mensajes

Esto es ya una burbuja... El unico modo de desinflarla, parece ser que cada país vaya asumiendo que debe tener sus propios fabricantes de chips... en vez de delegar siempre a los mismos que son solo un puñado.

... esto no es una crítica al formato, claro, ocurre lo mismo que con los documentos de Microsoft Office, algunas de sus funciones pueden ser empleadas con fines malintencionados, y el principal problema de seguridad pasa por la descarga u obtención...

Pues yo si critico el formato.
Un documento debe ser un objeto estático de datos, lo contrario es una aplicación. Entonces con estos formatos la línea entre documento y aplicación se diluye para ser ambos.
Desde mi punto de vista, lo tengo muy claro. Si un formato no se limita a mantener datos estáticos, es una aplicación. Y ahí, ya como cualquier otra aplicación está sujeta a fallos e intentos de manipulación.

El usuario es inocente desde el momento en que al llamarlo 'documento', confía en que solo mantiene datos y no que se ejecutan 'cosas' dentro de dicho formato. Los creadores de los formatos, no, porque bajo el palabro 'documento' toleran el  engaño que al final pasa factura y de usuario de un documento pasa a ser víctima del formato cuando es atacado.

Habrá quien piense que en vez de atacar al documento se puede por igual atacar a la aplicación que maneja el documento... pero hay claras diferencias. La más importante es que se pueden tener diferentes aplicaciones para abrir ese documento, con lo que se puede asumir que no todas van a tener los mismos problemas al mismo tiempo, una aplicación se puede parchear... pero el fake-documento... queda ahí.

Relee, he editado el mensaje mientras por lo visto respondías.

Sí, un problema de la consola es que el dibujado es a nivel de toda la pantalla. Esa es una de las razones por las que operar con forms es más eficiente, solo se actualiza la parte del gráfico que cambia.
Por otro lado la pantalla tiene dos barridos vertical y horizontal uno es miles de veces por segundo el otro es entre decenas y pocas centenas de veces por segundo (típicamente entre 24 y 120 por sg.).  Pués bien, si eres capaz de redibujar todo el gráfico en ese tiempo, no aparece ningún parpadeo.

Otro modo en que se palia ese efecto, es cuando el sistema dispone de un backbuffer (una memoria adicional donde vas dibujando, tarde lo que tarde, y cuando está listo se dibuja de un plumazo entero)... el peor caso es cuando se va dibujando en tiempo real, pixel a pixel, que es muy lento...
Lo cierto es que incluso aquellos antiguos monitores CRT en BN o 256 colores solían tener entre 2 y 8 páginas de vídeo, que uno podía dibujar antes de presentarla, no entiendo porqué Mocosoft, no ha provisto al menos un backbuffer adicional para la consola que luego con un simple Console.Flush o Console.Draw realizara el intercambio entre ambas páginas, incluso con un Raster Op. para dibujar (incorporar al dibujo) solo los cambios (por ejemplo).

Esto parece un problema de sincronización.
Hay dos tipos de sincronización. La que refiere al período de refresco, esto es cada vez que el puerto serie manda datos y a la interpretación de datos.
Si sucede que el puerto manda un dato que tu esperas (pongamos 450) y luego lo alterna con el envío de otro dato distinto (pongamos una señal de 'listo', con valor 0) y tu derivas ambos valores tratados como el mismo tienes ese resultado.

Sucede algo parecido cuando tu solicitas datos al puerto serie en vez de dejar que sea el puerto serie quien te los envíe. supongamos que el puerto serie envía una señal cada 200 ms. y tu pones un evento de actualización cada 100 ms. pués una de dos veces obtendrás el valor real y en la otra podrías obtener un valor temporal, si sucede que el dato no está listo, pero el dispositivo sigue funcionando con otros datos.

Es dífícil de determinar el problema exacto, pues requiere documentación del dispositivo y realizar pruebas específicas para determinar que tu programa cumple lo que la documentación señala y que el propio dispositivo también cumple  lo que la propia documentación señala (a veces puede haber un bug en la documentación o se hicieron cambios de última hora que no se refleja en la documentación).

Una de las cosas que puedes hacer es bajar la velocidad de refresco (por ejemplo de 100 a 200ms), y ver si se soluciona ese parpadeo, o por lo menos mejora.
Otra es interponer una propiedad que verifique diferencias entre el valor actual (recibido y el previo) y descartar el cambio si está por encima de cierto umbral... digamos que el dispositivo tiene flucturaciones que no están estabilizadas...

El siguiente pseudocódifgo trata de paliar ese efecto, naturalmente es un punto de partida, tendrás que afinarlo hasta que veas que resulta satisfactorio.
La idea es la siguiente. Partamos del hecho de que un voltaje es x (2'2 por ejemplo) y que la transicion entre ese valor y 0 precisare de 1sg. si resulta que el refresco es cada 100ms. podríamos establecer que la tasa de cambio por refrsco no debería ser mayor (nota que solo es una aproximación teórica) a tc = 2'2 / (1000/10). Es decir en cada refresco el valor no debería cambiar más de 0'22v. respecto del actual...

Código [Seleccionar] Expandir


flotante f_Valor, f_Previo, umbral

Escribe propiedad Voltaje(flotante valor)
   Si (valor <> p_valor)
       flotante tasaCambio = (f_valor/ (1000ms. / intervalorefresco))

       umbral = (valorAbsoluto(f_valor - valor)
        si (umbral <= tasaCambio)         // aceptar el cambio
            f_previo = 0
           f_Valor = valor
           llamada a redibujar
        sino
            // descomentar esta parte si lo previo funciona más o menos bien, pero tiene algunos 'incidentes' desajustados.
            //si (f_previo + umbral) >= tasacambio)   // segundo intento.
            //    f_previo = 0
           //     f_Valor = valor
           //     llamada a redibujar
           // sino
           //     p_previo += umbral
            //fin si       
       fin si
   Si no
       // no cambia nada, para qué redibujar?      
   fin si
fin propiedad

Y eso debería como mímino limitar los picos de transicion entre estados...

Nota que 'tasaCambio' es un valor de umbral que dentro del mismo acepta el cambio y alejado del mismo rechaza el cambio... en el siguiente evento, si la tendencia continúa, señala que es indicador de que el cambio recibido antes puede ser real... entonces se puede añadir una segunda oportunidad de cambio... ojo, te la comento, de entrada, si no funciona bien del todo, entonces descomenta ese código y habría que ponderarlo...

Es más que probable que deba ser afinado, tasaCambio podría ser ponderdado por un factor constante... (mayor o menos que 1) por ejemplo:

Código [Seleccionar] Expandir


   ...
   flotante tasaCambio = ...
   tasaCambio  = (tasaCambio * 1'3)  // <---- conviene ponerlo como constante

Igualmente el intervalo de refresco y el plazo tomado (son válidos si el sistema es fijo, no es válido si no hay eventos a intervalos fijos, en ese caso debe tomarse una media de eventos por minuto (por ejemplo).
Que funcione del todo bien, va a depender de cuanto se aproxime al funcionamiento del dispositivo.

Ya te respondí en el otro lado, aunque este es una ubicación más propicia... me cito:

Es explorer.exe

Amplío aquí la segunda pregunta que haces en otro sitio...

La ventana 'Run', es una ventana de Explorer, aparece cuando se pulsa ciertas combinaciones de teclas, luego no hay forma establecida para que desde Batch, puedas abrirla directamente.

Lo que no quitas que puedas enviar las pulsaciones de teclas con un sendkeys, dentro de cualquier miniprograma cuyo cometido sea precisamente ese y al que tu invocas.

Explorer está abierto por defecto, desde el momento en que aparece el 'desktop. es la ventana 0, las siguientes instancias de explorer abren el arbol de directorios de ficheros.

Las normas prohíben crear multiples mensajes con el mismo tema.

En el otro hilo ya te respondí a la segunda parte (que es lo que preguntabas allí). Amplía la pregunta si necesitas más.

Es explorer.exe


Amplío aquí la segunda pregunta que haces en otro sitio...

La ventana 'Run', es una ventana de Explorer, aparece cuando se pulsa ciertas combinaciones de teclas, luego no hay forma establecida para que desde Batch, puedas abrirla directamente.

Lo que no quitas que puedas enviar las pulsaciones de teclas con un sendkeys, dentro de cualquier miniprograma cuyo cometido sea precisamente ese y al que tu invocas.

La consola no dispone de un objeto 'Font' para poder cambiarlo.
La causa obedece a que esas son propiedades compartidas por todo el sistema (como la fecha, hora, etc...), no es local a tu aplicación, y por ende, es preferible que sea algo que el usuario (el consumidor de su equipo), configure y cambie a su gusto (no al gusto del programador).

Si necesitas personalizar ciertos detalles entonces tira de windows.forms (que para eso está)... ahí es el programador quien 'manda' sobre las ventanas de su aplicación.

Y si pones un tamaño de letra de 200 o la tinta del mismo color que el fondo, es cosa tuya... Esto mismo en la consola, puede dar problemas cuando el usuario abra otra aplicación (que no sea la tuya) que haga uso de la consola y resulte que 'no ve nada', aunque parece estar funcionando bien... o le aparece todo en caracteres chinos o ilegibles.

[el string que quieres convertir a entero de 4 bytes, tiene más bytes que los caben en un int32]

Creo que está bien claro.

Si el error que marca es 'overflow', implica que el string que quieres convertir a entero de 4 bytes, tiene más bytes que los caben en un int32... No hay solucion, más que quitar bytes hasta que no marque overflow, o directamente tomar solo 4 de ellos de la posición que interese, o bien utilizar un int64 (tendrás el mismo problemas si el string supera los 8 bytes).

Antes de preguntar, por que no haces un 'trace' del error?. Con un simple messagebox.show(recibidos) podrías llegar a ver el contenido de dicho string (si tiene caracteres no imprimibles, presenta el valor de los bytes. Es más ejecutando paso a paso, párate en el string 'recibidos', posiciona el cursor y espera un instante, el 'intellisense', mostrará el valor del string.

Para los errores léxicos o sintácticos, tienes que recurrir al lenguaje. Esto es pulsa F2, y localizas el objeto y método que marca el error (en este caso int 32, o mejor Convert), en la descricpión del mismo aparecerán los posibles errores que pueden darse y la causa del problema. En cualquier caso todos esos errores, debiera uno resolverlos con el IDE o la ayuda en linea (si no está instalada localmente en el equipo), de la pagina de Mocosoft... O bien con libros que explican bien.

Las preguntas que cabe hacer son las semánticas... esto es, cuando quieres hacer una cosa y 'te sale' otra o no te sale nada... o uno no tiene idea de por dondede tirar, o uno tiene demasiadas ideas por donde tirar, pero no tiene claro cual sería preferible. Este tipo de problemas no suelen resolverse con consultas a la ayuda (aunque algún código de ejemplo puede que sí ayude, si se llega a dar con el adecuado que coincida exactamente con tu caso) o al manual del programador...

Yo creo que más que 'velociraptor', es un 'vecinotontor', disfrazado para la ocasión (por ser de noche, si fuera de día se podría asumir que fuera la 'mascota' de algún equipo de algún deporte)...