On Mar 23, 2017, at 3:45 AM, David W. Schultz
wrote:
> 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 don't care about those bits.
Why does it need to be a “single
On 03/24/2017 05:39 PM, William Westfield wrote:
> Why does it need to be a “single instruction” for the compiler to
> create inline code for the shift (two instruction: "clrc; rrc",
> right) instead of pulling in (apparently) a library that includes
> code for every possible shift count and size?
On 24/03/17 19:00, Przemek Klosowski wrote:
> Bob, did you check whether changing the declared type avoids calling
> the runtime, and avoids excessive register saving/restoring?
Yes Przemek,
David Schultz kindly informed me that a right shift, as it is not
natively supported, can cause this. Chan
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 function because one of
the variab
On 2017-03-24, Bob von Knobloch wrote:
> 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 -
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 tha
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
http://home.earthlink.net/~david
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 in
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 don'
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
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, Slashdot.org!
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 mer
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,
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 about
Further work:
having got the compilation under a size which fitted into the flash, I
found that the code did not run. (This is the same source code that
worked fine when compiled with the 'old' mspgcc compiler.)
Inspecting the assembly, I found that the interrupt was suspect.
The 'old' code pushe
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, in
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, in
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 W.
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 ba
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 show you more info on w
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 n
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 things. Note that t
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 *.l
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.
SUP
> 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 msp430-gcc-
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
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:
expor
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 set up the stack an
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
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
r
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 get
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 b
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
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
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
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 cod
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 n
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 .te
38 matches
Mail list logo
