You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by "David G. Simmons" <sa...@mac.com> on 2016/05/23 16:27:08 UTC
Language Reference
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/ <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.
RE: Language Reference
Posted by David Baker <db...@ambiqmicro.com>.
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:sterling@apache.org]
Sent: Monday, May 23, 2016 12:56 PM
To: dev@mynewt.incubator.apache.org
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 <de...@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 <db...@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:santafen@mac.com]
>> Sent: Monday, May 23, 2016 12:14 PM
>> To: dev@mynewt.incubator.apache.org; sterling@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 <st...@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.
>
>
Re: Language Reference
Posted by Sterling Hughes <st...@apache.org>.
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 <de...@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\u2019m not running with C99 options for my compiles, as the error thrown says it is only allowed with C99. I\u2019m 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 <db...@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:santafen@mac.com]
>> Sent: Monday, May 23, 2016 12:14 PM
>> To: dev@mynewt.incubator.apache.org; sterling@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\u2019t 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 <st...@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 \u2026
>>>>
>>>> Is there a language reference for mynewt? I\u2019m seeing that standard C
>>>> stuff is not acceptable, so I\u2019m wondering if there is a language
>>>> reference for how to do stuff in mynewt. specifically things like
>>>> arrays, initializing arrays, for lops, etc.
>>>>
>>>> I\u2019m playing around with the blinky app on my new STM32F Discovery
>>>> board and finding some things just don\u2019t work as I\u2019d expect.
>>>>
>>>> TIA,
>>>> dg
>>>> --
>>>> David G. Simmons
>>>> (919) 534-5099
>>>> Web <https://davidgs.com> \u2022 Blog <https://davidgs.com/davidgs_blog> \u2022
>>>> Linkedin <http://linkedin.com/in/davidgsimmons> \u2022 Twitter
>>>> <http://twitter.com/TechEvangelist1> \u2022 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/> **/ \u267a 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 \u2022 Blog \u2022 Linkedin \u2022 Twitter \u2022 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 **/ \u267a 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 \u2022 Blog \u2022 Linkedin \u2022 Twitter \u2022 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
> **/
> \u267a 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.
>
>
Re: Language Reference
Posted by "David G. Simmons" <sa...@mac.com>.
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 <db...@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:santafen@mac.com]
> Sent: Monday, May 23, 2016 12:14 PM
> To: dev@mynewt.incubator.apache.org; sterling@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 <st...@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.
RE: Language Reference
Posted by David Baker <db...@ambiqmicro.com>.
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:santafen@mac.com]
Sent: Monday, May 23, 2016 12:14 PM
To: dev@mynewt.incubator.apache.org; sterling@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 <st...@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.
Re: Language Reference
Posted by Johan Hedberg <jo...@gmail.com>.
Hi David,
On Mon, May 23, 2016, David G. Simmons wrote:
> 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);
> }
That will call hal_gpio_init_out() with values of x from 1 to 8, and
it's probably the last one (which is out of bounds) that causes an
error.
> 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);
> }
The above is a different range: 0 to 7.
Johan
Re: Language Reference
Posted by "David G. Simmons" <sa...@mac.com>.
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 <st...@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.
Re: Language Reference
Posted by Sterling Hughes <st...@apache.org>.
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 \u2026
>
> Is there a language reference for mynewt? I\u2019m seeing that standard C
> stuff is not acceptable, so I\u2019m wondering if there is a language
> reference for how to do stuff in mynewt. specifically things like
> arrays, initializing arrays, for lops, etc.
>
> I\u2019m playing around with the blinky app on my new STM32F Discovery board
> and finding some things just don\u2019t work as I\u2019d expect.
>
> TIA,
> dg
> --
> David G. Simmons
> (919) 534-5099
> Web <https://davidgs.com> \u2022 Blog <https://davidgs.com/davidgs_blog> \u2022
> Linkedin <http://linkedin.com/in/davidgsimmons> \u2022 Twitter
> <http://twitter.com/TechEvangelist1> \u2022 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/>
> **/
> \u267a 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.
>
>