I thought about creating a new demo app, and the required pages to go with it for the documentation.
That being said, if the pull request for the mynewt_stm32f3 is accepted, the
standard blinky app will have to be modified slightly. As you can see, I
numbered all the pins, and in the original, there was just LED_BLINK_PIN that
is now LED_BLINK_PIN_1 so the original app will break with this modification
unless blinky is changed to incorporate that new name for the pin.
I’m happy to go about this whatever way you guys think is best. I can:
a) modify the blinky demo to use LED_BLINK_PIN_1 and submit a pull
request for that simple change to fix that issue and then either:
1) submit a NEW demo app mynewt_pinwheel with the new app or
2) write up the modifications and submit the docs for that in a
pull request to the existing docs.
B) Leave it as-is
Option B is, I guess, less preferable it sounds like.
Just let me know how you’d like me to proceed.
dg
> On Jun 6, 2016, at 1:18 PM, aditi hilbert <[email protected]> wrote:
>
> Hi David,
>
> Thank you for the modified demo - a pinwheel is far more exciting than a
> single blinking LED :)
>
> Thanks for the pull request on the remote mynewt_stm32f3 repo.
> As for the mynewt_blinky app changes, we could simply describe the main.c
> modifications in a mini-tutorial under the Blinky project for the discovery
> board. If you send out the patch I can enhance the docs. Or you could create
> a new example app and submit a pull request.
>
> thanks,
> aditi
>
>> On Jun 6, 2016, at 9:07 AM, David G. Simmons <[email protected]> wrote:
>>
>>
>> I’ve modified the Blinky demo for STM32F3Discovery to use all the LEDs
>> on-board. I thought it looked nicer than having a single LED blink on and
>> off every second. :-)
>>
>> I made the following changes to the
>> hw/bsp/stm32f3discovery/include/bsp/bsp.h in mynewt_stm32f3:
>>
>> 35: - #define LED_BLINK_PIN (72)
>> 35: + #define LED_BLINK_PIN_1 (72)
>> 36: + #define LED_BLINK_PIN_2 (73)
>> 36: + #define LED_BLINK_PIN_3 (74)
>> 38: + #define LED_BLINK_PIN_4 (75)
>> 39: + #define LED_BLINK_PIN_5 (76)
>> 40: + #define LED_BLINK_PIN_6 (77)
>> 41: + #define LED_BLINK_PIN_7 (78)
>> 42: + #define LED_BLINK_PIN_8 (79)
>>
>> That enables all the LEDs on the Board.
>>
>> I then modified main.c in the mynewt_blinky app to initialize all the pins
>> (in an array) and then turn them on/off in a round-robin pinwheel fashion.
>>
>> I’ll submit pull requests for it all.
>>
>> Best regards,
>> 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.
>>
>>
>
--
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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
