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
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
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
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 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
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
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
On 06/03/17 17:52, DJ Delorie wrote:
>
> Bob von Knobloch <b...@vknobloch.de> 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
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
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
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
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.
>>
>
> Ha
a .text of 2160 bytes.
This no longer fits on the target µproc.
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.
--
The Sun is out, the sky is blue, it's time to drive the MR2
as the prerequisites aren't listed on the wiki page, could it be that
something is missing? I don't know what mvars does.
I would appreciate any tips.
Bob von Knobloch
--
The Sun is out, the sky is blue, it's time to drive the MR2
von Knobloch b...@vknobloch.de wrote:
Hi,
I am trying to build the toolchain, following the wiki Install:from
source in order, as it is written.
On OpenSUSE 12.1 32-bit.
The make of gcc is crashing with:
=
make[2]: Entering directory
`/mnt/local
Hi,
I'm using mspgcc 20110716.
I have a project using an msp430g2231, which compiles and runs OK.
I am trying to change to processor type to a g2232 or g2332.
When I specify one of these (e.g. -mmcu=msp430g2232) then the toolchain
(linker) reports:
msp430-gcc -Wall -g -Os -mmcu=msp430g2232
serial numbers). I see that the MSP430 parts also have device
IDs but I can't find any reliable information about them. The TI docs
seem to be outdated or incomplete.
Can anyone point me to a better source of information?
Many thanks,
Bob von Knobloch
On 01/12/11 14:46, Mitnacht, Thomas wrote:
Does this help?
http://processors.wiki.ti.com/index.php/REP430F
http://www.ti.com/tool/rep430f
Regards,
Thomas Mitnacht
Thanks Thomas,
I have this, but it seems incomplete, maybe I am expecting too much :-)
Bob
On 01/12/11 15:15, Peter Bigot wrote:
I don't remember where I found this information, but I believe most
chips have a block of data at 0x0FF0 which contains chip-specific
information that can be used to figure out the part number. Other data
lives in the infoA segment of some chips, and in a
On 01/12/11 15:27, Mitnacht, Thomas wrote:
Hi Bob,
What details are you missing?
Thanks,
Thomas Mitnacht
I was hoping to be able to identify the part (or, at least, the flash
start address which I need for programming). The SLAU320c doc only maps
3 bytes (0xff0, 0xff1 0xffd) to several
On 01/12/11 16:33, Mitnacht, Thomas wrote:
Bob,
You are right, SLAU320 already talks about how to identify a derivative. The
related memory configuration needs to read from the device datasheet. We are
working on a machine readable database as part of our debug stack, but this
will not be
On 01/12/11 17:16, Peter Bigot wrote:
I think the point is that, if you already know the device, you can find the
address map (from the datasheet, from the msp430mcu package's devices.csv
file provided by TI that's used to generate the linker scripts for the
toolchain, or from information in
On 07/11/11 22:21, Daniel Beer wrote:
MSPDebug version 0.18 is now available from:
http://mspdebug.sourceforge.net/download.html
Significant new features in this release are:
* Support for new chips: MSP430F2121, MSP430F2012, MSP430F449.
* Support for raw USB access to
On 11/11/11 19:48, Chris Liechti wrote:
Am 11.11.2011 16:04, schrieb Bob von Knobloch:
I have a MSP-EXP430G2 (Launch Pad) FET and am running under OpenSuse11.3.
mspdebug -j uif
try a different driver
i'm using this to download to launchpad:
mspdebug rf2500 prog firmware.titext exit
On 11/11/11 20:18, Bob von Knobloch wrote:
There, mspdebug 'seems' (in my limited usb experience) to be trying to
access the wrong device ID (0451:f430) whereas only 0451:f430
exists, according to 'lsusb'.
OOps!
Should be:
wrong device ID (0451:f430) whereas only 0451:f432 exists
Fumblefingers
I am trying to build the toolchain on OpenSuse 11.3
Binutils GCC have built OK.
(Some trivial thing - in all 3 patch files:
../../binutils-2.21.1/configure.
should be:
../../../binutils-2.21.1/configure.
or similar).
GDB requires:
To build, obtain the upstream release distribution
On 22/07/11 12:15, Peter Bigot wrote:
On Thu, Jul 21, 2011 at 11:00 AM, bob b...@vknobloch.de wrote:
I followed the readme exactly. I have what appears to be a sensible
directory structure (although I note the is no 'info' or 'man'
directory, as there was in the '4' version).
If you want
27 matches
Mail list logo
