This is now checked into develop branch. These are in mcu/mcu.h.
> On Oct 6, 2016, at 1:35 PM, Sterling Hughes <[email protected]> wrote:
>
> PS: https://issues.apache.org/jira/browse/MYNEWT-424
>
> On 6 Oct 2016, at 13:33, Sterling Hughes wrote:
>
>> Glen thanks for the feedback, much appreciated!
>>
>> I think MCU specific macros make sense to me. Personally, I’m OK going to a
>> schematic and looking up physical pin->port pin mapping, depending on silk
>> screen, but the fact that the arduino zero BSP starts from 32 for PORTB
>> pins, and you can only find that by reading source, is not great.
>>
>> I’m thinking this is hw/mcu/<your-mcu>/mcu/mcu.h, and there is a convention,
>> i.e. for MCUs that have ports, MCU_PORTA(pin) returns that pin. We should
>> do this for all supported BSPs prior to release.
>>
>> We’ve also talked about having a Wiki page in the past for all supported
>> Mynewt BSPs where people can annotate board pictures, instructions, notes,
>> etc. I really think prior to 1.0 this would be a good thing to get going.
>> There are a lot of blinky tutorials for supported platforms, but I think a
>> wiki page will allow people to share tips & tricks as well, targeted at
>> specific development boards.
>>
>> https://cwiki.apache.org/confluence/display/MYNEWT/Board+Support+Packages
>>
>> It would be great if folks were willing to help out here as well :-) So if
>> people are playing with the boards and willing to donate some instructions
>> to help this bootstrap - it would be awesome. :-)
>>
>> Sterling
>>
>> On 6 Oct 2016, at 9:20, marko kiiskila wrote:
>>
>>> I agree as well. Magic number is a bit too much magic.
>>>
>>> MCU specific macros would be my preference.
>>>
>>> E.g.
>>> #define PORTA(pin) (pin)
>>> #define PORTB(pin) (16 + pin)
>>>
>>>> On Oct 5, 2016, at 5:09 PM, David G. Simmons <[email protected]> wrote:
>>>>
>>>> Hi Glen,
>>>>
>>>> Thanks for all this feedback. I'm just about to start digging in to the
>>>> documentation in a serious way, and this is very helpful! I will add that
>>>> I had a similar frustration with the pin numbering when I was working on a
>>>> demo a while back and it's something that should definitely be at least
>>>> well documented, if not fixed in the code.
>>>>
>>>> Best regards,
>>>> dg
>>>>
>>>>> On Oct 5, 2016, at 4:45 PM, Glen Darling <[email protected]> wrote:
>>>>>
>>>>> Hello mynewt community,
>>>>>
>>>>> I am new to mynewt , and at this point I have just managed to get mynewt
>>>>> running on an Arduino M0 Pro, with an attached pushbutton on one GPIO and
>>>>> an LED with resistor attached on another GPIO pin. My first test program
>>>>> just monitors the button and turns the LED on whenever the switch is
>>>>> closed. And that all works fine. I also have another supported board that
>>>>> I will be introducing to mynewt soon.
>>>>>
>>>>> My first impressions are very positive. I think I understand what you are
>>>>> trying to create with this platform and it's great. Thanks for building
>>>>> this!
>>>>>
>>>>> I'd like to also add that I think the mynewt documentation is really
>>>>> excellent in general and I feel I have very quickly been able to absorb a
>>>>> good introduction to the platform and get my hands dirty. Thank you!
>>>>>
>>>>> At this point I'd like to make a couple of suggestions based on my
>>>>> initial experience.
>>>>>
>>>>> I found it very difficult to determine the appropriate integer to pass to
>>>>> the code to identify a particular GPIO pin on my hardware. I Googled for
>>>>> it without success. Eventually I went to the source code and found this
>>>>> file in my project
>>>>> "repos/mynewt_arduino_zero/hw/mcu/atmel/samd21xx/src/hal_gpio.c". That
>>>>> file has a comment that attempts to clarify the numeric mapping, but I
>>>>> was unable to follow what it was saying. Eventually after hours of
>>>>> hunting I gave up and resorted to trial and error and I was able to
>>>>> identify the integers to pass for a handful of the GPIO pins. I found
>>>>> this experience to be pretty frustrating.
>>>>>
>>>>> I think I understand that this comment buried deep in the code is where I
>>>>> was expected to get the information I needed. However, it was difficult
>>>>> to find, and when found I did not think it did a very good job of
>>>>> conveying the information that any developer will require to use mynewt
>>>>> on this board to access GPIO pins. I'd like to identify this as a
>>>>> weakness in both usability and documentation for mynewt that I hope the
>>>>> community will consider addressing.
>>>>>
>>>>> To be more specific about what I think is missing, I believe any
>>>>> developer coming to the mynewt platform with a supported board will want
>>>>> to know what pin number to use in the code for a particular physical pin
>>>>> on the board. I think only the MCU pins are known in mynewt (never the
>>>>> board pins -- okay) and one must consult the schematic to find the board
>>>>> pin corresponding to the desired MCU pin (okay). However, it's not really
>>>>> the MCU pins that mynewt knows about. Mynewt only knows about raw
>>>>> integers that are mapped in some ad-hoc way on each board, such that a
>>>>> new mynewt developer will need to search the code to discover and then
>>>>> comprehend that mapping before they can target a specific MCU pin.
>>>>>
>>>>> In my opinion, it would be much more helpful if:
>>>>> 1. the mynewt MCU support code could expose symbolic names for MCU pins
>>>>> (e.g., for Cortex M0: PA0, PB0, ...) that could be used in the code so
>>>>> developers would not need to dig through mynewt board support code to
>>>>> discover and comprehend those numeric mappings, and
>>>>> 2. the mynewt board support code could offer a
>>>>> board-silkscreen-pin-number-to-MCU-pin-number mapping (and perhaps define
>>>>> names based on the board silkscreen).
>>>>>
>>>>> I think these changes would make a huge improvement to the mynewt
>>>>> developer experience. I also believe there would be very little coding
>>>>> work required for the above, and the information required would be well
>>>>> known by anyone writing the MCU support code and the board support code.
>>>>>
>>>>> Thanks again for this project and all the good documentation,
>>>>>
>>>>> Glen.
>>>>>
>>>>
>>>> --
>>>> 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.
>>>>
>>>>
>>>
