Ok alors je vais essayer d'être le plus exhaustif sur tout ce que j'ai tente :
J'ai commencé via l'IDE Arduino (commande utilisé par l'IDE dans la règle "IDE" du makefile en fin de message).
Ici les référance indéfinie se limite à quelques fonction :
/usr/bin/avr-ld : /tmp/TopMain.ino.elf.8d5Hv0.ltrans0.ltrans.o : dans la fonction « _GLOBAL__sub_D_main » :
/home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x0) : référence indéfinie vers « UMLRTMain::setArgs(int, char* const*) »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x8) : référence indéfinie vers « Top_slots »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0xa) : référence indéfinie vers « Top_slots »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0xc) : référence indéfinie vers « UMLRTCapsuleToControllerMap::setDefaultSlotList(UMLRTSlot*, unsigned int) »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x10) : référence indéfinie vers « UMLRTMain::targetStartup() »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x1a) : référence indéfinie vers « DefaultController »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x1e) : référence indéfinie vers « DefaultController »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x20) : référence indéfinie vers « UMLRTController::spawn() »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x24) : référence indéfinie vers « UMLRTMain::mainLoop() »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x2c) : référence indéfinie vers « UMLRTMain::targetShutdown(bool) »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x32) : référence indéfinie vers « DefaultController »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x36) : référence indéfinie vers « DefaultController »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.startup+0x38) : référence indéfinie vers « UMLRTController::join() »
/usr/bin/avr-ld : /tmp/TopMain.ino.elf.8d5Hv0.ltrans0.ltrans.o : dans la fonction « _GLOBAL__sub_I_main » :
/home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:38 : référence indéfinie vers « UMLRTSignalElement::UMLRTSignalElement() »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:38 : référence indéfinie vers « UMLRTSignalElementPool::UMLRTSignalElementPool(UMLRTSignalElement*, unsigned int, unsigned int) »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:12 : référence indéfinie vers « UMLRTSignal::UMLRTSignal() »
/usr/bin/avr-ld : /tmp/TopMain.ino.elf.8d5Hv0.ltrans0.ltrans.o : dans la fonction « _GLOBAL__sub_I_main » :
/home/breizh/Arduino/libraries/umlrt/umlrtmessage.hh:(.text.startup+0xc4) : référence indéfinie vers « UMLRTMessagePool::UMLRTMessagePool(UMLRTMessage*, unsigned int, unsigned int) »
/usr/bin/avr-ld : /tmp/TopMain.ino.elf.8d5Hv0.ltrans0.ltrans.o : dans la fonction « _GLOBAL__sub_D_main » :
/home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.exit+0x4) : référence indéfinie vers « vtable for UMLRTMessagePool »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.exit+0x6) : référence indéfinie vers « vtable for UMLRTMessagePool »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.exit+0x14) : référence indéfinie vers « UMLRTPool::~UMLRTPool() »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.exit+0x22) : référence indéfinie vers « UMLRTSignal::~UMLRTSignal() »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.exit+0x2e) : référence indéfinie vers « vtable for UMLRTSignalElementPool »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.exit+0x30) : référence indéfinie vers « vtable for UMLRTSignalElementPool »
/usr/bin/avr-ld : /home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:(.text.exit+0x3e) : référence indéfinie vers « UMLRTPool::~UMLRTPool() »
/usr/bin/avr-ld : /tmp/TopMain.ino.elf.8d5Hv0.ltrans0.ltrans.o : dans la fonction « _GLOBAL__sub_I_main » :
/home/breizh/Documents/Cours/stage/Sujet/TopMain/TopMain.ino:38 : référence indéfinie vers « UMLRTMutex::~UMLRTMutex() »
collect2: error: ld returned 1 exit status
Certaine son ammener à disparaitre comme UMLRTMutex() donc de toute façon cela posera problème à terme. Cependant, d'autre comme targetStartup() sont des simple return true;
J'ai donc dans un premier temps tenter de link la librairie dans la commande de link avec -L(chemin) et -lrts sans succes. Peut être que ma methode n'etais pas la bonne mais j'ai tenté plusieurs emplacement pour la commande. Tout cela pour finir par simplement recopier les ligne de compilation dans un makefile avec ce qui semblerais être les bon link à la librairie.
Ma deuxième tentative etais avec Arduino-Builder (qui est doccumenté avec les pied). j'ai donc réalisé la règles TopMainArduinoBuilder (makefile ci-dessous). Il semblerais que arduino-builder serais une espèce d'alias aux commande de compilation g++ et gcc ce qui me donne à la compilation :
La suite vous la connaissez. J'ai tenté de faire mon propre makefile from skratch et ici, comme avec toute les solutions que j'ai tenté d'exploité, des référance indéfinie.
Je dis ça je dis rien, mais j'y vois pas de trace d'une bibliothèque qui apporterait « UMLRTMain::targetStartup() »
Elle a pas l'air d'avoir été linkée together. Y a pas de miracle, elle va pas tomber du ciel...
PS: si c'est parti comme ça, ta commande IDE, tu en fait un script, histoire de ne pas mélanger les commandes que tu donnes explicitement avec des trucs que make fait à l'insu de ton plein gré.
Hola, on est parti sur "j'ai fait tout comme vous avez dit, et ça marche pas, bande de nuls".
Non en l’occurrence c'etais vraiment pas mon objectif ! Je vous remercie énormément déjà pour le coup de main donnée ! Je pense que j'ai vachement gagné en compétance niveau makefile grâce à vous.
Sur la ligne de Llinking j'ai tenté de rajouter -L/home/breizh/Documents/Cours/stage/Sujet/uml-rt-port-for-arduino/umlrt-arduino_lib/lib/arduino.avr-gcc -lrts avant le -L/tmp/arduino_build_288293 puis après. Et même chose avec arduino builder, j'ai essayé de link avec -L en reprenant la commande de linking.
Aussi en compilant avec l'IDE il y à une ligne d'output qui est intéressant après les erreurs :
Utilisation de la bibliothèque umlrt prise dans le dossier : /home/breizh/Arduino/libraries/umlrt (legacy)
/home/breizh/Arduino/libraries/umlrt correspond à une copie de tout les .cc et .hh de la librairie (j'ai essayé de faire comme pour les autres librairie aurduino)
UMLRTMain::targetStartup() existe bien. Il Y à juste un truc chelou, il y à un main.hh et un main.cc qui contiens les fonction de main.hh sauf targetStartup() targetShudDown() qui sont respectivement dans maintargetStartup.cc et maintargetShudDown.cc. Cependant ça ne viens quand même pas de la car j'ai essayé de tout mettre dans main.cc sans maintargetStartup.cc et maintargetShudDown.cc mais l'erreur reste la même.
Oui ben là, tu nous parles chinois parce qu'on ne sait pas ce qu'il y a dans ta bibliothèque, ce qu'elle est censé faire, et qu'on ne voit pas le code source. Alors pour trouver le problème des trucs cheloux, vaut mieux demander à une voyante.
targetSetup, et targetShutdown, c'est pas des fonctions que le code client est censé fournir (comme le setup / loop de l'arduino) ?
targetSetup, et targetShutdown font partie de la librairie UML-RT et non des fonction Arduino tout comme toute les fonctions non référencé.
Pour résumé, mon objectif est de porter de code c++ généré à partir de modèle UML-RT sur Arduino. Le problème étant que ce n'est pas du tout prévu pour cela.
Du coup, on peut distinguer trois choses : le main, qui varie en fonction des modèle, la librairie UML-RT qui elle est statique et c'est à elle que le main fait appel et les fonction lié à arduino qui sont peu nombreuse et qui à priori sont lié correctement car sans
> targetSetup, et targetShutdown font partie de la librairie UML-RT et non des fonction Arduino tout comme toute les fonctions non référencé.
Oui, j'entends bien que quand on travaille avec cette bibliothèque, il doit y avoir des fonctions de ce nom. La question est de savoir si c'est des fonctions fournies par la bibliothèque, ou des fonctions que le code client doit fournir à la bibliothèque (comme on doit fournir un "main" en C/C++ normal).
Quand on débugge un problème, il faut remettre en cause touts les affirmations "raisonnables" sur lesquelles on se repose quand tout se passe bien par magie. Et c'est pénible.
Ca tombe bien, être pénible, c'est une seconde nature chez moi. Qu'est ce qui prouve :
qu'elles sont **définies** (par seulement déclarées) dans le source de la bibliothèque, dans quel fichier source ?
que ces fonctions ayant été définies, les sources qui les contiennent ont bien donné lieu à des modules objets intégrés dans la bibliothèque ? (où sont les traces de la fabrication de la bibliothèque ?)
que l'édition des liens du code client est bien faite avec la bibliothèque
C'est galère, hein. Mais bon, en programmation il y a un facteur psychologique amusant du genre "oui oui mais non non, t'inquiète, ça s'est bon ça peut pas venir de là je suis sûr" qui empêche de trouver l'erreur, alors qu'on a tous les éléments sous le nez.
(C'est pour ça qu'on trouve plus facilement les problèmes dans le code des autres)
donc ça répond à quelques questions, oui toute les fonctions sont bien définie. Le librairie crée bien un fichier objet et un fichier pour la librairie statique
Ensuite mon main donne ça :
#include <Led.h>
void setup(){}
Led led(2);
void loop(){
led.flash(1000);
}
Juste de quoi faire clignoter une led toute les seconde sur la GPIO 2
Au finale, pour l'instant en tout cas, je n'ai plus de référence indéfinie vers la lib mais vers les fonctions Arduino comme digitalWrite() ou delay() et la ça m'échappe un peu pourquoi. J'ai pensé à rajouté un -L et -l pour arduino il il n'y à pas de .a.
Im manque que
michelbillaud a écrit:
Ca tombe bien, être pénible, c'est une seconde nature chez moi. Qu'est ce qui prouve :
que l'édition des liens du code client est bien faite avec la bibliothèque
Comment puis-je vérifier cela ?
Désolé pour le temps de ma réponse, j'ai eu plusieurs pistes intéressante mais qui n'ont mené nul part.
Ca tombe bien, être pénible, c'est une seconde nature chez moi. Qu'est ce qui prouve :
que l'édition des liens du code client est bien faite avec la bibliothèque
Comment puis-je vérifier cela ?
Le plus simple est de regarder les commandes que le makefile fait exécuter, et de vérifier si l'option -lmabibliotheque est bien à l'endroit voulu, dans le commande qui est censée créer l'exécutable.
soit en tapant make, qui va essayer de tout faire (et cracher un million de lignes d'erreur)
soit en tapant make -n, qui va dire quelles commandes il faudrait exécuter, mais ne les exécutera pas (ça ira plus vite :-)).
Pour arduino, je crois me souvenir (je dis peut être une bêtise) qu'il n'y a pas une bibliothèque précompilée.
Quand on crée un projet, il recompile tous les sources "arduino" dans un coin du projet (sketch). Ce qui fait qu'il affiche des tas de trucs
PS: la justification, c'est que l'environnement arduino permet de fabriquer des exécutables pour une foultitude d'architectures différentes (avr, xtensa, ...) . Donc ils ne distribuent pas le "système arduino" pré-compilé sous forme de bibliothèques, mais sous forme de sources à compiler le moment venu.
Le makefile que tu as posté plus haut compilait aussi la bibliothèque arduino dans un fichier de bibliothèque statique "core.a", c'est probablement ce qu'il manque...
Si tu peux, installe plutôt platformio, c'est beaucoup plus simple de compiler des projets arduino (ou pour d'autres frameworks pour microcontrôleurs). Pour ton exemple basique, après avoir créé un projet avec platformio en suivant ces instructions: https://docs.platformio.org/en/latest/core/quickstart.html#initialize-project
PlatformIo peut être une alternative ! Je vais regarder de quoi il en retourne.
En attendant, j'ai réussi à compiler mon cas simple ! Pour le core.a j'ai juste source le /tml dans un premiers temps pour tester. Le Makefile est donc le suivant :
Je n'arrive pas à saisir d'ou viens le problème et pour reprendre les 3 question de michel, - je n'ai pas regardé toute les fonctions une par une mais en tout cas il y en a un certain nombre de déclaré et définie de façon sur.
- ils ont effectivement donné lieu à des objets
- et a priorie l'edition de lien est bien faire car c'est les meme commande que le cas simple.
La ou je suis vraiment perplexe c'est que, a priorie, ça ne viens pas du Makefile car il marche dans mon cas simple. L'une des possibilité c'est que cela vienne des modifications que j'ai effectué dans la librairie rts pour la compiler avec avr mais cela serais étrange car j'ai des référance indéfinie sur des fonctions qui return true sans appeler d'autre fonctions.
-lcore est uniquement pour les fonction Arduino (digitalWrite(), pinMode() etc...) or tout mes référence indéfinie vienne de la librairie UML-rt (-lrts) (et il y en à trop pour les lister). Les fonctions sont définie dans divers fichier de la librairie.
Par contre j'ai des message avant les référence indéfinie que je n'avais pas vu :
/usr/bin/avr-ld : TopMain la section «.text» ne va pas s'adapter à la région «text»
/usr/bin/avr-ld : l'adresse 0x813adf de TopMain de la section «.bss» n'est pas dans la région «data»
/usr/bin/avr-ld : l'adresse 0x813adf de TopMain de la section «.bss» n'est pas dans la région «data»
/usr/bin/avr-ld : l'adresse 0x813adf de TopMain de la section «.bss» n'est pas dans la région «data»
/usr/bin/avr-ld : la région « text » est débordée de 33110 octets
Et aussi autre point que peut-être utilse, je n'ai pas les même message d’erreur avec l'IDE (qui ba chercher les fichiers source de la lib dans un dossier définie par l'IDE dans le quelle j'ai mis tout les .hh et .cc pour tester), la, l'es référence indéfinie ne sont pas sur la même choses et plus contenue. Par exemple, via l'IDE j'ai une référence indéfinie vers UMLRTMain::targetStartup() qui fait juste un "return true;" ce qui n'est pas le cas avec mon Makefile. à l'inverse, avec le make file j'ai une référence vers UMLRTController::UMLRTController(char const*, unsigned int, UMLRTSlot*) qui n'est pas présente avec l'ide.
Le fait que ça "return true" n'a aucune importance dans l'histoire. Si la référence est indéfinie, c'est que la définition de la fonction UMLRTMain::targetStartup() n'est pas prise en compte.
Si tu as des différences entre ce qui se passe avec ton Makefile et avec l'IDE, c'est une piste. L'IDE lance certaines actions, il faut te débrouiller pour savoir lesquelles, pour pouvoir les reproduire exactement. Il génère pas un Makefile intermédiaire ?
Nous, on n'est pas dans ton environnement, on n'a pas le code, on sait pas ce que tu fais avec. Et on a des capacités de voyance limitées.
J'ai précisé l'histoire du "return true" car je ne sait pas si par exemple la fonction func appel une fonction indéfinie il y à une référence indéfinie sur func ou la fonction appelé par func et de plus vu que j'ai elagué grossièrement la lib pour arduino (virer les thread, sig, etc...) ce n'est pas impossible qui y ai des vrai fonctions indéfinie mais ne n'est pas le cas de targetSetup()
L'IDE ne génére par de Makefile intermédiaire ou sinon il est mega bien planqué.
DefaultController et Top_slots avec "externe UMLClass variable;" dans "TopMainController.hh"
Le plus gros problème que j'ai c'est que je ne voit plus trop ou chercher..
Mais du coup
/usr/bin/avr-ld : TopMain la section «.text» ne va pas s'adapter à la région «text»
/usr/bin/avr-ld : l'adresse 0x813ad6 de TopMain de la section «.bss» n'est pas dans la région «data»
/usr/bin/avr-ld : l'adresse 0x813ad6 de TopMain de la section «.bss» n'est pas dans la région «data»
/usr/bin/avr-ld : la région « text » est débordée de 32318 octets
N'a aucune importance ? Quelle est la nature de ces messages ?
Si j'ai bien compris le fonctionnement de l'IDE à la compilation, à la toute première compilation après le lancement de l'IDE il va compiler les lib arduino en core.a. Ensuite il va chercher les libs dans un fichier spécifique Arduino ou il y à les fichier head et core (.h/.hh et .c/.cc/.cpp). C'est la première chose que j'ai essayé, mettre les fichier de la lib dans un dossier pour que l'ide aille le chercher et il y va bien car sans ça j'ai une erreu "no such file or directory" sur "1 | #include <umlrtmain.hh>" et à la fin de la compilation il y à la ligne "Utilisation de la bibliothèque umlrt prise dans le dossier : /home/breizh/Arduino/libraries/umlrt (legacy)"
La logique ça serait en effet qu'il compile la bibliothèque, mais il n'a pas l'air de compiler umlrt pour de vrai, parce qu'il n'y a aucune commande lancée
Compiling library "umlrt"
// AU SECOURS NE ME LAISSEZ PAS TOUT SEUL
Compiling core...
Quand on écrit le Sketch arduino, on importe les bibliothèques explicitement par l'interface, ça copie la bibliothèque dans un répertoire de bricolage, mais c'est pas probablement pas tout.
Experience, je crée un sketch "blink" (original) et j'inclue, au hasard SD
- ca me met un include
je compile. tout va bien. Dans /tmp me retrouve avec
drwxr-xr-x 2 billaud billaud 4096 mai 20 15:22 arduino_cache_749238 drwxr-xr-x 6 billaud billaud 4096 mai 20 15:22 arduino_build_577693
si je vais voir dans le build, avec grep SD *; je vois qu'on en cause dans includes.cache
ou ici, il effectue bien une commande et tout ça sans action particulière de ma part de ma part.
Si jamais ça peut être plus simple et si tu/vous à le temps on pourrais faire un appel type zoom pour essayer de voir de vive voix Évidement uniquement si vous avez le temps et l'envie d'aider un jeune freluquet que je suis.
c'est pas que j'ai pas envie, c'est que j'ai pas trop le temps, et que je n'ai pas les trucs sous la main pour regarder en détail. En plus, le bazar pour compiler avec arduino, je ne connais pas vraiment.
Faut demander à quelqu'un qui sait comment ça marche, parce moi je découvre au fur et à mesure.
Peut être qu'en faisant un "tree", on verrait ce qui a été compilé ou pas ?
les fichiers Foo.h et Foo.cpp ne sont pas passionnants
$ cat Foo/src/Foo.cpp
#include "Foo.h"
int Foo::bar(int a, int b) {
return a + b;
}
$ cat Foo/src/Foo.h
#ifndef FOO_H
#define FOO_H
class Foo {
public:
int bar(int a, int b);
};
#endif
Plus critique le fichier libraries.properties
$ cat Foo/library.properties
name=Foo
version=1.0.2
author=Xyz
maintainer=Xyz
sentence=Bla Bla.
paragraph=Just pour tester
category=Device Control
url=http://www.nowhere.com
architectures=*
Pour mon cas simple j'ai uniquement mis les fichier (le .h et le .cpp) dans un dossier que j'ai crée et nommé "Led" et il le compiler dans poser problème. L'une des pistes que j'ai explorer est que dans la plupart des libraire Arduino il y a un fichier nommé "librairy.properties" qui contiens pour l'exemple des capteur de température et hydrométrie DHT
name=RTS
version=0.1
author=
maintainer=
sentence=Library for UML-RT.
paragraph=Library for UML-RT.
category=
url=https://gricad-gitlab.univ-grenoble-alpes.fr/hilin/uml-rt-port-for-arduino
architectures= includes=mlrtmain.hh
Certain champs ne sont pas obligatoire comme les "depends" qui n’apparaît pas dans toute les librairie qui est remplacé par "include" Il y'a une options pour inclure une librairie depuis un ZIP via l'ide, il ne fait que deziper la librairie et le mettre dans le bon dossier (ce que j'ai fait de base)
UPDATE : je viens de voir le message ça reviens donc à ce que j'ai fait (j'ai essaie sans le champ "includes" aussi) et du coup j'ai les même erreurs en passant par la...
UPDATE 2 :
ça reviens aussi à mon cas simple avec la classe Led qui passe elle aussi.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
git is great because Linus did it, mercurial is better because he didn't.