Merci pour cette dépêche intéressante, un peu moins merci au fabricant qui n'a ici même pas assuré le service minimum à la fois côté récupération des données et au niveau design, afin que ce soit rendu plus simple (il aurait par exemple pu réserver une empreinte pour un connecteur afin d'éviter le retrait, avec toujours un risque de dégât, de la mémoire en prévision de récupération des données post-mortem)!
Je suis par contre étonné de voir du zigbee là dedans tant la portée est limitée (compensé par le réseau maillé via les noeuds sur secteur dans un usage domotique, mais pas ici)! Bon, vu la date Lora/Sigfox n'étaient peut-être pas une option.
Pour la structuration des données, surtout au vu de la faible capacité de l'EEPROM, je trouve assez étrange de voir stocké cela sous forme texte: Pour y stocker des données numériques codées sur un octet ASCII, on a un rapport 8 niveau place vs un stockage hexa.
Au moins cela a simplifié la récupération a défaut de coopération du fabricant, mais rien que cet aspect démontre qu'ils n'ont pas été malins: Un exemple classique, c'est les bitstream de contenu de FPGA (qui contiennent la fusemap de la logique programmée) que les outils de génération sortent également sous une forme ASCII de données pourtant à 99.9% numérique.
En embarqué, ou on est souvent contraint par la taille des stockages, il y a ceux qui prennent le marteau pilon de la compression des données pour enfoncer un clou (avec un impact de la décompression sur les temps de démarrage, des librairies de décompression à ajouter...) et ceux qui réfléchissent et passent ces fichiers bitstream dans une moulinette simple qui convertit ascii->hexa et gagnent un facteur 8 sur les données simplement (et sans impact temps de boot au chargement du FPGA ni ajout de librairies de décompression).
A l'avenir, surtout vu le prix de ces joujous, il faudrait à mon sens ajouter quelques obligations au cahier des charges tenant compte de cette expérience!
# Fabricant...
Posté par lym . En réponse au journal Sauver des données embarquée à dos d'outarde. Évalué à 2. Dernière modification le 12 mai 2025 à 09:11.
Merci pour cette dépêche intéressante, un peu moins merci au fabricant qui n'a ici même pas assuré le service minimum à la fois côté récupération des données et au niveau design, afin que ce soit rendu plus simple (il aurait par exemple pu réserver une empreinte pour un connecteur afin d'éviter le retrait, avec toujours un risque de dégât, de la mémoire en prévision de récupération des données post-mortem)!
Je suis par contre étonné de voir du zigbee là dedans tant la portée est limitée (compensé par le réseau maillé via les noeuds sur secteur dans un usage domotique, mais pas ici)! Bon, vu la date Lora/Sigfox n'étaient peut-être pas une option.
Pour la structuration des données, surtout au vu de la faible capacité de l'EEPROM, je trouve assez étrange de voir stocké cela sous forme texte: Pour y stocker des données numériques codées sur un octet ASCII, on a un rapport 8 niveau place vs un stockage hexa.
Au moins cela a simplifié la récupération a défaut de coopération du fabricant, mais rien que cet aspect démontre qu'ils n'ont pas été malins: Un exemple classique, c'est les bitstream de contenu de FPGA (qui contiennent la fusemap de la logique programmée) que les outils de génération sortent également sous une forme ASCII de données pourtant à 99.9% numérique.
En embarqué, ou on est souvent contraint par la taille des stockages, il y a ceux qui prennent le marteau pilon de la compression des données pour enfoncer un clou (avec un impact de la décompression sur les temps de démarrage, des librairies de décompression à ajouter...) et ceux qui réfléchissent et passent ces fichiers bitstream dans une moulinette simple qui convertit ascii->hexa et gagnent un facteur 8 sur les données simplement (et sans impact temps de boot au chargement du FPGA ni ajout de librairies de décompression).
A l'avenir, surtout vu le prix de ces joujous, il faudrait à mon sens ajouter quelques obligations au cahier des charges tenant compte de cette expérience!