FUUUUUUUUUUU UUUUUUUUUU UUUUUUUUUUU UUUUUUUUUUUUU - Page 95

Non mais ils font comme ça dans l'industrie spatiale, c'est de la haute technologie

Nan mais le coup des printfs c'est un classique: ça marche avec, et quand tu les enlèves, toutes tes fuites de mémoire et autres jardinages se manifestent pour de vrai et ça ne marche plus Zerosquare: ose me dire que ça ne t'ait jamais arrivé

j'ai déja vu des printfs initialiser de la stack utilisée par les appels suivants, ce qui permettait a des variables non initialisées de faire marcher le code avec des valeurs bidons, et sans le printf, la RAM était non initialisée et ca plantait.

printf: la solution à vos problèmes.

Xi > ah mais carrément ; j'ai même livré un proto comme ça un jour, parce que j'avais pas le temps de chercher pourquoi ça marchait plus sans (en plus les printf() sur un port série sans rien de branché au bout, ça se voit pas, du coup ils l'ont jamais su).

Mais c'est le genre de trucs qu'on n'est pas censé avouer publiquement, surtout quand on bosse dans un domaine critique et qu'on milite pour MISRA et co.

Me dis pas que tu as mis des printf() de debug en orbite quand même ?

Nan Mais je me tâte, pour le prochain satellite on a un driver qui marche moins bien en release qu'en debug

Bah, c'est son jardin secret, il compte les printf à chaque évolution du satellite, ça lui fait plaisir

Je dois être vieux jeu, mais j'ai du mal à me faire à l'idée de releaser un satellite en mode debug

Bah c'est bien, s'il y a un problème, tu peux déboguer puis uploader un fix

Nan bien sûr qu'on ne va pas le faire va Mais c'est aussi une généralité de l'embarqué certifié: on n'aime pas les options d'optimisations de la compilation, et en l'occurrence la release était en -O2 parce qu'on est limite en mémoire, et c'est ça qui doit être coupable (en plus du sous-contractant qui a codé le driver, bien sûr), donc au pire il y aura désactivation de l'optimisation pour ce module si on ne trouve pas le problème et basta.

jtag over CCSDS

on a ici sur un Keil ARM bien plus de heisenbugs en -O2 qu'en -O0.

Il a fallu qu'on splitte des fichiers pour résoudre des plantages en initialisant a zéro des variables globales déja zéroisées par le code init.

(et certains endroits ont requis de tests genre

#pragma push
#pragma -O0
int code(void) {...}
#pragma pop

...)

Ximoon > tiens, vous utilisez -O2, pas -Os ?

squalyl > au prix que coûte Keil, ça doit faire mal
(d'ailleurs, c'est quoi l'intérêt de Keil pour de l'ARM ? vous avez eu une promo ? parce que sinon...)

Je préférerais rester en -OS, mais on veut être prêt des fois que l'on doive passer en -O2.

L'octet coûte si cher que ça en satellite pour qu'il faille travailler en -Os, ou il y a d'autres raisons ?

si c'était moi ce serait en gcc mais le fournisseur nous file un kit avec ca et les outils de dév sont intégrés.

(puis le printf est limité dans une carte a puce...)

C'est surtout qu'on a une architecture déjà établie, on ne peut plus augmenter nos mémoires disponibles à ce stade du projet, et qu'on a beaucoup plus de fonctionnalités à implémenter qu'initialement prévu. Et oui la mémoire de grade spatial (comme tout ce qui est de grade spatial en fait) coûte cher, d'où la tendance du "new space" à utiliser des composants terrestres et à apprendre à vivre avec les pannes plutôt que de tout sur-qualifier.

squalyl > ok.
(et y'a un port série sur les cartes à puce, non ? donc tu peux faire des printf(), du moment que tu n'as pas l'idée saugrenue de vouloir communiquer aussi avec l'hôte )

./2818

:/



Bon ca reste une version ancienne (1.0.25) car ils ont vire RC6 (me semble, en tout cas y a un cipher dont j'ai besoin en moins maintenant), mais j'comprend pas pourquoi ca marche pas.
Pas envie de faire une application dummy en plus, mon projet actuel a besoin de boost, glm, glfw, et vulkan.

J'crois que je vais laisser comme ca en attendant

Ximoon (./2838) :
C'est surtout qu'on a une architecture déjà établie, on ne peut plus augmenter nos mémoires disponibles à ce stade du projet, et qu'on a beaucoup plus de fonctionnalités à implémenter qu'initialement prévu.

"640 KB ought to be enough for anybody."?

Zero: nope

Mais sur l'ému l'ingé ST nous a dit qu'on pouvait sortir des pulses brefs quand le bus interne accédait à des adresses programmables (via des registres qui n'existent que dans l'ému) De la a faire une UART soft il n'y avait qu'un pas, avec une simple une bascule RS sur un bout de breadboard

maintenant on a un printf a 3Mbit/s

Copieurs, en 2002 j'ai rendu un projet avec un printf en trop parceque ca plantais sans

Kevin Kofler (./2841) :

Ximoon (./2838) :
C'est surtout qu'on a une architecture déjà établie, on ne peut plus augmenter nos mémoires disponibles à ce stade du projet, et qu'on a beaucoup plus de fonctionnalités à implémenter qu'initialement prévu.

"640 KB ought to be enough for anybody."?

Pour l'instant sans se stresser trop on a une prévision de moins de 2MiB de RAM utilisée et moins de 500kiB de ROM. En échangeant de la mémoire contre des performances on peut certainement tomber sous les 640kiB de RAM

Vous voulez envoyer une TI-89 dans l'espace?

(-en+dans)

En java j'ai jamais constaté le problème

Oui, mais en Java, va charger un programme dans moins de 640kiB de RAM

N'oublie pas que le java a commencé pour l'embarqué

et il continue. on fait des merveilles ds 12k de RAM.