Skip to content

kinetis: adaption for common makefiles#3099

Merged
kaspar030 merged 7 commits intoRIOT-OS:masterfrom
jfischer-no:pr@kinetis-use-common-makefile
Jun 2, 2015
Merged

kinetis: adaption for common makefiles#3099
kaspar030 merged 7 commits intoRIOT-OS:masterfrom
jfischer-no:pr@kinetis-use-common-makefile

Conversation

@jfischer-no
Copy link
Copy Markdown
Contributor

like "refactor board makefiles #2852"

@gebart Do you agree with 7704626 and you can test it please? I did not dare to change the Mulle's Makefile :-).

3150af0 is also necessary because not every Cortex-M4 has a FPU.

@jfischer-no jfischer-no added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation labels May 27, 2015
@haukepetersen
Copy link
Copy Markdown
Contributor

nice. The FPU issue is fixed in #3023. So I would suggest to merge #3023 first and adapt this...

@jfischer-no jfischer-no added the State: waiting for other PR State: The PR requires another PR to be merged first label May 27, 2015
@jfischer-no
Copy link
Copy Markdown
Contributor Author

@haukepetersen ok, will rebase/refactor it after #3023 is merged.

@jnohlgard
Copy link
Copy Markdown
Member

@jfischer-phytec-iot I will test this asap. You may delete all of the devio stuff as well I guess.

@jfischer-no
Copy link
Copy Markdown
Contributor Author

rebased on #3023

@OlegHahm OlegHahm modified the milestone: Release 2015.06 May 28, 2015
@jfischer-no
Copy link
Copy Markdown
Contributor Author

rebased on master, wait until #3100 is done.

@jnohlgard jnohlgard removed the State: waiting for other PR State: The PR requires another PR to be merged first label May 30, 2015
@jnohlgard
Copy link
Copy Markdown
Member

#3100 is merged now. Please rebase.

@jfischer-no
Copy link
Copy Markdown
Contributor Author

@gebart rebased, please review and test it. I had a strange behavior of I2C if heap is placed at the end of ram. I initially left it as it was.

@jnohlgard
Copy link
Copy Markdown
Member

I have some fixes for mulle, I have opened a PR in your repo at https://github.com/jfischer-phytec-iot/RIOT/pull/15

@jnohlgard
Copy link
Copy Markdown
Member

Did you fix the i2c issue?
I don't have any i2c devices with me right now to test with, but I can probably do it on Monday.

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 seem like a left over after your latest rebase.

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.

I want to keep it for the time being.

@jfischer-no
Copy link
Copy Markdown
Contributor Author

@gebart I do not have found a issue. If the heap moved backwards, then hdc1000 sernsor no longer works (also on the FRDM k64f-board), everything else works. I have no way to measure on i2c until Monday :-)

@jfischer-no
Copy link
Copy Markdown
Contributor Author

I mark it WIP (It only applies to c20ef10) until I checked i2c on Monday.

@jfischer-no jfischer-no added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label May 30, 2015
@jnohlgard
Copy link
Copy Markdown
Member

A hint: examine the .map file and see if any .data or .bss symbols overlap
with the sheap - eheap area.
On May 30, 2015 1:19 PM, "Johann Fischer" [email protected] wrote:

I mark it WIP (It only applies to c20ef10
c20ef10)
until I checked i2c on Monday.


Reply to this email directly or view it on GitHub
#3099 (comment).

@jfischer-no
Copy link
Copy Markdown
Contributor Author

@gebart Mulle build was broken, look at afe1788, it was necessary to move linkerscripts because they are hardcoded to $(RIOTCPU)/$(CPU)/$(CPU_MODEL)_linkersscript.ld in boards/Makefile.include.cortexm_common.

@jnohlgard
Copy link
Copy Markdown
Member

@jfischer-phytec-iot rebase on latest master since #3120, like I wrote in the original PR in your repo, "Depends on #3120"

@jfischer-no
Copy link
Copy Markdown
Contributor Author

@gebart Sorry, got it too late, will revert and rebase

@jfischer-no
Copy link
Copy Markdown
Contributor Author

rebased

@jfischer-no jfischer-no removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label May 30, 2015
@jfischer-no
Copy link
Copy Markdown
Contributor Author

@gebart I have found the reason for the anomaly, #3124. Ready for review.

@jnohlgard
Copy link
Copy Markdown
Member

Nice, I will review and test this on mulle tomorrow.

@jnohlgard
Copy link
Copy Markdown
Member

Works fine except for make term, I forgot to add the proper include. I opened https://github.com/jfischer-phytec-iot/RIOT/pull/16

@jnohlgard jnohlgard added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label May 31, 2015
@jnohlgard
Copy link
Copy Markdown
Member

ACK, please squash all commits marked "squash"

@jfischer-no
Copy link
Copy Markdown
Contributor Author

@jremmert-phytec-iot We had that before, what was it ? -> failed: driver_kw2xrf, driver_xbee

@jfischer-no jfischer-no reopened this May 31, 2015
@jfischer-no
Copy link
Copy Markdown
Contributor Author

ups

@jnohlgard
Copy link
Copy Markdown
Member

the error message is:

riot/sys/auto_init/netif/auto_init_ng_at86rf2xx.c:27:33: fatal error: ng_at86rf2xx_params.h: No such file or directory
 #include "ng_at86rf2xx_params.h"

so it seems like a problem with the ng_at86rf2xx module

@jnohlgard
Copy link
Copy Markdown
Member

I think we can just blacklist the xbee and kw2xrf tests for mulle for the time being until I have had time to properly try out the ng_ stack. The kw2xrf driver (not sure about xbee) is not applicable to the mulle platform anyway.

@jfischer-no
Copy link
Copy Markdown
Contributor Author

The kw2xrf driver (not sure about xbee) is not applicable to the mulle platform anyway.

@gebart maybe yes : http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCR20A
This is the same modem.

@jonas-rem
Copy link
Copy Markdown
Contributor

@jremmert-phytec-iot We had that before, what was it ? -> failed: driver_kw2xrf, driver_xbee

Without having a deeper look into it, the issues we had before were:

  1. The Makefile of the test application for the radio-drivers defines default GPIO-pins if the Board did not define pins for that radio module (I think the pins are counted for GPIO0 to 4 or so).
  2. And the second problem. The driver module was missing in some Makefile (I guess it was Makefile.include) that the driver was not .

@jonas-rem
Copy link
Copy Markdown
Contributor

@gebart you need to define the pins (SPI, IRQ-pin...) for the radio-driver you want to use. E.g. for the samr21-xpro board these pin assignments are defined in ./boards/samr21-xpro/include/ng_at86rf2xx_params.h

The makefile in ./boards/mulle/Makfile.dep tells to use the ng_at... driver. Without that module definition it should build either.

@jnohlgard
Copy link
Copy Markdown
Member

@jremmert-phytec-iot Thank you for the explanation. I think I will make a separate PR with the ng_netif change..

@jfischer-phytec-iot could you remove https://github.com/jfischer-phytec-iot/RIOT/commit/1d06ddebaebbe2f53c9db7b2aedb3ba534659408 (mulle: Add dependency check for ng_netif) from this PR?

I'll open a specific PR for the transceiver settings for mulle.

@jfischer-no
Copy link
Copy Markdown
Contributor Author

@gebart removed 1d06dde, squashed and rebased on master

@jfischer-no jfischer-no removed the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label May 31, 2015
@jnohlgard
Copy link
Copy Markdown
Member

ACK
@haukepetersen do you want to say anything or can we merge this so that all Cortex M platforms are finally aligned with regards to Makefiles and linker?

@jfischer-no
Copy link
Copy Markdown
Contributor Author

broadcast: Can we merge it?

@kaspar030
Copy link
Copy Markdown
Contributor

Yeah, merge!

kaspar030 added a commit that referenced this pull request Jun 2, 2015
…on-makefile

kinetis: adaption for common makefiles
@kaspar030 kaspar030 merged commit 369a47a into RIOT-OS:master Jun 2, 2015
@jfischer-no jfischer-no deleted the pr@kinetis-use-common-makefile branch July 6, 2015 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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 Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants