-
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
Simplify msp430 headers #408
Conversation
Breaks build with
|
Please rebase on current master, #310 has been merged =) |
rebasing done; I'll look into the flashrom issue ASAP. |
BTW: this is with |
After consulting the "TI MSP x5xxx and x6xxx family user guide" (a.k.a. SLAU208M), it seems that the Flash module on these MCU works completely differently than on the x1xxx and x2xxx family. (Among others: there is no FCTL2 register on CC430xxxx devices, and the addresses are totally different from what we have in F1611/F1612/F2617). I now get the impression that the current 'flashrom.c' file should be moved from the 'msp430-common' folder to the 'msp430x16x' folder, and that a new 'flashrom.c' file should be created in the 'cc430' folder for these peculiar families... |
That's maybe the reason why flashrom.c exists as well in msp430-common as in msp430x16x. Probably someone (might be me) wanted to move this file from common to 16x but didn't removed the copy in common... Hence, I agree in removing this file from msp430-common. It is rarely used anyway as far as I can tell. |
Plus, I think it just wouldn't actually work on CC430: as I said, the SLAU208M manual says there is no FCTL2 register in these chips; however, the current code writes in this register during setup... |
Would you do that along with this PR? |
Here you go. Also added a "dummy" flashrom.c file in the 'cc430' directory: people using this kind of MCUs may implement it if they need/want to update Flash memory at runtime. |
ACK |
please rebase, #251 was merged |
Inclusion of generic <msp430.h> file is done in cpu.h
done. |
since flash management differs with the MSP430 family
I don't know if this happened before the rebase (or if telosb built before the rebase at all), but at least now the build for telosb fails here while it does not in master:
|
Indeed: the problem is that the Makefiles of both the project ('default') and the 'RIOT/cpu/msp430x16x' folder don't include the board's header files... Since RIOT is always built for a given platform (a.k.a. "board"), it seems to me that Makefiles (at least all the ones in cpu-specific directories) should always have a line like: Do you agree, people? |
The problem is a missing section in |
Whoops, I missed this file totally. My bad. Shall I add the needed section in that file, or should it be made in another PR (since it is not strictly directly related to the purpose of the current one)? |
I'd just add it here as a single commit.. |
.. and I guess it's the make structure which is to blame, not you ;-) |
Update done; maybe does it explain (and solve) some problems Oleg experienced with the telosb port?... |
ACK |
#include <stddef.h> | ||
#include <stdint.h> | ||
#include <cpu.h> | ||
#include <irq.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.
Use quotes for include directives of internal headers (#437).
Apart from the small, pureley cosmetic changes: ACK. |
Changes done (indeed, it's a recommended practice to quote custom headers and to bracket the standard ones). |
ACK ACK |
Hooray! |
Modification of the way standard MSP430 header files are included in RIOT.
This new scheme should reduce the use of #ifdefs in RIOT source code, and allow for easy integration of any other MSP430-based platform.