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.
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 (12.01 KiB) Visto 881 veces
- rick.jpg (9.49 KiB) Visto 881 veces
- gorgonitas.jpeg (8.23 KiB) Visto 881 veces
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 (4.56 KiB) Visto 881 veces
) 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. 