Nice!! I pinged a question to my Green Hills compiler friend about that abstruse for(int X=0; ....... thingie. I'll let you know what I hear back. d
-----Original Message----- From: Sterling Hughes [mailto:[email protected]] Sent: Monday, May 23, 2016 12:56 PM To: [email protected] Subject: Re: Language Reference Hi David, Compiler options are in the compiler directory: $ more compiler/arm-none-eabi-m4/compiler.yml <snip> compiler.path.cc: arm-none-eabi-gcc compiler.path.archive: arm-none-eabi-ar compiler.path.as: arm-none-eabi-gcc -x assembler-with-cpp compiler.path.objdump: arm-none-eabi-objdump compiler.path.objsize: arm-none-eabi-size compiler.path.objcopy: arm-none-eabi-objcopy compiler.flags.default: -mcpu=cortex-m4 -mthumb-interwork -mthumb -Wall -Werror -fno-exceptions -ffunction-sections -fdata-sections compiler.flags.optimized: [compiler.flags.default, -Os -ggdb] compiler.flags.debug: [compiler.flags.default, -O1 -ggdb] compiler.ld.flags: -static -lgcc -Wl,--gc-sections compiler.ld.resolve_circular_deps: true compiler.ld.mapfile: true If you look here, of special note are: compiler.flags.default: -mcpu=cortex-m4 -mthumb-interwork -mthumb -Wall -Werror -fno-exceptions -ffunction-sections -fdata-sections compiler.flags.optimized: [compiler.flags.default, -Os -ggdb] compiler.flags.debug: [compiler.flags.default, -O1 -ggdb] When you specify a "build_profile" in the target (e.g. debug or optimized), it will take the flags that correspond with that build profile. By modifying this definition (or creating your own), you can modify the default compiler settings. The compiler definition is specified by the board support package, so if you look in: $ more hw/bsp/olimex_stm32-e407_devboard/pkg.yml <snip> pkg.name: hw/bsp/olimex_stm32-e407_devboard pkg.type: bsp pkg.description: BSP definition for the Olimex STM32-E407 board. pkg.author: "Apache Mynewt <[email protected]>" pkg.homepage: "http://mynewt.apache.org/"; pkg.keywords: - olimex - stm32 - e407 pkg.arch: cortex_m4 pkg.compiler: compiler/arm-none-eabi-m4 pkg.linkerscript: "olimex_stm32-e407_devboard.ld" pkg.linkerscript.bootloader.OVERWRITE: "boot-olimex_stm32-e407_devboard.ld" pkg.downloadscript: "olimex_stm32-e407_devboard_download.sh" pkg.debugscript: "olimex_stm32-e407_devboard_debug.sh" pkg.cflags: -DSTM32F407xx pkg.deps: - hw/mcu/stm/stm32f4xx - libs/baselibc You can see the pkg.compiler defined there -- if you wanted to have a custom compiler definition for your BSP, you could mod it there. If you think the default options are wrong, we're happy to discuss changing them as well, just come up with a proposal for what you think would work better. Best, Sterling On 5/23/16 10:33 AM, David G. Simmons wrote: > Apparently I’m not running with C99 options for my compiles, as the error > thrown says it is only allowed with C99. I’m still trying to figure out the > structure of a build so I can change build options, etc. > > Thanks, > dg > >> On May 23, 2016, at 1:27 PM, David Baker <[email protected]> wrote: >> >> Do you run with C99 options for your compiles? I thought this for(int x = 0; >> x < 8; x++) should have been valid too. Is this a MISRA restriction? >> >> >> -----Original Message----- >> From: David G. Simmons [mailto:[email protected]] >> Sent: Monday, May 23, 2016 12:14 PM >> To: [email protected]; [email protected] >> Subject: Re: Language Reference >> >> Poking around in bsp.h I figured out that the LED pins are 72 - 79 on this >> board, so I #DEFINEd them all as LED_BLINK_PIN_x so I could blink them all >> round-robin, just as an exercise. >> >> I then changed int g_led_pin to int g_led_pins[8]; >> >> but initializing them all via >> >> int x = 0; >> while(x++ < 8){ >> hal_gpio_init_out(g_led_pins[x], 1); } >> >> results in: main.c:58:26: error: iteration 7u invokes undefined behavior >> [-Werror=aggressive-loop-optimizations] >> hal_gpio_init_out(g_led_pins[x], 1); >> >> which indicates that it is caused by aggressive optimization of the loop >> itself (apparently for(int x = 0; x < 8; x++) loop structure isn’t accepted). >> >> Interestingly, when I just now changed it to: >> >> int x; >> for(x = 0; x < 8; x++){ >> hal_gpio_init_out(g_led_pins[x], 1); } It all worked fine. I >> now have blinky running a colorwheel. :-) >> >> Lots to learn, I guess. >> >> Thanks! >> dg >> >>> On May 23, 2016, at 12:32 PM, Sterling Hughes <[email protected]> wrote: >>> >>> Standard C stuff should be acceptable. What's not working -- note: we do >>> compile with -Wall -Werror as the default setting. >>> >>> Sterling >>> >>> On 5/23/16 9:27 AM, David G. Simmons wrote: >>>> >>>> Another N00B question … >>>> >>>> Is there a language reference for mynewt? I’m seeing that standard >>>> C stuff is not acceptable, so I’m wondering if there is a language >>>> reference for how to do stuff in mynewt. specifically things like >>>> arrays, initializing arrays, for lops, etc. >>>> >>>> I’m playing around with the blinky app on my new STM32F Discovery >>>> board and finding some things just don’t work as I’d expect. >>>> >>>> TIA, >>>> dg >>>> -- >>>> David G. Simmons >>>> (919) 534-5099 >>>> Web <https://davidgs.com> • Blog <https://davidgs.com/davidgs_blog> >>>> • Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter >>>> <http://twitter.com/TechEvangelist1> • GitHub >>>> <http://github.com/davidgs> >>>> /** Message digitally signed for security and authenticity. >>>> * If you cannot read the PGP.sig attachment, please go to >>>> * http://www.gnupg.com/ Secure your email!!! >>>> * Public key available at keyserver.pgp.com >>>> <http://keyserver.pgp.com/> **/ ♺ This email uses 100% recycled >>>> electrons. Don't blow it by printing! >>>> >>>> There are only 2 hard things in computer science: Cache >>>> invalidation, naming things, and off-by-one errors. >>>> >>>> >> >> -- >> David G. Simmons >> (919) 534-5099 >> Web • Blog • Linkedin • Twitter • GitHub >> /** Message digitally signed for security and authenticity. >> * If you cannot read the PGP.sig attachment, please go to >> * http://www.gnupg.com/ Secure your email!!! >> * Public key available at keyserver.pgp.com **/ ♺ This email uses 100% >> recycled electrons. Don't blow it by printing! >> >> There are only 2 hard things in computer science: Cache invalidation, naming >> things, and off-by-one errors. >> >> > > -- > David G. Simmons > (919) 534-5099 > Web • Blog • Linkedin • Twitter • GitHub > /** Message digitally signed for security and authenticity. > * If you cannot read the PGP.sig attachment, please go to > * http://www.gnupg.com/ Secure your email!!! > * Public key available at keyserver.pgp.com **/ ♺ This email uses > 100% recycled electrons. Don't blow it by printing! > > There are only 2 hard things in computer science: Cache invalidation, naming > things, and off-by-one errors. > >
