I'm working to update the mspgcc-based tool chain to support the CC430F5137
and related chips on TinyOS. Since the CC430 family doesn't have more than
32KB of memory, I'm ignoring the MSP430X branch. Similarly, I'm leaving
aside the mspgcc4 fork, though I plan to go back to that. However, I am
I also could not find anything saying which was canonical, but I have found
the Bazaar repository on SourceForge to incorporate material from the
mspgcc4 fork and from the msp430x branch of CVS. I'm using it as the basis
of the CC430 support. (I see I mistakenly said git in my post where I
meant
.
* Additional MSP430-5xx module support from JMGross msp...@grossibaer.de,
including new support for:
- CRC16
- Power Management Module
* Additional MSP430-5xx/CC430 module support from Peter Bigot
p...@peoplepowerco.com, including new support for:
- Port Mapping Control
- Special Functions
I've updated the CC430 bazaar repository hosted on the
OSHANhttp://sourceforge.net/projects/oshan/project page with these
enhancements below. How can I help get these merged
into a single MSPGCC repository?
- Define __cc430x613x, __cc430x513x, __cc430x612x per TI headers to
control feature
Although my EZ430 is still in the box, I believe there are others who have
had success. I do use MSP430 with the TI EM430 board which uses the same
chip. You need binutils and gcc patches, which according to the logs are
being integrated into the mspgcc4 development line. A new distribution
as mspgcc4; up to two
weeks ago that's what I was using.
Peter
On Wed, Jan 13, 2010 at 11:43 AM, Peter Bigot p...@peoplepowerco.com wrote:
In support of OSHAN http://sourceforge.net/projects/oshan/, an open
source home area network targeted to embedded devices, I've implemented
CC430 support
mspgcc4 in conjunction with the updated msp430-libc that extends the
peripheral support for MSP430XV2 chips should be able to handle this chip
using the -mmcu=msp430x5437 MCU flag
Peter
On Wed, Feb 24, 2010 at 9:07 PM, Anthony Asterisk
anthony.aster...@gmail.com wrote:
Hi all!
I have a new
Heh. This is all happening in mspgcc CVS, mspgcc bazaar, mspgcc4
subversion, and msp430-libc git (under the OSHAN project). I'm pretty
committed to a solid packaged solution, and at the moment the most receptive
maintainers appear to be associated with mspgcc4. I'm working towards
getting them
That warning pre-dates my involvement, but I've assumed it was just a notice
that untested code was being used (the X2 chips have more interrupts, so the
address for the reset pointer changed). At this time, I consider it to be
noise, and expect to remove it next time I'm working on msp430-libc.
There was some discussion about whether to include msp430/common.h; the pros
are that the documentation says it should be included and people seem to
expect it; the cons are that it defines certain things that aren't
necessarily common, like the address of the watchdog timer (fixed) and the
LPM
Thanks; I'd fixed the issue for UCA, but neglected to do the same for UCB,
and wasn't using that header by the time I validated UCB functionality.
I'll fix usci.h in my variant msp430-libc, but you may be better off using
usci_5xx.h, which gives up on trying to support everything in one file,
Project GNU is not involved with maintaining any of the msp430-libc
variants. The changes have been integrated into the msp430-libc I maintain,
and should be part of the next mspgcc4 release.
I don't think what you describe is quite normal for interrupt handling. If
the function declaration has
I'll merge this into my msp430-libc this weekend. I hope to get that moved
onto the mspgcc4 project soon.
Peter
On Wed, Mar 31, 2010 at 2:13 AM, Eric Decker cire...@gmail.com wrote:
We recently switched to the msp430f2618 from a msp430f1611 and on boot up I
noticed that DCOCTL was getting
I've posted SRPMs for the latest mspgcc4 (binutils 2.20 + gcc 4.4.3) and
msp430-libc. See http://sourceforge.net/projects/mspgcc4/files/
These are based on the current Fedora RPM spec files, but have been updated
for mspgcc4 support. I have not posted pre-built RPMs for any particular OS
or if we are making the
jump over to Bazaar.
There here:
https://launchpad.net/~adamhorden/+archive/msp430https://launchpad.net/%7Eadamhorden/+archive/msp430
They need respining for Ubuntu Lucid and I hope to get this done as soon as
possible.
Adam
On 5 April 2010 18:13, Peter Bigot p
Closest useful functionality may be strtoul(3), which is present (I haven't
personally tested it).
Peter
On Mon, Apr 19, 2010 at 6:13 AM, Balbir Thomas bal...@hvpd.co.uk wrote:
Hi,
I am trying to port some software to msp430-gcc. I think the code was
originally written for IAR (not sure).
If you can duplicate that with mspgcc4 please let me know or file a ticket
on that project and I'll see it gets fixed.
Peter
On Mon, Apr 19, 2010 at 7:09 AM, Michiel Konstapel m.konsta...@sownet.nlwrote:
-Original Message-
From: Peter Bigot [mailto:p...@peoplepowerco.com]
Sent
The patch is too big for this mailing list. I've uploaded a copy to:
http://sourceforge.net/projects/mspgcc4/files/Patches/msp430-r4.20100210-chipcat.patch
It's also available within the SRPM.
Peter
On Tue, Apr 27, 2010 at 6:06 PM, Peter Bigot p...@peoplepowerco.com wrote:
Yes
directory.
Peter
On Tue, Apr 27, 2010 at 6:14 PM, Anthony Asterisk
anthony.aster...@gmail.com wrote:
Thank you very much!
a dumb question...
how do I apply these patches (roughly)?
Peter Bigot wrote:
The patch is too big for this mailing list. I've uploaded a copy to:
http
GCC does not use #pragma directives; they use function attributes instead.
The syntax for marking an interrupt routine is:
// Timer A0 interrupt service routine
// #pragma vector=TIMER1_A0_VECTOR
// __interrupt
__attribute__((interrupt(TIMER1_A0_VECTOR)))
void TIMER1_A0_ISR(void)
{
Beyond
There's a header file signal.h that defines some macros like interrupt and
eint as helpers instead of using the underlying attribute declarations and
intrinsics. You can use either syntax.
Peter
On Mon, May 24, 2010 at 10:52 AM, Dan Bloomquist d...@lakeweb.net wrote:
Peter Bigot wrote
version instead of /opt to /usr or is there any neat
trick to maintain both versions. I'm not sure is this even necessary -
actually one version that suits for both is better.
There aren't any mspgcc4 .deb packages - are they coming in the future?
Andres
On 24.05.2010, at 17:58, Peter Bigot
(I speak here with reference to the binutils patches in the mspgcc4
repository. Not sure which release you're using.)
Chip-specific constants like that are stored in ld/emulparams/msp430all.sh.
It appears ones for INFO and BOOT were added for some (but not all) chips,
but are never referenced.
I'll get the basic patch for this into the queue for mspgcc4.
Jens-Michael, would you say that for chips that have INFOA through INFOD,
the sections should be named infoa (etc) and that infomem should be dropped
on those chips? Do we need infoanobits (etc) for each of those as well?
If the
The IAR compiler specifically generates very tight code; some of the
intrinsics (such as even_in_range) help it do so (while it's possible to
create a function that has the same operational behavior as the intrinsic,
the code generated for the intrinsic is likely to be smaller). It's quite
for one of them.
I have no idea of the template script, so I don't know what to do and how,
or not.
JMGross
- Ursprüngliche Nachricht -
Von: Peter Bigot
An: mspgcc-users@lists.sourceforge.net
Gesendet am: 27 Mai 2010 18:25:39
Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx
I've been told before that the MSP430X patch set has never been integrated
into mspgcc4. That's on my list to get to, but it's probably between one
and four weeks out.
Peter
On Tue, Jun 1, 2010 at 10:36 PM, p...@sehorne.org wrote:
I am using mspgcc4.
The warning: internal error: unsupported
:
Thank you, Peter.
I notice you refer to the linking problem as MSP430X. Are the linking
problem and the warning issued in signal.h related?
Thanks,
Paul
On 6/3/2010 9:16 AM, Peter Bigot wrote:
I've been told before that the MSP430X patch set has never been
integrated
into mspgcc4
But that file won't necessarily have the right values for the F2013. For
that chip, I suspect you want msp430x20x3.h. Without looking at the
datasheet, I'm reasonably sure the 2013 doesn't have an ADC12_PLUS or even
an ADC12.
Peter
On Fri, Jun 4, 2010 at 12:04 PM, Paul F. Sehorne
If you will provide a complete standalone example that reproduces the
problem I'll take a look at this. The fragments you posted before(menu.h,
menu.c, main.c) aren't complete and I don't really have time to try to fill
out the missing pieces. Best way would be to file it as a bug on the
mspgcc4
The information that TI encodes in their linker command file is built into
the MSP430 support in binutils, and is installed in the lib/ldscripts
directory installed with binutils. (Other parts of it are coded in the
MSP430 include files.)
While the relocation problem may be related to something
The value of PORT1_VECTOR + VECTOR_OFFSET is an integer, which is not the
same as an addressable memory location. In gcc4, the parameter to a memory
reference has to be an lvalue.
Try something like:
asm(br %[add] :: [add] m (*(uint16_t*)(PORT1_VECTOR +
VECTOR_OFFSET)));
Peter
On Tue, Jun
to the wrong addressing mode/parameter type.
JMGross
- Ursprüngliche Nachricht -
Von: Peter Bigot
An: GCC for MSP430 - http://mspgcc.sf.net
Gesendet am: 16.Juni.2010 22:02:52
Betreff: Re: [Mspgcc-users] memory input 0 is not directly addressable
The value of PORT1_VECTOR
While this may have been the problem, be aware that there is an undocumented
(AFAIK) chip erratum on the CC430. I had programmed some boards to
immediately enter LPM5 on boot; at that point, I could no longer use the FET
over JTAG. See the threads titled *Cannot access TI MSP Experimenters board
One reason why keep it even if unreferenced may be the default even when
optimizations are enabled is that these tools (binutils, gcc) are primarily
used in environments that have far more capabilities, and couldn't care less
if a few extra kilobytes are present in the image. If you work in Linux
Excellent; thank you. With this help I've determined that the msp430
patches to gcc don't enable the check for dwarf2 support on that
architecture; as a result the compiler won't generate the line information
required for integrated listings. This is probably why another user has
complained that
Certainly you'll need an updated header. It may also be necessary to update
binutils and gcc; the 430x41x2 chips are not currently recognized as
different from the 430x41x chips, and I haven't looked into the issue enough
to estimate whether it's trivial or messy to fix this. You might be able
, Jul 2, 2010 at 8:32 PM, Robert Spanton rspan...@zepler.net wrote:
Hi Peter,
On Fri, 2010-07-02 at 10:18 -0500, Peter Bigot wrote:
Unrelated comment: For the last six months or so, I've been updating
binutils, mspgcc, and msp430-libc to support new chips.
Awesome. Have you put the code
I haven't, though
http://old.nabble.com/430X-patch:-ldiv.S,-and-strtoul-problem-td27293374.htmldescribes
a problem that might be related. My records indicate the patch
for that is in the current msp430-libc release.
Did you get mspgcc4 from deb package files somewhere, or building from
either
mspgcc4 is a port of the mspgcc tool chain to the GCC 4.x series of
compilers. It is available from SourceForge at
http://sourceforge.net/projects/mspgcc4/
I've taken over primary responsibility for maintaining mspgcc4 and its
associated patches to binutils, gcc, gdb, and the msp430-libc
I think busy is a red herring here, since the compiler optimizes it away
completely. The bug is that it doesn't respect the sequence points in the
statement list. It improperly moves the bic.b before the read of P4IN even
though the writes to P4OUT and the read of P4IN are all volatile
I believe some people are having some success using mspgcc4 and compiling
with the TI headers version of msp430-libc. There's a bug in the headers
right now that means you should include the legacy header msp430x552x.h
instead of the chip-specific one, and the compiler isn't aware of the 5529
so
(a) For a ticketing approach, might be better to create tickets on the
sourceforge project instead of emailing everybody with each one. Though I
don't know if anybody's going to maintain the how-to for the existing mspgcc
infrastructure; my preference is to leave packaging to downstream and just
behavior.
Peter
On Tue, Aug 10, 2010 at 5:48 AM, JMGross msp...@grossibaer.de wrote:
- Ursprüngliche Nachricht -
Von: Peter Bigot
Gesendet am: 10 Aug 2010 01:17:03
What I propose to do instead is reduce the machines to those required
reflect the chip CPU architecture (MSP430, MSP430X
I'm not convinced that presence of a single far pointer requires that every
address kick up to 32 bits. If near/far is maintained as an attribute on
the symbol, as apparently IAR uses a __data20 qualifier, it should be
possible to manage things properly. Whether GCC+binutils makes it
reasonably
= ?
What should the root PATH= ?
Errol
On Wed, 2010-08-11 at 18:08 -0500, Peter Bigot wrote:
(a) For a ticketing approach, might be better to create tickets on the
sourceforge project instead of emailing everybody with each one. Though I
don't know if anybody's going to maintain the how
-0500
Peter Bigot p...@peoplepowerco.com wrote:
The patch for the basic problem (bad address for infomem on newer chips) has
been submitted to mspgcc4. Once the moderator approves it it'll go in. In
the meantime, it's integrated into the next branch of the git repository
for mspgcc4
Download the source from from
http://sourceforge.net/projects/mspgcc4/files/mspgcc4/mspgcc4-20100815.tar.bz2.
Please continue to try the variant msp430-libc that uses Texas
Instruments-provided headers: this is the way of the future.
Sorry, no pre-built binaries. I'm still looking for
The -T msp430x149.x option overrides the default linker script. Does
the one you're using provide definitions for those symbols?
Try eliminating that option; it shouldn't be necessary unless you're
doing something special.
Peter
On Tue, Aug 17, 2010 at 8:54 AM, Berndt Josef Wulf
access, and possibly update the
build instructions, but mspgcc4 is referenced by the WASP project who
originated it and until their project completes I can't make changes
to what they did without breaking their documentation.
Peter
cheerio Berndt
On 18/08/10 Peter Bigot wrote:
The -T msp430x149
not tried on target yet).
Fred
Le 19 août 2010 15:35, Frédéric Sureau frederic.sur...@gmail.com a écrit :
-- Forwarded message --
From: Peter Bigot p...@peoplepowerco.com
Date: 2010/8/11
Subject: Re: [Mspgcc-users] mspgcc or mspgcc4 for a msp430f5529
To: GCC for MSP430
...@usherbrooke.ca
Hello,
I unsuccessfully modified the binutils patch and the msp430 port
source to add support for msp430f5529. On a previous thread (Re: mspgcc
or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile
line to use -mmcu=msp430x5418. The problem is the start
/mediawiki/mspgcc/index.php?title=AddingNewDeviceon
mspgcc wiki. Thats what I tried to follow :)
Thanks again and have a good day!
Alex
On 10-08-26 10:14 AM, Peter Bigot wrote:
Sorry; my suggestion was meant to trick the compiler into defining some
relevant CPU and MPY flags, and work around
You can download the latest source release of mspgcc4 (20100815, though
there should be another later today) from
http://sourceforge.net/projects/mspgcc4/. There's a MinGW.txt file in the
root directory that may help with building, if you're not using cygwin.
I don't have a good windows
New source releases for mspgcc4 are available. Download the source from from
http://sourceforge.net/projects/mspgcc4/files/mspgcc4/mspgcc4-20100829.tar.bz2.
mspgcc4 20100829 contains these changes:
- Support for following chips in binutils and gcc:
msp430x5510 msp430x5513 msp430x5514
binary format. How can convert from the gcc
output to ti txt hex file format?
Very thank's again.
Sergio
Peter Bigot wrote:
You can download the latest source release of mspgcc4 (20100815, though
there should be another later today) from
http://sourceforge.net/projects/mspgcc4/. There's
Your program builds for me using mspgcc4 release 20100829 built with
the TI header support. (Came out two days ago; this is the only
version that will support that chip. Good timing.)
msp430-gcc -mmcu=msp430x5529 q.c
Peter
On Tue, Aug 31, 2010 at 3:03 PM, Arturo Gurrola
Not a cygwin user, so I'm reaching here, but there may be a package
libcurses-devel (or libncurses-devel) that you need in order to get the
headers. This is generally the fix for this problem when it arises under
Linux.
Unless you're sure the curses.h you found matches the libncurses library, I
Go to http://www.elprotronic.com and download FET-Pro430. The Lite (free)
version has done everything I needed.
Use msp430-objcopy to convert the elf output from mspgcc to Intel hex and
program with FET-Pro430. You may need to name the file something.hex to get
FET-Pro430 to recognize it.
Best
#Installing_mspdebug_under_Mac_OS_X
On Thu, Sep 2, 2010 at 2:02 PM, Mark J. Blair n...@nf6x.net wrote:
On Sep 2, 2010, at 11:57 AM, Peter Bigot wrote:
Go to http://www.elprotronic.com and download FET-Pro430. The Lite
(free)
version has done everything I needed.
Thanks for the suggestion! I'll give that a try.
I
MA: Thanks. The patches look good, and I've merged them to the next
branch of the git repository.
MB: Help is certainly welcome. Wiki pages with updated instructions,
especially how to build (especially on windows) would address the biggest
problems; perhaps, having recently succeeded, you
Could be this:
https://sourceforge.net/tracker/?func=detailaid=3038718group_id=277223atid=1177287
Make sure you're using the latest TI headers version of msp430-libc. That
should be the ti-20100829 release.
If you are, it may be that there's another header named iomacros.h that is
being
Yes, that extra-underscore fix is in the 20100815 release.
I'm really unmotivated to continue to patch the hand-written header
files (and no, the peripherals do not stay in the same place, and it's
hard to determine where they're going to end up from general chip
family information). The TI
I'm doing the work in local git repositories that are mirrors of the
official GNU binutils and gcc ones. I'd been reluctant to push them to
sourceforge because of size, but in the end I think that's the right
solution.
The status is that I've successfully built applications with hand-crafted
completely disabled and so XPUSHM does not get defined. I don't see
how this compiles on any platform...
Neither do I. It only affects the msp3 and msp5 multilibs, which I don't
use since until last week I didn't have relevant hardware, and the Makefile
(under Linux) just blows right over
For legacy reasons, SVN is still present, but is no longer used for
maintenance. The latest version is in git. The latest stable release is
20100829. The zip and tar.bz2 files have identical content; I just don't
use windows so make it available in zip in case it's hard to deal with
tar.bz2
Got a EXP430F5438 so I can eventually do far-memory work on gcc/binutils.
Verified the hardware and MSP-FET430UIF work by using Code Composer on
Windows to install and run the User Experience. Now need this on Linux.
Using the current master of the mspdebug repository (ecccfb5), I get:
*Adding* -lc might be enough; keep -lgcc.
Peter
On Sat, Sep 25, 2010 at 2:05 PM, Peter Bigot p...@peoplepowerco.com wrote:
_unexpected_ is defined in libc.a, which you are not including.
Try using msp430-gcc instead of msp430-ld as the linker. That's usually
safer when linking code
_unexpected_ is defined in libc.a, which you are not including.
Try using msp430-gcc instead of msp430-ld as the linker. That's usually
safer when linking code compiled in higher-level languages where
language-specific runtime support is needed. (-lgcc is not sufficient in
this case. -lc
I can't help with this, not using windows or Olimex. I understand
that msp430-gdbproxy is based on proprietary code and can't be
rebuilt; it may not be compatible with current versions of gdb. I
believe mspdebug is the preferred solution.
Others on the list may be able to provide more help.
As I mentioned before, mspgcc4 does not properly prevent generation of
the routines that reference the hardware multiplier registers, even
though it does correctly categorize the 2274 as an msp1 chip that does
not have the hardware multiplier.
Unless something generates a reference to mulsi3hw,
Well, it's in stdlib as opposed to being in binutils or gcc. And has
nothing to do with hardware multiply being used in the demonstration
program. A one-line program calling printf with a format parameter shows
the problem.
Which is that when msp430-libc builds the multi-lib variants, it
New mspgcc4 release numbered 20101006 posted on
http://sourceforge.net/projects/mspgcc4/. See specific changes at
http://mspgcc4.git.sourceforge.net/git/gitweb-index.cgi.
Let me know if something that used to work doesn't anymore.
msp430-libc legacy headers:
- 6bccacf SF 3082318: c++ dislikes
That's not an ABI problem. Without a declaration available at the point of
call, C mandates that the parameter be assumed to be an int (two bytes). If
you define a function with non-int parameters, you have to have a compatible
declaration in scope wherever it's invoked. Using to mask off
Sorry, you're right: I read this too quickly.
I don't think it's an ABI problem so much as a compiler problem: it's
actually passing the 32-bit value in registers r14 and r15, instead of
truncating it to an int and passing it in r15, as it's supposed to do when
there's no declaration.
Fine. Yet
On Thu, Oct 7, 2010 at 5:49 AM, JMGross msp...@grossibaer.de wrote:
Thanks for all your work (even if I don't use mspgcc4 as it isn't ready for
critical production environment)
You're welcome. But:
In case somebody reads this and decides to avoid mspgcc4 in favor of a
supposedly
Third time's the charm? It's been so long since I've dealt with KR C I've
forgotten the rules.
The behavior is correct. char and short are upcast to int when no
declaration is in scope. Integral types that are larger than int are left
as is. That you're masking off all but the low byte does
The 247 and 249 do have different layouts, but I would have expected
mspdebug to write data to the addresses specified in the object file, but
perhaps it does something else.
If the object file is built for -mmcu=msp430x247, the text section should
start at 0x8000 and data at 0x1100. If for
|
:1081200082808A81820182810A02020082100C020E
:108133241F4292013041B2F0EFFF820182938B |
:108130200F4290013040A0128201000197
I don't know what to make of that, but it might be relevant.
Michiel
-Original Message-
From: Peter Bigot
I doubt there's any explicit support for it. Position independent code is
mostly irrelevant in embedded systems where there won't be any dynamic
loading. There are applications where one might replace code with overlays,
but those can be generally be handled with fixed addresses. I believe
a feature request ?
Fred
2010/10/19 JMGross msp...@grossibaer.de:
- Ursprüngliche Nachricht -
Von: Peter Bigot
Gesendet am: 19 Okt 2010 04:48:41
I doubt there's any explicit support for it. Position independent code
is
mostly irrelevant in embedded systems where there won't
No, that chip is not supported. File a ticket requesting support on the
mspgcc4 project and I'll add it in the next release, whenever that is. This
will impact binutils, gcc, and msp430-libc, with the only really important
stuff being in binutils (msp430all.sh needs to be updated with the
Constructors for global C++ objects should be called automatically, as long
as you're not doing something in the link phase that disrupts things. My
testing with the program below shows that it seems to work. Note that if
you fall off the end of main(), the global dtors are called.
mspgcc4 does not support more than 64KB of flash. You can probably
hand-code calls; there should be instructions somewhere on the list
archives, now available at
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/
Would somebody who has gotten the MSP430X branch of mspgcc3 to
I wonder whether it would be appropriate for this tiny patch to be applied
as part of the mspgcc4 build process?
Probably somebody included iomacros.h before including a chip-specific
header. What I think I'll do is just remove the condition in the iomacros.h
that comes with the TI header
For mspgcc4's git repository, stay on master. The changes will probably be
limited to the msp430-libc repository; if you follow that, use the
pab/ti_headers branch, as master is still used for the legacy headers.
Peter
I understand; I've been swamped at my day job, and have been putting off
Yes.
Peter
On Sun, Oct 24, 2010 at 8:47 PM, Mark J. Blair n...@nf6x.net wrote:
On Oct 24, 2010, at 6:26 PM, Peter Bigot wrote:
For mspgcc4's git repository, stay on master. The changes will probably
be
limited to the msp430-libc repository; if you follow that, use the
pab/ti_headers
The memory layout of the G2231 appears to be the same as for the F2011. Try
using -mmcu=msp430x2011 on the command line.
Version 20101006 mspgcc4, if built with the TI headers, should have an
msp430g2231.h include file. Include that file explicitly instead of
msp430.h or io.h or any of the
Alright, I've added support for the Value Line chips MSP430G2201,
MSP430G2211, MSP430G2221, and MSP430G2231. Use the standard
msp430x2201-style mcu tags. Will be in the updated release later today.
You must use the TI headers for these; they're not supported in the legacy
msp430-libc.
These are
Version 20101114 of mspgcc4 has been released. Highlighted bug fixes:
- SF 3109143: Support value-line MSP430G22x1 devices
- SF 3090697: Adding mspgcc4 support for msp430G series
- SF 3103015: Bug in strtol, implies ldiv bug
- SF 3094472: TI headers define assembler-incompatible constants
-
Historically I've worked around this by forcing the buffer to be aligned,
but that's not the right solution. I've seen other hints that mspgcc
doesn't handle non-aligned byte accesses correctly.
Based on a quick test with GCC/intel, something like this should work.
Please create a ticket on the
Two points:
1) I propose to change the list management so that email to it from people
who are not subscribed is immediately bounced (saying that the list requires
subscription for posting), rather than put into a pending bucket where Chris
or I have to look at it. If it's worth our time to
the millennium and I actually get a chance to complete the uniarch
revisions). Patches attached to bug reports are a lot easier to deal with.
Peter
On Wed, Nov 17, 2010 at 3:09 AM, Robert Spanton rspan...@zepler.net wrote:
On Tue, 2010-11-16 at 11:35 -0600, Peter Bigot wrote:
1) I propose to change
AM, Peter Bigot p...@peoplepowerco.com wrote:
Two points:
1) I propose to change the list management so that email to it from people
who are not subscribed is immediately bounced (saying that the list requires
subscription for posting), rather than put into a pending bucket where Chris
or I
Create a Bugs tracker ticket on the mspgcc4 sourceforge project and attach
your patch to that. If the changes are to the headers themselves, I may
have to push them upstream to TI.
Peter
On Fri, Nov 19, 2010 at 2:57 PM, Ben Ransford ransf...@cs.umass.edu wrote:
Hello,
What's the right way
Dunno. What does __no_init do in IAR? Or, more importantly, what does it
do in TI's example code?
Peter
On Fri, Nov 19, 2010 at 5:49 PM, Mark J. Blair n...@nf6x.net wrote:
I'm porting some TI example code which uses the __no_init keyword, and
I'm having trouble figuring out whether there's
To expand on what Chris said:
The .noinit section is an alias for the .infomemnobits section.
Using __attribute__((section(.infomem))) causes the storage for the
variable to be placed in one of the MCU's information memory blocks. In the
current implementation, there are two: .infomem is a
variables don't end up creeping in the area
reserved for USB. Yet another variation point
Peter
On Sat, Nov 20, 2010 at 2:46 PM, Chris Liechti cliec...@gmx.net wrote:
Am 20.11.2010 20:38, schrieb Peter Bigot:
To expand on what Chris said:
The .noinit section is an alias
On Sat, Nov 20, 2010 at 3:06 PM, Mark J. Blair n...@nf6x.net wrote:
On Nov 20, 2010, at 1:00 PM, Peter Bigot wrote:
I suspect assigning a specific address using asm, though, overrides this
and
makes the section irrelevant. In any case, I believe there may need to
be a
different linker
.
Peter
On Sat, Nov 20, 2010 at 3:25 PM, Mark J. Blair n...@nf6x.net wrote:
On Nov 20, 2010, at 1:15 PM, Peter Bigot wrote:
Would you mind filing a bug report asking for this (prevent use of
USB-reserved memory on relevant devices), so I don't forget it? Thanks.
No problem, I'll do
1 - 100 of 620 matches
Mail list logo
