Re: Initial impressions.

[marko kiiskila]

This is now checked into develop branch. These are in mcu/mcu.h.

> On Oct 6, 2016, at 1:35 PM, Sterling Hughes  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//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  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  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 

Re: Initial impressions.

[Sterling Hughes]

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

Re: Initial impressions.

[Sterling Hughes]

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//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  
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  
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, 

Initial impressions.

[Glen Darling]

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.