Re: [Mspgcc-users] TI compiler

On Fri, Mar 24, 2017 at 10:43 AM, Grant Edwards wrote: > I predict it will get worse and worse until it gets forked and > somebody else fixes it. I thought someone suggested that the interrupt routine saves too many registers because it ends up calling a runtime

Re: [Mspgcc-users] TI compiler

On 23/03/17 15:10, David W. Schultz wrote: > The family guides have complete descriptions. In this case slau144. Thanks David, I seem to have missed that, it is indeed a proper description. Thanks for all the help. The TI compiler is still no good - the interrupts are still taking much longer

Re: [Mspgcc-users] TI compiler

On 03/23/2017 06:13 AM, Bob von Knobloch wrote: > Do you know where there is proper documentation of their instruction > set? What I have from TI is scant, to say the least. The family guides have complete descriptions. In this case slau144. -- David W. Schultz

Re: [Mspgcc-users] TI compiler

On 23/03/17 11:45, David W. Schultz wrote: > While you didn't explicitly call a function in your interrupt routine, > the compiler did for the right shift of TXByte. Which the 'old' compiler doesn't. And your complaint to TI of April 2015 appears to have been ignored. > Making TXByte a signed

Re: [Mspgcc-users] TI compiler

While you didn't explicitly call a function in your interrupt routine, the compiler did for the right shift of TXByte. Making TXByte a signed int makes this go away. (The MSP430 doesn't have a single instruction to do the unsigned right shift.) You don't need for it to be unsigned because you

Re: [Mspgcc-users] TI compiler

OK, here is some code that shows the problem. I use OpenSUSE LEAP 42.1 as the operating system and have both compilers installed in /opt under 2 different names ("msp430-elf-gcc" for the TI and "msp-gcc" for the 'old' P.A.Bigot compiler). Hope it's not too much, I've tried to keep it as small as

Re: [Mspgcc-users] TI compiler

Could you post your interrupt code (C) and the resulting assembler? It's hard to debug problems without seeing those... -- Check out the vibrant tech community on one of the world's most engaging tech sites,

Re: [Mspgcc-users] TI compiler

On 03/22/2017 10:43 AM, Bob von Knobloch wrote: > On 22/03/17 16:24, David W. Schultz wrote: >> Calling another function from the ISR was what triggers this bad >> behaviour. Especially if the called function is in another file. > Hi David, > my code doesn't call a function in the interrupt, it

Re: [Mspgcc-users] TI compiler

On 22/03/17 16:24, David W. Schultz wrote: > Calling another function from the ISR was what triggers this bad > behaviour. Especially if the called function is in another file. Hi David, my code doesn't call a function in the interrupt, it merely decrements a count, tests it for zero and, if not,

Re: [Mspgcc-users] TI compiler

On 03/22/2017 09:54 AM, Bob von Knobloch wrote: > Inspecting the assembly, I found that the interrupt was suspect. > The 'old' code pushed the registers that it needed, the 'new' TI > compiler pushes (and, of course, later pulls) all of the registers from > r4 - r15 inclusive. I complained

Re: [Mspgcc-users] TI compiler

On 06/03/17 21:53, David W. Schultz wrote: > On 03/06/2017 02:19 PM, Bob von Knobloch wrote: >> Hi David, >> How have you extracted these from the .elf file? > > I didn't. You were talking about the .hex file so that is where I looked. > > The ISRs start out like this: > > __attribute__((wakeup,

Re: [Mspgcc-users] TI compiler

On 06/03/17 21:53, David W. Schultz wrote: > On 03/06/2017 02:19 PM, Bob von Knobloch wrote: >> Hi David, >> How have you extracted these from the .elf file? > > I didn't. You were talking about the .hex file so that is where I looked. > > The ISRs start out like this: > > __attribute__((wakeup,

Re: [Mspgcc-users] TI compiler

On 03/06/2017 02:19 PM, Bob von Knobloch wrote: > Hi David, > How have you extracted these from the .elf file? I didn't. You were talking about the .hex file so that is where I looked. The ISRs start out like this: __attribute__((wakeup, interrupt(USCI_A1_VECTOR))) void rxISR(void) -- David

Re: [Mspgcc-users] TI compiler

On 06/03/17 18:09, David W. Schultz wrote: > On 03/06/2017 10:25 AM, Bob von Knobloch wrote: >> Now I have to find out where the vectors have gone - they are missing >> from the .hex file. Maybe a different name from the old mspgcc? >> > > TI moved a lot of things into the linker scripts a while

Re: [Mspgcc-users] TI compiler

On 06/03/17 17:52, DJ Delorie wrote: > > Bob von Knobloch writes: >> Now the linker doesn't want to play with me - it cannot find the >> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" >> in the same directory. > > Add "-v" to your gcc line, it will

Re: [Mspgcc-users] TI compiler

On 03/06/2017 10:25 AM, Bob von Knobloch wrote: > Now I have to find out where the vectors have gone - they are missing > from the .hex file. Maybe a different name from the old mspgcc? > TI moved a lot of things into the linker scripts a while back. Each vector now gets its own section and as

Re: [Mspgcc-users] TI compiler

Bob von Knobloch writes: > Now the linker doesn't want to play with me - it cannot find the > "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" > in the same directory. Add "-v" to your gcc line, it will show you more info on where it's searching for

Re: [Mspgcc-users] TI compiler

On 06/03/17 16:58, Ben Green wrote: >>From my understanding the .h files and the .ld files are not supposed to be >>in the same directory. When in installed msp430-gcc-support-files-1.198.zip I >>did this: Curious, as the TI installer places them there (under /opt/msp430-gcc/include) > cp

Re: [Mspgcc-users] TI compiler

On 03/06/2017 09:42 AM, Bob von Knobloch wrote: > Now the linker doesn't want to play with me - it cannot find the > "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" > in the same directory. I include -Wl,-L$(SUPPORT_FILE_DIRECTORY) in the flags for gcc when linking.

Re: [Mspgcc-users] TI compiler

> Now the linker doesn't want to play with me - it cannot find the > "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" > in the same directory. >From my understanding the .h files and the .ld files are not supposed to be in >the same directory. When in installed

Re: [Mspgcc-users] TI compiler

On 03/03/17 19:30, DJ Delorie wrote: > Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime > support. Thanks DJ, I tried -mintr and at least one project produces code that could fit, thanks (should have RTFM - but finding this was not intuitive). Now the linker doesn't want to

Re: [Mspgcc-users] TI compiler

Ugh... Really sorry, hit reply instead of reply list. Greetings, Apologies for hijacking this e-mail chain, but I have had issues with the ``bloat'' in newlib as well. My issue is with internationalization support in newlib. I have configured and compiled newlib with the following flags:

Re: [Mspgcc-users] TI compiler

On Fri, Mar 3, 2017 at 12:30 PM, DJ Delorie wrote: > Also, if you're REALLY constrained to size, you might consider getting > the crt0.S source file from newlib and modifying it yourself to really > strip out the parts you don't need. Most embedded code really only > needs to

Re: [Mspgcc-users] TI compiler

On 03/03/17 19:30, DJ Delorie wrote: > > This has come up before, and here's what's going on... the new > msp430-elf-gcc includes all the code required by the standard, partly > because... well, standards... > So you end up with things like "argv handling" when there's no command > line, or "exit

Re: [Mspgcc-users] TI compiler

long story short, one of my first mspgcc worked because of a bug, when later either the bug was fixed in mspgcc or fedora (don't recall which one exactly), things broke all over, code unusable, docs I had share were wrong. But by then I was already married to the MSP430 chips, so I stayed for the

Re: [Mspgcc-users] TI compiler

I think it's pretty unlikely msp430-libc would work with upstream gcc, though I admit I haven't tried it. http://pabigot.github.io/bsp430/msp430elf.html has some outdated suggestions for building customized newlib and trimming out functionality that isn't needed. Glad to know people are still

Re: [Mspgcc-users] TI compiler

This has come up before, and here's what's going on... the new msp430-elf-gcc includes all the code required by the standard, partly because... well, standards... and partly so that the testsuite can test everything. The old msp-gcc made lots of assumptions about how the compiler would actually

Re: [Mspgcc-users] TI compiler

I "thought" something like that was happening to me, but didn't follow through. For operating system compatibility reasons I decided a while back to just keep using the legacy one, it works well for the simple things that I do, also some tool I downloaded from TI was a terrible bloat itself in the

Re: [Mspgcc-users] TI compiler

On 03/03/17 14:29, David W. Schultz wrote: > On 03/03/2017 05:20 AM, Bob von Knobloch wrote: >> As far as I can see, the 'bloat' is in library funcs (newlib?). >> Why the 50% increase and can I mitigate this somehow? >> Regards, >> Bob von Knobloch. >> > > Hard to say without seeing the code. Have

Re: [Mspgcc-users] TI compiler

Hi Bob, > As far as I can see, the 'bloat' is in library funcs (newlib?). If the bloat is indeed in the library funcs why not just compile with gcc and then link in the old, mspcc C library instead of newlib ? Cheers Nick

Re: [Mspgcc-users] TI compiler

Op 03/03/2017 om 02:29 PM schreef David W. Schultz: > On 03/03/2017 05:20 AM, Bob von Knobloch wrote: >> As far as I can see, the 'bloat' is in library funcs (newlib?). >> Why the 50% increase and can I mitigate this somehow? >> Regards, >> Bob von Knobloch. >> > Hard to say without seeing the

Re: [Mspgcc-users] TI compiler

On 03/03/2017 05:20 AM, Bob von Knobloch wrote: > As far as I can see, the 'bloat' is in library funcs (newlib?). > Why the 50% increase and can I mitigate this somehow? > Regards, > Bob von Knobloch. > Hard to say without seeing the code. Have you looked at the resulting file using objdump? If

[Mspgcc-users] TI compiler

Hi, I've been using the 'old' compiler last maintained by P.Bigot(many thanks to him). Now I need to make some changes and have installed the new msp430-gcc 6.2.1.16 under OpenSuse 42.1 My small project under the 'old' compiler produced a .text size of 1392 bytes, the 'new' compiler makes a