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. > >
