Creo que no es necesario entrar en profundidad en el tema.

El concepto de polo, tiene que ver con lo que se conoce como 'diferencia de potencial'. Habrá polos muy marcados tanto más cuanto más diferencia exista.

Un modelo simple de entenderlo son los 'vasos comunicantes', imagina varios tubos de vidrio con agua conectados entre si pero con alguna llave de paso. Tienen agua o no tienen, si tienen ejercen una presión... podemos considerar un polo positivo y otro negativo, en cuanto consideramos dos diferentes presiones en la columna de agua en dos tubos. Cuando abras la llave de paso, el caudal del que tiene más presión, manará hacia el tubo que tiene menos presión, hasta que se equilibren...
La electricidad funciona igual que el símil hidraúlico, pero el magnetismo tienen ligeras diferencias... un imán mantiene su magenitsmo durante miles de años (no se equlibra al instante).

Todavía, es fácil ver la equivalencia de la polaridad de un imán con el sistema hidráulico. Imagina un imán de 100cm. de largo, a un lado el positivo al otro el negativo. En el centro (aproximadamente) hay un valor de carga neutro. Si ahora cortas el imán, por la mitad, no tienes 2 imanes tal que la primera mitad tenga un polo positivo y un neutro y el otro trozo un polo neutro y el otro negativo... tienes dos nuevos imanes con sus polos positivos y negativos. Precisamente por lo que el símil hidráulico demuestra, la diferencia de presión establece los polos.
No importa cuantas veces partas el imán en dos, siempre habrá dos extremos (esto me recuerda a menudo la Hidra de la mitología griega, donde se decía de ella, que cada vez que le cortabas la cabeza a una, aparecían 2 más, cabe preguntarse si no hablaran en sentido físico sino en sentido figurado).

Entiende así como polos, la diferencia medida en dos puntos y no necesariamente que algo sea 'negativo o positivo', si no uno más positivo que otro o uno más negativo que otro.
Comparando por ejemplo la electronegatividad de los materiales, si pones en contacto un ácido con cobre y plomo, se oxidará el plomo, pero si sustituyes el plomo por oro, quien se oxida ahora es el cobre. El fenómenos sucede porque uno es más electronegativo que otro, no porque uno sea 'positivo' y otro negativo'... estos son conceptos que ayudan mucho a entender el problema, pero a entender lo que sucede en un instante dado (donde hay unas condiciones puntuales). Así la corriente (el movimiento de electrones), circulará de un metal a otro, entonces positivo o negativo, definen el flujo, el sentido de circulación de los electrones... pero persé, un metal no es positivo o negativo (aunque existe como digo la propiedad de electronegatividad), dicho estado (positivo/negativo) aparece cuando colocas otro material diferente, con propiedades distintas por eso uno puede ser el polo positivo en una ocasión y negativo en otras circunstancias. No sé si alcanzo a tratar de dejarte claro el asunto.

De todos modos, la gravedad y por ende el magnetismo, no terminamos de comprenderlo por completo, aún quedan lagunas.

En cuanto al palabro 'el magnetismo no es una fuerza que se ejerce sino una interaccion entre bosones', digo yo, que si acaso la palabra fuerza, no es lo suficientemente abstracta, como para ser definida como la magnitud de cualquier interacción (sea del tipo que se trate), que tenga sentido querer expresar lo mismo con un cambio de palabras. De otro modo, el palabro 'interacción entre bosones', resulta insuficientemente explicado ni aclaratorio. Fuerza, es genérico, perfectamente válido y quizás lo que debiera 'remplazarse' fuera lo de 'ejerce...' con 'que resulta...' o 'resultante de...'

Revisa las APIs:
Gdipcreatebitmapfromfile, GdipcreateHbitmapfrombitmap y Gdipdisposeimage de la librería Gdiplus.dll

...por la red, debe haber chorrocientos ejemplos de uso.

Cuando sucede que las fluctuaciones de un sistema son elevadas y esto es normal (es decir la causa no es debida a ruido generado en alguna etapa), entonces es más adecuado usar un control tipo búmetro, con escalas verticales (preferible a las horizontales), incluso coloreando distintamente cada bloque o celda en la columna...

Un ejemplo de este caso, son las notas de la música, donde en un instante dado un valor vale 400hz. y al instante siguiente 4000hz.
En casos así, es adecuado 'recordar' el pico, durante un tiempo mayor que el que dura el intervalo del refresco...
Una imagen de ejemplo (aunque aquí se presentan varias columnas):


Dado un valor se cuantiza dentro del bloque supuesto en una serie de divisiones.
En vez de borrar y redibujar el gráfico entero, es preferible dibujar solo lo que cambia.
Por ejemplo imagina que hay una sola columna (es extensible a más columnas como muestra la imagen, pero para explicaciones es más fácil atenerse a solo una).

Para darle cierta concrección al código, considera estos datos: el rango de valores 0-255, 8 bloques en la columna, el valor actual 203 y el previo 85

En este enlace tienes bastante por revisar y orientarte...

https://foro.elhacker.net/abril_negro/abril_negro_spok_simple_production_of_keys-t468239.0.html

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.

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...

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:
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:


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.