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.
