Jump to content
43oh

Energia on EXP430FR4133?


Recommended Posts

Haven't checked yet to see if mspgcc 4.6 supports the FR4133 or 6989 as it is (considering interrupt vector table size, etc). If so it'd require shipping the header and ldscript files separately along with Energia core changes.

No released version of mspgcc supports the FR4xx/2xx or FR6xx chips as those didn't exist in 2012 when the last usable updates for msp430mcu were received from TI (the 20130321 release incorporated the interrupt vector length change that released mspgcc doesn't support). Energia needs to update to msp430-elf for any chips that weren't at least in preview state in 2012, or (as you suggest) take responsibility for providing the header and linker include scripts.

 

I really want to see folks including Energia moving to msp430-elf. I'm not doing any more updates to mspgcc and in fact am no longer using it myself. Honestly I'm getting a bit tired of being the one who gets to diagnose and report all the issues msp430-elf has: it looks like passive-aggressive complaining on my part, and it mostly isn't.

Link to post
Share on other sites

... Honestly I'm getting a bit tired of being the one who gets to diagnose and report all the issues msp430-elf has: it looks like passive-aggressive complaining on my part, and it mostly isn't.

Hey, I've been doing my part. Maybe I'm not posting the problems to the right place. I assumed that posting on e2e.ti.com would be the right place as they deal with most of the issues related to specific chip configs. Is that not the right place?

 

I reported the problem with the hardware multiple back in Sept.

 

http://e2e.ti.com/support/development_tools/compiler/f/343/t/367209.aspx

 

and other problems with c++ ..

 

Where do you think this stuff should get addressed? From TI or RH? Seems like TI has the money and RH only does stuff when poked by TI?

 

-rick

Link to post
Share on other sites

Hey, I've been doing my part. Maybe I'm not posting the problems to the right place. I assumed that posting on e2e.ti.com would be the right place as they deal with most of the issues related to specific chip configs. Is that not the right place?

 

I reported the problem with the hardware multiple back in Sept.

 

http://e2e.ti.com/support/development_tools/compiler/f/343/t/367209.aspx

 

and other problems with c++ ..

 

Where do you think this stuff should get addressed? From TI or RH? Seems like TI has the money and RH only does stuff when poked by TI?

 

-rick

Thanks for reporting that issue there. It's possible that your report in early September led to the late September change to upstream gcc that started fixed the problem for msp430g2553 by adding a list of MCUs that have no MPY peripheral. Unfortunately, those changes didn't get it right for msp430fr5969.

 

Decoupling the list of available MCUs and their characteristics from the toolchain sources is one of the things that wasn't done for msp430-elf. When I say it's "mostly not" passive-aggressive complaining on my part, that's because I'm absolutely disgusted with the way TI has managed the transition from mspgcc. It's been more than two years since they started the process; only now is the toolchain usable, and it has fundamental gaps (like inline hardware multiply using the appropriate peripheral) that mspgcc was doing correctly over three years ago. The correlation between your report and subsequent changes upstream suggests that there is some responsiveness from TI, even though there's no visibility into the process and the chosen approach of using hard-coded MCU characteristic lists within the gcc sources is fundamentally flawed.

 

To your question: I use the upstream GNU sources, not TI's fork. Consequently I'm mostly filing bugs on the gcc bugzilla for things that are clearly GCC errors.

 

But bugs reported against GCC are usually ignored unless you can attract the attention of somebody, so I also post them on the mspgcc-users mailing list because folks who use mspgcc need to move to msp430-elf and to do so they need to know what issues they're going to run into. I also know the Red Hat folks monitor that and take some responsibility for fixing problems in the port they wrote. So far, I've been lucky: the only time I really needed something fixed Nick Clifton from RH was on duty and merged the patches for me.

 

If you're using the TI fork, probably E2E is the only place to report it. If you can reproduce the problem with the upstream trunk versions, report it via the appropriate GNU channels such as https://gcc.gnu.org/bugzilla. In either case, it's worth posting a note about it to mspgcc-users, and probably also on E2E, to raise visibility and hopefully encourage people to address the issue.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...