Skip to content
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

Merged
merged 3 commits into from
Mar 16, 2018

Conversation

basilfx
Copy link
Member

@basilfx basilfx commented Feb 23, 2018

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

@basilfx basilfx added Platform: ARM Platform: This PR/issue effects ARM-based platforms CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Area: boards Area: Board ports labels Feb 23, 2018
Copy link
Contributor

@aabadie aabadie left a 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.

@@ -0,0 +1,9 @@
ifneq (,$(filter saul_default,$(USEMODULE)))
USEMODULE += saul_gpio
Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

# The board MPU family (used for grouping by the CI system)
FEATURES_MCU_GROUP = cortex_m4_2

include $(RIOTCPU)/efm32/Makefile.features
Copy link
Contributor

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

Copy link
Member Author

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it though.

Copy link
Member

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.

* Connection to the on-board temperature/humidity sensor (Si7021).
* @{
*/
#ifndef SI7021_ENABLED
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed this part.

board_common_init();

/* initialize the Si7021 sensor */
#if SI7021_ENABLED
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

@basilfx
Copy link
Member Author

basilfx commented Mar 6, 2018

Fixed comments and rebased PR.

@jia200x
Copy link
Member

jia200x commented Mar 7, 2018

Don't have this board to test, but code-wise looks fine to me

@basilfx
Copy link
Member Author

basilfx commented Mar 7, 2018

@haukepetersen Do you have access to this board, and willing to test this one?

@basilfx
Copy link
Member Author

basilfx commented Mar 8, 2018

Don't have this board to test, but code-wise looks fine to me

@jia200x I can also provide you with remote access (via SSH), if you want to try?

@jia200x
Copy link
Member

jia200x commented Mar 8, 2018

@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 :)

@basilfx
Copy link
Member Author

basilfx commented Mar 13, 2018

@jia200x Are you still up for testing this one? So far nobody had the time :-)

@jia200x
Copy link
Member

jia200x commented Mar 13, 2018

Tested, works as expected.

Copy link
Member

@jia200x jia200x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK

@jia200x
Copy link
Member

jia200x commented Mar 13, 2018

let's wait for @aabadie and @kYc0o

Copy link
Contributor

@kYc0o kYc0o left a 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
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

@basilfx basilfx Mar 16, 2018

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 :-)

Copy link
Contributor

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"
Copy link
Contributor

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?

#include "board.h"
#include "board_common.h"

#include "periph/gpio.h"
Copy link
Contributor

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.


#include "cpu.h"

#include "periph_conf.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too.

@kYc0o
Copy link
Contributor

kYc0o commented Mar 16, 2018

You can squash the changes so the PR is ready.

Copy link
Contributor

@aabadie aabadie left a 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

@basilfx
Copy link
Member Author

basilfx commented Mar 16, 2018

Squashed and rebased.

@kYc0o
Copy link
Contributor

kYc0o commented Mar 16, 2018

ACK. Merge when Murdock agrees.

@basilfx basilfx merged commit 4e84530 into RIOT-OS:master Mar 16, 2018
@basilfx
Copy link
Member Author

basilfx commented Mar 16, 2018

Thank you all!

@basilfx basilfx deleted the feature/efm32_slstk3401a branch March 16, 2018 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: boards Area: Board ports CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Platform: ARM Platform: This PR/issue effects ARM-based platforms
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants