Bonjour,
Dans mes recherches sur l'ESP32 je regarde du coté d'ESP-IDF et je vois que dans les exemples en C/C++ on n'utilise pas main() mais app_main()
Je n'ai jamais entendu parler d' "app_main" qu'elle est la différence avec "main" ?
Bonne journée.
main() n'est qu'une convention.
Si le point d'entrée s'appelle app_main() c'est que le startup appelle cette fonction au lieu de main().
Merci.
Je pensais que le terme "main" était normalisé en langage C ou C++, donc obligatoire, et que c'était la fonction qui se lançait automatiquement en premier.
D'un autre coté je ne sais pas ce qu'est un "startup" et je pense qu'il faut être réaliste : j'atteins mes limites.
Le startup initialise les variables globales et appelle les constructeurs des objets globaux. Il crée aussi la pile et le tas.
Il configure aussi les périphériques principaux du micro-contrôleur :
Ensuite il appelle main().
C'est particulier aux microcontrôleur ?
Avec les avr j'avais suivi. J'avais trouvé le vrai fichier C++ avec sa fonction main() qui appellait une fonction init() qui configurait le micro à la sauce arduino.
Avec les avr j'avais l'impression que j'avais prise sur le logiciel arduino et que je pouvais m'en écarter, avec le circuit Xtensa terminé par Espressif je découvre qu'il existe des mécanismes dont j'ignore l'existence.
Cela devient vraiment une boîte noire dans laquelle on ne peut plus entrer, c'est dommage mais c'est la rançon de la performance.
J'ai toujours aimé comprendre ce que je ne connais pas encore mais là je crains que cela tourne au masochisme.
Vrai. Sur Arduino c'est différent.
Le point d'entrée est main() et il appelle une fonction init(). Init() ne fait pas grand chose à part initialiser timers et ADC.
Init() n'est pas le startup.
Le vrai startup est planqué dans la librairie libgcc, livrée sous forme binaire dans ARDUINO.
Les sources : probablement ici : gcc/libgcc at master · gcc-mirror/gcc · GitHub
Le choix se "ferait" au niveau de la conception du compilateur ou du linker ?
app_main serait normalisé dans le C et/ou C++ ?
Il faut bien un mécanisme qui fixe la première fonction appellée au démarage d'un programme.
Admettons que le choix d'appeler app_main ou main soit fait dans la conception du complilateur ou du linker, je ne m'étais jamais posé la question de savoir où ce choix est fait. Pour moi c'était un choix des concepteurs du langage.
Dans tous les tuto de C que j'ai parcouru j'ai toujours vu la fonction main et jamais app_main.
Mais pourquoi cette double (ou plus ?) possibilité app_main et main.
Derrière les noms il se cache bien des comportements différents, des avantages et des inconvénients.
En fonctionnement "normal" app_main appelerait-elle directement main ?
Avec les micros (contrôleur ou processeurs) app_main permettrait-elle de faire des actions suplémentaires ?
ou dit autrement app_main est-il réservé aux systèmes d'exploitation ou équivalents, et main pour les programmes qui tournent à l'intérieur d'un système d'exploitation ?
Merci pour ta patience.
.
Le choix se "ferait" au niveau de la conception du compilateur ou du linker ?
Non, le choix se fait au niveau de la librairie C.
Il faut bien un mécanisme qui fixe la première fonction appellée au démarage d'un programme.
Oui, le vecteur de RESET.
Dans le fichier de lien on peut fixer l'adresse de certaines variables ou fonctions.
L'adresse des vecteurs d'interruption est fixée ainsi.
Le vecteur de reset contient l'adresse du startup.
Que le startup appelle main(), app_main() ou toto() importe peu.
main() est simplement un standard, une convention, mais cela dépend totalement de la librairie C.
Bonjour
pour moi le code machine exécuté à la mise sous tension est enfoui dans la ROM de l'ESP32
Il configure certaines ressources (horloges..RAM, UART, SPI...) en tenant compte de l'état de 'fusibles' (efuses)
Ceci fait il examine l'état de plusieurs GPIO (0, 2....) et ensuite selon leur combinaison fixe le comportement du bootloader matériel (ROM) , bootloader de premier niveau
Pour ce qui nous concerne cela va donner soit :
-l'activation du téléchargement d'un code par UART et son stockage en memoire Flash SPI
-l'activation directe du code présent en mémoire Flash SPI avec des points d'entrée définis
Un bootloader logiciel , bootloader de second niveau, ( téléchargé auparavant par UART avec l'application et nombre de fonctions) entre alors en scène.
Il est en partie configurable par la chaine de développement en application de règles définies par Xtensa. Une ligne bootloader config apparait dans le menu de configuration de l'IDF.
sources :
boot : Home · espressif/esptool Wiki · GitHub
efuses : Home · espressif/esptool Wiki · GitHub
bootloader logiciel : Bootloader - ESP32 - — ESP-IDF Programming Guide latest documentation
Les engagements de confidentialité et non divulgation ne permettent pas à Espressif de documenter en profondeur certaines fonctionnalités de l'ESP32 et Cadence de répond pas aux demandes d'utilisateurs Lambda. Cette situation a déjà été évoquée sur les forums d'Espressif.
Oui tout à fait. Dans le fichier map on voit bien ceci :
.text 0x0000000000000000 0x30de
*(.vectors)
.vectors 0x0000000000000000 0x68 /mnt/sdc1/riton/.arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/avr5/crtatmega328p.o
0x0000000000000000 __vectors
0x0000000000000000 __vector_default
*(.vectors)
*(.progmem.gcc*)
0x0000000000000068 . = ALIGN (0x2)
0x0000000000000068 __trampolines_start = .
*(.trampolines)
.trampolines 0x0000000000000068 0x0 linker stubs
*(.trampolines*)
0x0000000000000068 __trampolines_end = .
*libprintf_flt.a:*(.progmem.data)
*libc.a:*(.progmem.data)
*(.progmem*)
.progmem.data 0x0000000000000068 0x3c /tmp/ccj26h77.ltrans1.ltrans.o
0x0000000000000068 port_to_output_PGM
0x0000000000000072 port_to_mode_PGM
0x000000000000007c digital_pin_to_port_PGM
0x0000000000000090 digital_pin_to_bit_mask_PGM
.progmem.data 0x00000000000000a4 0x14 /tmp/ccj26h77.ltrans2.ltrans.o
0x00000000000000b8 . = ALIGN (0x2)
*(.jumptables)
*(.jumptables*)
*(.lowtext)
*(.lowtext*)
0x00000000000000b8 __ctors_start = .
*(.ctors)
.ctors 0x00000000000000b8 0x2 /tmp/ccj26h77.ltrans1.ltrans.o
0x00000000000000ba __ctors_end = .
0x00000000000000ba __dtors_start = .
*(.dtors)
0x00000000000000ba __dtors_end = .
SORT(*)(.ctors)
SORT(*)(.dtors)
*(.init0)
.init0 0x00000000000000ba 0x0 /mnt/sdc1/riton/.arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/avr5/crtatmega328p.o
0x00000000000000ba __init
*(.init0)
*(.init1)
*(.init1)
*(.init2)
.init2 0x00000000000000ba 0xc /mnt/sdc1/riton/.arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/avr5/crtatmega328p.o
*(.init2)
*(.init3)
*(.init3)
*(.init4)
.init4 0x00000000000000c6 0x16 /mnt/sdc1/riton/.arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/avr5/libgcc.a(_copy_data.o)
0x00000000000000c6 __do_copy_data
.init4 0x00000000000000dc 0x10 /mnt/sdc1/riton/.arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/avr5/libgcc.a(_clear_bss.o)
0x00000000000000dc __do_clear_bss
*(.init4)
*(.init5)
*(.init5)
*(.init6)
.init6 0x00000000000000ec 0x16 /mnt/sdc1/riton/.arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/avr5/libgcc.a(_ctors.o)
0x00000000000000ec __do_global_ctors
__init, __do_copy_data, __do_clear_bss, __do_global_ctors font bien penser à un startup.
J'ai trouvé le source 
:
http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/crt1/gcrt1.S?revision=2519&view=markup
On voit bien (ligne 302) XCALL main