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 <dev@mynewt.incubator.apache.org>"
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 <dba...@ambiqmicro.com> 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:santa...@mac.com]
Sent: Monday, May 23, 2016 12:14 PM
To: dev@mynewt.incubator.apache.org; sterl...@apache.org
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 <sterl...@apache.org> 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.
