Imagen

Fatware en los sistemas embebidos?

Responder
Avatar de Usuario
ackerman
Mensajes: 525
Registrado: 05 Feb 2019 21:32
Ubicación: Asturias
Contactar:

Fatware en los sistemas embebidos?

Mensaje por ackerman »

Existe un hilo muy interesante, ya tratado hace tiempo sobre el fatware en plataformas grandonas:

https://retrowiki.es/viewtopic.php?t=200034233

Se estan repitiendo patrones idénticos, pero en sistemas embebidos. Esto va a quedar bastante ladrillo, pero la idea es que se comente sobre ello.
 ! Mensaje de: ackerman
ladrillo.gif
ladrillo.gif (2.67 KiB) Visto 882 veces
Espressif da una vida útil a sus productos de 10 años, y en casos como el 8266, a 12 sin problemas:

https://www.espressif.com/en/products/longevity-commitment
vidaESP32.gif
vidaESP32.gif (12.01 KiB) Visto 882 veces
El ESP32, la familia S, que es la que se usa sobre todo para los emulatas, ya data del 2016, es decir, que a fecha actual del 2023, ya tiene casi 8 años, es decir, está en la etapa final, y se debería tener un conocimiento total y absoluto sobre la plataforma, como si fuera el pic 16F88, vamos, lo que viene siendo un sota, caballo, rey de toda la vida. ¿Será esto cierto?
rick.jpg
rick.jpg (9.49 KiB) Visto 882 veces
Lo que se va a tratar aquí no sólo es aplicable al ESP32, el RP2040 (raspberry pi pico) no se queda corto, la fundación lo ha usado como caballo de Troya con frases como "poder llegar al mayor número de plataformas", y luego va y decide no dar soporte USB en Windows 7 64 bits, porque según ellos, lo consideran deprecated, y se quedan tan anchos. Lo siguiente será sólo dar soporte para desarrollar por usb en una SONY Play 5 por USB, pero luego sacar pecho palomo, de que es 100% multiplataforma. La realidad es que siguiendo el algoritmo ratini, no quieren pagar los royalties del driver usb, pero es que ni se molestan en hacer el unnoficial, en pleno 2023.
gorgonitas.jpeg
gorgonitas.jpeg (8.23 KiB) Visto 882 veces
Resumo todo, en una sacada de colores, es decir, mostrar al mundo las vergüenzas, no para una crítica destructiva, sino para que cuando alguien se pongo a ello, sepa lo que existe y por donde debe ir.
Cuando algo sale nuevo, no se puede atacar directamente ante cualquier posible fallo, es decir, hay que darle el margen de la duda, y la posibilidad del arreglo del mismo, con el tiempo. ESPRESSIF ha sacado demasiados frameworks, demasiadas librerías, demasiadas dependencias, demasiadas deprecated, incompatibilidades, etc..., en demasiado poco tiempo.

He visto proyectos, que nada tienen que ver con emuladores, en los que los desarrolladores tienen que poner a calzador todo detallado lo que se necesita, pero es que llega el momento, en que directamente deciden dar por deprecated una librería o un framework que habían propuesto que lo arreglarían. Lo que hacen los desarrolladores ante este problema, al igual que el mundo PC, pues crean tickets a ESPRESSIF para que lo arreglen. Ellos dan largas o dicen que lo arreglan en versión siguiente. El desarrollador o el usuario creen que eso es lo correcto,pero no se dan cuenta, que si se está desarrollando en una versión anterior, luego tiene que volver a pasar todo el proyecto sobre la que se va a arreglar, que muchas veces, va a tener hasta incompatibilidades.

Existen problemas de memoryleak, de pila, de core's, de temporizadores, vamos de todo. La pseudo FPU, con el cambio de contexto también falla, que ocurre en ISR's y en hilos de core's cuando se saturan. Soluciones, usar double en lugar de float, que salvo casos excepcionales, usaría CPU, es decir, más lento. Todo lo que sea cambio de contexto por sobrecarga, o uso de módulos con saturación desde hilos, problemas. Si se mira el código, por eso está plagado de semáforos y rarezas de módulos a dolor, porque quiere abarcar mucho y muchas familias.

Si se tiene acotado el problema, ¿lo correcto no sería aprovechar todo el potencial como programador para pasar en cantidad de ESPRESSIF?, es decir, si existe problemas con la FPU, pues mejor usar coma fija o enteros. Si existe problemas con el DAC interno, pues a usarlo a pelo como hice yo, o directamente, usar un DAC pasivo R2R de toda la vida por I2s o por GPIO digital. Y así con el resto de cosas, o sea, ir a lo seguro, y ya que se aclaren ellos cuando se centren.

https://github.com/rpsubc8/ESP32wavdac

Cada vez que sacan un framework versión nueva, hay que mirar si han cambiado alguna rareza. No es normal reinventar la rueda todo el rato (día de la marmota), sin añadir nada, es decir, que con lo que acabo de comentar, muchas veces en años no se debería cambiar el código de un proyecto si no se ha añadido funcionalidad. ¿Tiene sentido que una tesis que se hizo en un formato texto hace 10 años, cada año se tiene que volver a reescribir, porque los que definen el formato no saben donde les sopla el aire?

Y PLATFORMIO? dependencias del propio Visual Studio Code, dependencias de python, dependencias de framework, etc... que llega un momento que siempre hay una incompatibilidad. Si se quiere estar todos los días creando tickets:
mando.jpg
mando.jpg (4.56 KiB) Visto 882 veces
GXY
Mensajes: 362
Registrado: 21 Ago 2023 15:06

Re: Fatware en los sistemas embebidos?

Mensaje por GXY »

hay tres problemas principales que generan el "fatware"

1.- el desarrollo de hardware es constante (podemos discutir su utilidad y si el 90% es copia-pega de lo anterior), pero lo cierto es que cada 1.5~2 años, tienes hardware nuevo DE LO QUE SEA. hardware que por supuesto, el fabricante quiere vender.

si optimizamos el software para que funcione DPM en el hardware de hace 10 años para que ·"%$·" queremos HW nuevo¿?

2.- todo desarrollo se basa en el trabajo de las personas. y el trabajo de las personas el 90% del tiempo es "haz que funcione, hazlo YA y hazlo por menos dinero que el de al lado".

si tienes 1000 programadores haciendo software (o ingenieros haciendo hardware) bajo esas premisas, no van a hacer excelencia, van a hacer lo que se les ha pedido "que funcione, que funcione YA y al coste X" y efectivamente, el 90% de ese desarrollo sera una absoluta basura.

yo no soy programador (ni ganas, gracias. valoro mucho mi salud mental). soy tecnico de sistemas y un poquito de redes, es lo que he hecho (con pausas) durante años, es lo que aprendi y es lo que se me da bien. actualmente el >90% de mi trabajo es mantenimiento en una plataforma de "robotizacion" de procesos administrativos que desde el punto de vista del codigo es una absoluta basura. el "codigo" es literalmente un organigrama con cajitas (blueprism, por si alguien lo conoce :roll: ) pero resulta que resuelve los problemas y resulta que permite procesar 10 veces mas expedientes en el mismo tiempo que los humanos asignados a la misma tarea (usando la mitad de maquinas de ejecucion que de humanos), con lo cual, operativamente (costes) es un exito, aunque el codigo sea una completa basura.

3.- el objetivo de desarrollar el codigo (en productos comerciales) no es la excelencia del producto final. ES VENDERLO. por tanto la premisa es que el cliente lo compre, no que sea excelente para que refresque en 0.3s en vez de en 3s. si - aunque se queje - al cliente (comprador) le parece aceptable, champan. si encima se ha hecho "mas o menos" dentro de presupuesto (contando con que los presupuestos en desarrollo tienden a ser como los presupuestos en el dentista o los del albañil -> crecen un 50~100% en tiempo y un 100~200% en dinero cuando se meten en faena)... doble champan... y al siguiente, que la maquinaria de que el jefe se pueda comprar el proximo cochecito no se paga sola. :roll:

no se como sera exactamente en ESP que ademas por ser una plataforma confinada se entiende que deberia ser mas critico el ser optimo, pero dudo que los 3 puntos indicados no se cumplan, cuando basicamente, se cumplen en cualquier ambito tecnologico, no solo "ahora", hace 50 años, tambien.

un ejemplo del texto que enlazan en el hilo anterior. para pensar, señores:
Tengo un programa en Python que ejecuto todos los días, tarda 1.5 segundos. Duré 6 horas re-escribiendolo en Rust, ahora solo tarda 0.06 segundos. Esa mejora en la eficiencia significa que voy a recuperar mi tiempo invertido en 41 años y 24 días :-)
y eso, en el ambito del desarrollo, es una maxima: el tiempo del programador, aunque sea un indio que cobra 400 rupias, o un "pica-teclas" español "junior", es mas caro que el tiempo de computacion. y mas aun cuando hemos estado 4+ decadas duplicando la potencia de procesamiento cada 5 años. En otras palabras: no vale la pena invertir (y sobre todo, pagar) 6 horas de desarrollo para disminuir un proceso de tiempo 1.44 segundos por ejecucion... cuando de todos modos el 99% de esos 1.44 segundos de ejecucion, son tiempo que esta pagado igual sea efectivo o sea el usuario tomando café.

en otras palabras: el software es bloatware ineficiente, y se considera tolerable, porque la evolucion tecnologica del hardware lo hace tolerable (y de hecho lo exacerba, pero eso es otra cuestion) y porque tanto el hardware como el software esta hecho para ser vendido sabiendo que completa la tarea, no porque sea excelente en lo que hace.

por eso para buscar buenos ejemplos de software bien hecho de abajo a arriba y que si aprovecha bien el hardware sobre el que esta hecho, el 99% de las veces te tienes que ir a plataformas confinadas (como mucho del software que se hace hoy dia para sistemas antiguos) o ejemplos varios que estan hechos ex profeso asi, que suelen ser academicos o entusiastas... pero no te vas a encontrar hecho asi hoy dia piezas de software grandes (o sin ser grandes, simplemente que haya un objetivo comercial) como puede ser una aplicacion o un juego, menos aun un navegador y menos aun los sistemas operativos. incluso diria que los actuales Linux mayoritarios en entornos de escritorio y de servidor dudo que se escapen de la "quema".

de hecho hace poco estuve trasteando un poquito un windows 11, y comprobe que sigue llevando mucho del mismo "nucleo duro" que llevaba win10, y win7, y winXP y que viene de los tiempos de Windows 2000. simplemente han puesto OTRA manta encima, muy bonita, eso si. pero debajo sigue habiendo codigo de hace 20 años. bueno, tal vez alguno menos, ya que es 64bit y hace 20 años no habia windows de 64bit.

perdon por el tocho y por el "desvio".
Avatar de Usuario
ackerman
Mensajes: 525
Registrado: 05 Feb 2019 21:32
Ubicación: Asturias
Contactar:

Re: Fatware en los sistemas embebidos?

Mensaje por ackerman »

GXY escribió:
Tengo un programa en Python que ejecuto todos los días, tarda 1.5 segundos. Duré 6 horas re-escribiendolo en Rust, ahora solo tarda 0.06 segundos. Esa mejora en la eficiencia significa que voy a recuperar mi tiempo invertido en 41 años y 24 días :-)
Es difícil exponer todo en un simple texto y seguramente con lo que intentas comentar en este caso, tienes toda la razón del mundo, pero este ejemplo en concreto sin una escala de referencia, tal y como lo comentas, no aclara mucho. Si en lugar de reducir en segundos como has hecho, hicieras lo contrario, es decir, un downgrade, por ejemplo, que tardara 30 segundos, seguramente, valdría también igual, porque evidentemente, la escala de tiempo en este caso, da margen suficiente en el tiempo del ser humano. Y si además, aunque tardese más tiempo, pero a cambio, se eliminase por ejemplo componentes, como python o rust, seguramente, interesaría más, porque se ahorrarían recursos de sistema, que se podrían usar para otros procesos. Otra cosa, es que un proceso tarde 1 hora de ejecución, y que sea acumulativo, es decir, que si falla, tarde el doble. 1 hora en escala de tiempo humana es mucho tiempo, y por tanto, cualquier reducción, es importantísima. Lo mismo, si el tiempo de respuesta tiene que ser tiempo real, pues no queda otra que tiempo real, y 1 segundo, por muy rápido que parezca, no es tiempo real. Conocer la escala es fundamental. Pero todo esto es más para el mundo PC, que no es que el fatware esté mal o este bien en PClandia, es que no le queda otra, ya no se puede dar marcha atrás.
Si todos van en dirección contraria en la carretera, ¿qué podemos hacer? , pues lo mismo, que sino, nos matamos. El I+D de las GPU's, de los chipsets, CPU's y demás, con su ventaja competitiva, todo cerrado, no se paga solo, es lo que hay.

Pero estamos hablando de sistemas embebidos, sistemas, que en algunos casos muy concretos interesará o no la latencia, pero en lo que interesa SI o SI, es que ante una entrada, tiene una salida. Si alguien compra un interruptor para una casa, espera, que funcione, o sea, que active o desactive la luz. Si lamentablemente falla, es decir, deja de encender, pues, hombre, fastidia, ya se mirará parámetros como tiempo de vida útil, etc..., pero es que si cuando vas a dar al interruptor, te tira abajo toda la instalación eléctrica o no se, por desfasar, que se abre el grifo de agua, que no tiene nada que ver con una instalación eléctrica, pues se te empieza a quedar una cara, que no se que palabra usar.

Tenemos que tener acotado las posibles salidas con las posibles entradas, y eso, con las MCU's como atmega ya se tenía, no es algo que sea ciencia ficción o que no se pueda alcanzar. Si ya se tiene, ¿a que viene esa forma de tirar pilares para hacer mal las cosas?
En el mundo PC, el hardware evoluciona rápido, pero en sistemas empotrados, aunque va creciendo, no lo hace a ese ritmo, que sigo sin ver Arduinos UNO con 1 giga de RAM, 4 núcleos y a 3 leureles.
Las MCU's, al igual que algunos SOC's, sólo tiene que activar las entradas, las salidas, controlar los timers y demás, y hacerlo bien, para que luego los desarrolladores se peguen con ello, no para que el desarrollador esté solucionando los marrones que tengan junto con las pajas mentales que se han montado los fabricantes y que cada vez que sumes 2 números tengas que custionarse si 1+1=3 o te va a dar una letra como salida porque esten cambiando las reglas todos los días.

En muchas MCU's ya hace tiempo que se han cansado de la situación, y han pasado a SDK's baremetal, es decir, unos kits básicos, sin tanta parafernalia y con cabeceras básicas. Para el caso del ESP32, aún está bastante en pañales, pero va creciendo la cosa, y para casos muy específicos, cumple muy bien. No confundir ejecución baremetal con SDK baremetal.
GXY
Mensajes: 362
Registrado: 21 Ago 2023 15:06

Re: Fatware en los sistemas embebidos?

Mensaje por GXY »

el tema al que iba y que intentaba explicar, es porqué el "fatware", "bloatware", etc "resulta ser aceptable" en nuestro dia a dia, digamos con "ejemplos del mundo real" (del mundo real hasta cierto punto porque todo lo que se ejecute en una maquina nada de eso es "mundo real" per se, aunque los resultados o las acciones puedan afectar al mundo real)

en el ejemplo, lo que se ejemplifica es que "resulta aceptable" que un proceso informatico demore un poco de tiempo que de todos modos es "tiempo inutil" el 99,99% de las veces en cada ejecucion, en comparacion al tiempo y recursos que supone resolverlo, porque ese tiempo y recursos que supone resolverlo, supone unos costes mayores que la perdida que se pretendia resolver.

por supuesto yo estoy de acuerdo en que en el tema que se trata (sistemas embebidos) la eficiencia es esencial y perdidas de tiempo como esas deberian resolverse siempre, asi como evitar cualquier situacion de "estar esperando por la maquina", etc.

el problema, como trataba de exponer, es que el "fatware" que se denuncia, existe como resto de una ecuacion que en muchos parametros, se desea por parte de muchos de quienes participan en ella que sea asi, por motivos comerciales, de "economia de recursos" o los que sean. evidentemente mucho de lo que indique no aplica directamente a los sistemas embebidos en concreto, sino "en plan generico". pero aun asi, generico y todo, hay partes que si tocan, como los ciclos de obsolescencia tecnologica porque el fabricante quiere vender hardware nuevo.
Responder

Volver a “ESP32 TTGO VGA32”