Discussion :

[pcdwarf]

Bonjour.

La question s'adresse aux programmeurs qui ont usage assez pointu du préprocesseur C / C++.
Elle est en lien avec la plateforme avr (arduino).


contexte


Sur certaines architectures, dont les AVR, les constantes se trouvent copiées en RAM par le loader alors que des informations de debuggage ont tout lieu d'être stockées en ROM. Il en résulte un gaspillage de ram important sur des architectures très limitées de ce point de vue.

il existe déjà un attribut __ATTR_PROGMEM__ permettant de spécifier qu'un element doit être placée (uniquement) en ROM.
Il faut par contre utiliser une fonction spéciale pour la lire.

Pour simplifier l'usage de cet attribut, il existe un jeu de macro dont par exemple
La macro PSTR(x) Permet de mettre la chaine x en ROM
voir à ce sujet http://www.nongnu.org/avr-libc/user-..._pgmspace.html


Problème

Vous connaissez sans doute la __func__ qui donne le nom de la fonction en cours.

Le problème, c'est qu'on ne peut pas faire quelque chose du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DebugP( PSTR( __func__ ) );

parce que __func__ n'est pas un "string litteral" mais une variable statique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

error: initializer fails to determine size of '__c'

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
//The C99 __func__ magic variable is defined as:
static const char __func__[] = "function-name";

Du coup, on se retrouve à mettre des informations de debuggage en RAM, ce dont on manque cruellement.

Bref, l'idée serait de disposer d'une macro __funcP__ définie comme

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

static const char __funcP__[] __ATTR_PROGMEM__ = "function-name";

voir même directement comme une chaine "immédiate" comme c'est par exemple le cas pour __FILE__

Seulement voila.
Les developpeurs de gcc-avr n'ont pas l'air bien motivés pour ajouter cette fonctionnalité
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760

Du coup, je me demandais si il n'était pas possible de faire une macro qui définirai ça tout seul à partir du prototype.

J'ai bien fait quelques essais mais je sèche pour trouver quelque chose qui produise du code à peu près lisible.
Au point où j'en suis, il est moins pénible et surtout plus lisible de définir une variable locale en rom en copie-collant le nom de la fonction.
Quelqu'un aurait-il une idée sur la meilleure façon de s'y prendre ?


Ah! si dernier point.
Si il y a un #prgama que j'ai pas vu et qui fait le job. Je prends !

[pcdwarf]

L'absence de réponse malgré un nombre de lectures élevé m'incite à croire que ce problème n'a effectivement pas de solution simple.

Je me suis fait une macro raccourci mais qui nécessite toujours de copie-coller le nom de la fonction entre guillemets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void foo(){
FUNCNAMEP("foo");
 
}

Je ne vois vraiment pas comment faire autrement et je laisse tomber pour le moment.
Si quelqu'un a une idée....

[bacelar]

Je ne connais pas la plateforme arduino, mais j'ai toujours eu du mal à comprendre le fait vouloir avoir ces informations "en live".
J'ai tendance à utiliser les coredump, qui, avec les informations de débugging, permettent d'avoir toutes ces informations de manière fiable et automatique.

[Bousk]

As-tu essayé __FUNCTION__ ? C'est ce que l'on utilise sur VS au boulot.

[pcdwarf]

Alors oui. J'ai Essayé __FUNCTION__ et il n'y a aucune différence.

https://gcc.gnu.org/onlinedocs/gcc/Function-Names.html

__FUNCTION__ is another name for __func__, provided for backward compatibility with old versions of GCC.

J'ai tendance à utiliser les coredump, qui, avec les informations de débugging, permettent d'avoir toutes ces informations de manière fiable et automatique.

Pour rappel, la "platefome" arduino c'est un microcontroleur Atmega328.
Un microcontroleur équipé de "seulement" 2Ko de RAM, 32Ko de ROM Flash et 1Ko d'EEPROM. (ça parait peu mais c'est de fait le plus musclé de la famille)

Il n'y a pas de système d'exploitation pour faire un coredump d'un programme qui crashe.
Un programme qui crashe, il fait juste complètement n'imp ou il reset le MCU.
Historiquement. Il n'y avait tout simplement pas assez de place dans ces bébéttes pour y mettre des informations de débuggage.
Cela dit, avec 32Ko de ROM, on commence à être confort.
Le problème est que si toutes les chaînes constantes sont chargée en RAM par le loader, les 2Ko de RAM sont rapidement et largement insuffisants.
Je n'ai pas vraiment le choix : je dois mettre ce genre de chaînes de debuggage en ROM ou y renoncer.

[Médinoc]

J'ai bien peur qu'à moins qu'il y ait un support spécifique du compilo pour cela, ce soit peine perdue (du au fait que __func__ etc. ne soit jamais une chaîne littérale).

[bacelar]

Il n'y a peut-être pas de coredump mais la possibilité de debugging à distance doit être possible, non ?

[nikko34]

Le problème c'est que débugger à distance veut dire mettre un port série ou un afficheur LCD (voire une led ou un beeper). Mais rien que le fait de mettre ces éléments peut amener d'autres bugs car il n'y a pas de protection de la mémoire sur ces puces, et la pile et le tas peuvent se chevaucher sans prévenir et te faire des bugs dans tous les sens.

Du coup, il faut surtout faire très attention à son code (et le C++ peut aider d'ailleurs). Et vu le genre de bugs qu'on peut avoir si on fait pas attention, je crois pas qu'avoir le nom de la fonction aide beaucoup, franchement.

[pcdwarf]

J'ajoute que le débugging "pas à pas" n'est possible qu'a condition de sacrifier un certain nombre de fonctions du MCU à cet usage sans compter que l'execution "pas à pas" n'est pas forcément compatible avec les temps de réponse attendus par le matériel qui est autour.
En l'occurence, je n'ai pas d'autre choix que de faire du debugging "dans le code" avec une sorte de log des différentes opérations qui se font sur le port série du MCU.
c'est à ce moment là que j'aimerai bien pouvoir préfixer automatiquement le message de debug avec le nom de la fonction qui envoie le message mais ce n'est absolument pas nécessaire et au pire, ça peut se faire à la main.