C:B for MSP430 issues

[Aerodesic]

I've been using C::B for quite a few years.  Currently on SVN 10376 so I stay in touch with latest work.

I'm trying to make C::B work with MSP430 (especially TI's latest sponsored version of 4.9.1).  Lots of things are rough around the edges..  The linkage between the -mmcu selection and the flags embedded into C::B is just wrong for most of them (TI / GCC changed the names from 'msp430xXXX' to 'msp430fXXX'.)  I can manually go through and 'modify' each flag by hand, but that's a pain.

Also, the mmcu flag is not passed by default to the linker so it need to manually messed with whenever the mcu type is changed.

I don't even know about GDB yet.

Is there any active development on the MSP430 stuff, then I can volunteer some changes after I tweek some more stuff.

I have *some* familiarity with C::B internally as I started writing an STM32 plugin, trying to stay totally within the scripting system rather than writing plugins - plugins are ugly because they need to be 'implemented' for each IDE binary implementation.  But trying to do everything in the scripts leaves you feeling like you are missing a few fingers now and then.

So: is anyone else trying to use C::B for msp430 development?  If so, contact me and we can share notes.  The latest note I found seemed to be from 2014, so this is not apparently a 'hot' issue at the moment :-)

If I've stuffed this message in the wrong place, please forgive me.  First time to the Message Board - tried to read all msp430-related topics, but nothing seemed to fit and I wanted this to look more 'current' than the others.

-Gary

[oBFusCATed]

The options for the compiler/linker are stored in xml file. You can edit them so they can work with the newer compiler.
Then you can post a patch, which could be integrated in the svn.

Also I think there are features for compiler version detection, but I'm not to knowledgeable about this area of codeblocks, so I might be misleading you.

[Aerodesic]

That's what I've been doing, but I don't like some of the dependencies I'm having to trace down.  Seems like there could be a better way to add function without having to *change* function already there..

For example, I've cloned the compiler_msp430_gcc.xml and options_msp430_gcc.xml (and renamed) so as to edit in the differences the TI supported compiler needs (such as *all* of the -mmcu=xxx changing names plus adding a bunch more.)  But unfortunately, to make it 'first class' you need to edit:

src/plugins/scriptedwizard/resources/common_functions.script

to set up the 'defaults' for the Debug and Release (or other) targets.  Otherwise you get nasty messages about the wizard getting pissed since it can't find the compiler/debugger defaults.

Last year I started down the road to understand the scripting stuff (mighty powerful if you get into it!) but it was missing a few critical pieces of 'interface' to the bowels of C::B (though, of course, that may have changed - there have been some might awsome updates to C::B since then.)  I'd *love* to see a way to simply *add* stuff (as in the 'automatically found .xml files' in the 'compilers' folder I cloned - those work just fine.  But I am trying not to 'touch' the delicate bits by changing the scripting harness, per se.  I hoped I could just add some extra stuff to the .xml (options) or add an addtional 'defaults_msp430_gcc_ti.xml' file (found by using the 'compiler id' in the original compiler_msp430-gcc-ti.xml file.

However, being determined to see this through, no matter what ...  Is there a 'road map' that shows where the major activities are (so one can avoid messing with something that will change out from under me) or do I just 'wing it?'

And pardon if these are dumb questions - I haven't been too close to the forums for more than a year - but I haven't find much current information about *how* to submit patches.  I'm familiar (though not directly involved) with the Linux Kernel Developers process and it is *intense* and directly coupled to the workings of git.  I'm comfy with svn and it's corresponding diff patch file production, so can handle that, but I don't know if you guys branch the way the Linux Dev stuff does.  I.e. Should I just create a patch bundle and just mail it some where?

Also, I didn't specify, but I'm Linux not Windows, but I don't want break Windows (or MacOSX either) so this was mostly why I'm trying to stay in the 'script' side of things.  I have coworkers (who are only Windows, alas) who may need access to my product and I'd like to be able to steer them to C::B without any religious issues to resolve.

Oh well, that's enough for now.  Gotta get back to some real work (I have the TI MSP430 stuff working well enough to do my development job for the moment.  I'll get back to C::B in a few days...

Thanks guys!  This is a truly incredible project and I will help if I can.

And thanks for the quick reply - given some of the old dates in the forum, I was a bit worried that anyone would see my request.

-Gary

[oBFusCATed]

Too much random info so I cannot answer all of it.
If you have to change something go for it, then we will negotiate if it is good/bad/needs changes.
There is no roadmap, everybody works on things he/she finds interesting or needs for something.

And pardon if these are dumb questions - I haven't been too close to the forums for more than a year - but I haven't find much current information about *how* to submit patches.

Currently the policy is that patches must be posted in the tickets section on sf.net.
Generally I don't like svn branches and I prefer if they are not made, because of svn's limitation.
There are some git repos that are kept in sync by various devs on various places.

I'm fine to push branches against my repo [1] directly, but they have to be directly rebase-able on my master branch. This is because of limitations of git svn.


[1] https://github.com/obfuscated/codeblocks_sf

[drvlas]

Is there any active development on the MSP430 stuff

Here I am
Here I am
How do you do

I don't even know about GDB yet

Exactly the field of my interest now. I use C::B to code, build and load programs in msp430 (FRAM) devices.
Since the (old) mspgcc linker had a bug in creating .ELF files for msp430fr MCUs, I use msp430-gcc-opensource. But I use the good old mspdebug for uploading (via the Tools menu).
Though there is no great need, but now I try to run debugging. And here I have some problems. Since these problems occur not only in C::B session, but even in 2 terminals (one for mspdebug, one for gdb) I'm not sure here is a proper place to discuss them. But if anybody shows some interest - we could try to solve the problem together.

And, well, merry Xmass! We have it in January, but there's a hot public discussion in my country about the possibility to change our Church calendar to Gregorian...  (pardon this off topic!)