New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shields: Add arduino uno click shield #60009
shields: Add arduino uno click shield #60009
Conversation
mikrobus_header: &mikrobus_header_1 {}; or | ||
mikrobus_header: &mikrobus_header_2 {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of them should be &mikrobus_header, another probably &mikrobus_header_alt. Or add
mikrobus_header: &mikrobus_header_1 {};
to boards/shields/arduino_uno_click/arduino_uno_click.overlay
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't adding
mikrobus_header: &mikrobus_header_1 {};
to the end of overlay force all the connecting shields to use socket_1?
The way it's implemented now, both sockets are available, and it's up to the board overlay to decide which socket is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to the end of overlay force all the connecting shields to use socket_1?
Yes, that is the point. Only one of them can be used in the tree out of the box, git grep mikrobus_header
, and that is mikrobus_header
.
The way it's implemented now, both sockets are available, and it's up to the board overlay to decide which socket is used.
Actually no, I do not see a generic way to choose one of them for a arbitrary shield at build time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The node label mikrobus_header could be set in the board overlay to decide which socket is used.
But I don't have a strong preference about this. I used mikrobus_header_1 as default and assigned mikrobus_header label.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The node label mikrobus_header could be set in the board overlay to decide which socket is used.
It is about existing shields. But have an overlay per board is nonsense as well.
If a node alias for one of the interfaces does not exist and it is not used | ||
by the connecting shield, a dummy node alias can be created by the board. | ||
An alternative is to simply delete the node alias from the | ||
arduino_uno_click.overlay file. For example if a connecting shield only uses | ||
the mikrobus_spi node alias, then mikrobus_serial and mikrobus_i2c can be deleted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does it come from? IMHO it does not make any sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Arduino UNO click creates three labels (see the overlay file).
mikrobus_spi: &arduino_spi {};
mikrobus_serial: &arduino_serial {};
mikrobus_i2c: &arduino_i2c {};
I have to create all three, because I do not know what interface the connecting shield will use.
So what happens if the arduino_i2c is not actually defined by the target board (because the drivers for i2c are not implemented), while only the spi will be used by the connecting shield? Well, the compilation will break.
In the documentation, I'm simply making a suggestion that mikrobus_i2c label may be detected if unused
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH, I do not see any reason for this text, either requirements are met or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I removed the text.
.. zephyr-app-commands:: | ||
:zephyr-app: samples/drivers/can/counter | ||
:board: xmc47_relax_kit | ||
:shield: "arduino_uno_click mcp2518fd_click" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no mcp2518fd_click in the tree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not a dependency but just not correct description, we have mikroe shields in the tree you can use as example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair enough, I updated the example to use atmel_rf2xx_mikrobus shield.
The shield converts Arduino UNO R3 headers to two mikroBUS sockets. Two mickoBUS sockets are exposed via the overlay labelled mikrobus_header_1 and mikrobus_header_2. mikrobus_header_1 is used as the default and assigned the node label mikrobus_header. Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
ea67682
to
1e6f1e2
Compare
The shield converts Arduino UNO R3 headers to two mikroBUS sockets.
Two mickoBUS sockets are exposed via the overlay labelled mikrobus_header_1 and mikrobus_header_2.
Edit:
mikrobus_header_1 is used as the default and assigned node label mikrobus_header.
The example depends on PRs:#60008#59968