Skip to content

make: enable selection of periph drivers via USEMODULE#3420

Closed
haukepetersen wants to merge 16 commits intoRIOT-OS:masterfrom
haukepetersen:add_periph_usemodule
Closed

make: enable selection of periph drivers via USEMODULE#3420
haukepetersen wants to merge 16 commits intoRIOT-OS:masterfrom
haukepetersen:add_periph_usemodule

Conversation

@haukepetersen
Copy link
Copy Markdown
Contributor

So far, we are compiling all available peripheral drivers for a CPU, independent if they are really used or not. This PR enables us to treat peripheral drivers just as ordinary modules (e.g. select them via USEMODULE += periph_gpio, etc.).

I re-ordered some includes in the main Makefile.include, would be nice if somebody could re-check this change! @gebart, @Kijewski maybe?

This PR brings some advantages:

  • we save compile time
  • we can check automatically during compile time, if a board/cpu has all the peripheral drivers needed -> no need to explicitly state the required features in an application anymore...
  • device drivers now state explicitly, what kind of peripherals they need. This could be used for automatic extraction of a board-to-driver compatibility matrix or the like

Outlook: Next step is to look at the test application and scripts and remove the explicit FEATURES_REQUIRED definitions from their Makefiles...

@haukepetersen haukepetersen added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: build system Area: Build system Area: drivers Area: Device drivers labels Jul 15, 2015
@haukepetersen haukepetersen changed the title make: eneable selection of periph drivers via USEMODULE make: enable selection of periph drivers via USEMODULE Jul 15, 2015
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

don't the cc*** use any periph stuff?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

nope, these are old (deprecated) drivers. The SPI/GPIO stuff of this drivers is implemented in a board specific part of the driver for some of the boards... These drivers are anyway subject to cleanup soon and will be removed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

kick the line out anyways, there's no cc110x in master anymore. :)

@jnohlgard
Copy link
Copy Markdown
Member

I think Mulle would need USEMODULE += periph_gpio because it controls on-board LEDs and power switches using the periph_gpio driver.
Edit: And periph_rtt for the clock

@haukepetersen
Copy link
Copy Markdown
Contributor Author

The thing is, that all Freescale CPUs do still build all the peripherals anyway, as the structure for these boards differs from the structure of the other CPUs. I would actually touch them in a follow-up PR...

@haukepetersen
Copy link
Copy Markdown
Contributor Author

rebased.

@PeterKietzmann
Copy link
Copy Markdown
Member

@kaspar030 did you already start your review? For #3538 it would be cool to have this one merged soon. At the first glance the PR looks ok to me, but I didn't read the changes that detailed.

@haukepetersen
Copy link
Copy Markdown
Contributor Author

@kaspar030 @PeterKietzmann could you review this? Would be nice to have it off the table.

Also rebased.

@kaspar030
Copy link
Copy Markdown
Contributor

Looking at it now, is there a need for all "periph" *_MODULEs to also be _FEATURES?

@haukepetersen
Copy link
Copy Markdown
Contributor Author

Don't know if I understand the questions correctly: do you mean if we still need the features_provided declarations? Then the answer is yes.

@kaspar030 kaspar030 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Aug 14, 2015
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

timer in there two times

@haukepetersen
Copy link
Copy Markdown
Contributor Author

hm, the new periph_common clashes with this PR, as this PR does automatic parsing of everything that starts with periph_...

@kaspar030
Copy link
Copy Markdown
Contributor

Do you want to rename that to "common_periph"?

@haukepetersen
Copy link
Copy Markdown
Contributor Author

just did.

@haukepetersen
Copy link
Copy Markdown
Contributor Author

Can you look over the changes once more? I will squash once you give me your ok.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I like!

@haukepetersen
Copy link
Copy Markdown
Contributor Author

fixed obvious errors and look into travis bugs now.

@haukepetersen
Copy link
Copy Markdown
Contributor Author

Travis things seemed unrelated to me, let's see what the current run tells us.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This driver is based on i2c. Don't you need to add the USEMODULE += periph_i2c line here?

@PeterKietzmann
Copy link
Copy Markdown
Member

I don't know where this comes from, but some applications don't compile because it seems that a USEMODULE is missing. E.g. now you can't compile periph_adc for stm boards. Adding USEMODULE += periph_adc to the tests Makefile, it works

@PeterKietzmann
Copy link
Copy Markdown
Member

Travis things seemed unrelated to me, let's see what the current run tells us

@haukepetersen am I mistaken somewhere? For me, the build fails really don't seem unrelated to the PR. Please adapt some of my proposed changes. I hope the number of fails will decrease and then I'll have a look at your PR again. Ok?

@haukepetersen
Copy link
Copy Markdown
Contributor Author

I think you are right, I mussed have messed up something in the build system... I look into it as soon as I find the time...

@haukepetersen
Copy link
Copy Markdown
Contributor Author

remove the hack'n'ack label, as this PR still needs work

@haukepetersen haukepetersen removed the Community: Hack'n'ACK candidate This PR is a candidate for review and discussion during one of RIOT's monthly Hack'n'ACK parties label Nov 24, 2015
@OlegHahm OlegHahm modified the milestones: Release 2015.12, Release 2016.03 Dec 3, 2015
@haukepetersen
Copy link
Copy Markdown
Contributor Author

ok won't get this working anytime soon (or ever?), so I will close this PR for now and open a new one whenever (if ever) I make progress...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: build system Area: Build system Area: drivers Area: Device drivers CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants