-
Notifications
You must be signed in to change notification settings - Fork 2k
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
boards: slstk3401a: add support (v2) #8630
Conversation
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.
Made a pass of review and found minor things.
boards/slstk3401a/Makefile.dep
Outdated
@@ -0,0 +1,9 @@ | |||
ifneq (,$(filter saul_default,$(USEMODULE))) | |||
USEMODULE += saul_gpio |
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.
indentation should be 2 spaces here
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.
Fixed
boards/slstk3401a/Makefile.features
Outdated
# The board MPU family (used for grouping by the CI system) | ||
FEATURES_MCU_GROUP = cortex_m4_2 | ||
|
||
include $(RIOTCPU)/efm32/Makefile.features |
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.
just comparing to nucleos and I think if a '-' at the beginning of the line is required
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.
According to this link, it should be prefixed if you don't care if the file exists. But I do :-)
I see that others have it, but I wonder why the cpu
include is somewhat optional...
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.
Fixed it though.
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.
I do think the optional include in the other boards is a bug though.
boards/slstk3401a/include/board.h
Outdated
* Connection to the on-board temperature/humidity sensor (Si7021). | ||
* @{ | ||
*/ | ||
#ifndef SI7021_ENABLED |
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.
I don't think this is the way to go. Just bind this to the fact that the module is loaded or not, e.g. use MODULE_SI7021
, or even MODULE_SI70XX
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.
So in fact this part is not needed.
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.
Removed this part.
boards/slstk3401a/board.c
Outdated
board_common_init(); | ||
|
||
/* initialize the Si7021 sensor */ | ||
#if SI7021_ENABLED |
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.
use:
#ifdef MODULE_SI70XX
instead. This flag is set automatically when one adds USEMODULE += si7021 in the application makefile.
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.
Fixed.
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.
I didn't see this comment. IMHO this is not needed at all, since the inclusion of the driver is not really optional, the device is physically attached to the board and cannot be detached or deactivated, thus it belongs to the board and should be initialised whenever it's used.
The iotlab-m3 board has also some sensors attached, maybe you can take a look there to see how it's implemented, but as far as I can tell, they are only initialised when they're used through auto_init.
Another option would be to add a params file so you can access the sensor through SAUL using the default 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.
since the inclusion of the driver is not really optional, the device is physically attached to the board
yes it is, if the application doesn't load the driver module, there's no need for initializing and setting the pin that control it on the board.
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.
I just got the purpose of this, made my comment in my review.
d05b362
to
42ae8c2
Compare
Fixed comments and rebased PR. |
Don't have this board to test, but code-wise looks fine to me |
@haukepetersen Do you have access to this board, and willing to test this one? |
@jia200x I can also provide you with remote access (via SSH), if you want to try? |
Thanks for the offer. Unfortunately I won't be in the office until next monday, so I think would be nice if someone else can test it before :) |
@jia200x Are you still up for testing this one? So far nobody had the time :-) |
Tested, works as expected. |
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.
ACK
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.
I found some small style issues but besides it's OK.
/* perform common board initialization */ | ||
board_common_init(); | ||
|
||
#ifdef MODULE_SI70XX |
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.
is it possible to not use this module physically on the board? I mean, that you can disable it somehow so you need this guard?
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.
Well, removing this condition will always enable the sensor, even if you don't use it. I would therefore not want to remove it.
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.
So what you mean is that this pin can turn on/off the sensor? If that's the case, then this is a kind of "software detachment".
IMHO it looks a bit strange to have it here, but I don't have in mind right now a better way to integrate this functionality.
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.
a better way to integrate this functionality.
It could be done using the driver params, as you suggested before. But this is something that is not described in the sensor datasheet, a kind of external switch, only available on that board. So the actual solution is the best one I think.
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.
Just to clarify: this pin is not directly connected to the enable line of the Si7021: it's connected to a board-specific IC that will toggle VDD for the Si7021. The Si7021 does not have one.
So to use this Si7021, you have to enable this pin to supply it VDD. The reason to disable it, is to not take into account its consumption when profiling power consumption. The user manual calls it the enable pin, but it could also have been called toggle-power pin :-)
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.
@basilfx Yes is what I thought, a real physical software controlled switch. That's why I didn't have an idea on how to integrate it, but I guess we should leave it as it is here and if the case comes across again we find a better integration.
|
||
#include "periph_cpu.h" | ||
|
||
#include "em_cmu.h" |
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.
Can you put all the includes together?
boards/slstk3401a/board.c
Outdated
#include "board.h" | ||
#include "board_common.h" | ||
|
||
#include "periph/gpio.h" |
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.
I think the space in between is not necessary.
boards/slstk3401a/include/board.h
Outdated
|
||
#include "cpu.h" | ||
|
||
#include "periph_conf.h" |
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.
Here too.
You can squash the changes so the PR is ready. |
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.
My comments have been addressed, ACK
42ae8c2
to
995973f
Compare
Squashed and rebased. |
ACK. Merge when Murdock agrees. |
Thank you all! |
Contribution description
This PR add supports for the Silicon Labs SLSTK3401a. The files are similar to the SLTB001a and STK3600 and STK3700 already supported. The main difference with the STK3x00 is that is has a second series MCU and it has a memory LCD (supported by U8g2).
For convenience, this is the diff between STK3600 and SLSTK3401a board files.
Issues/PRs references
#8585
#8520