On Tue, Apr 22, 2014 at 1:00 PM, DJ Delorie d...@redhat.com wrote:
* __delay_cycles() didn't get back-ported from the version that TI
published back in December
My bad. I can provide it if anyone needs it, but I'll see about
adding it to the 4.9 branch.
Any idea when this might happen? I
On 2014-04-22, DJ Delorie d...@redhat.com wrote:
I was surprised to see DJ's comment that there actually was no
standard system interface; the standard interface I was referring to
is the one documented at http://neptune.billgatliff.com/newlib.html
The key to a successfully ported newlib is
On Wed, Apr 23, 2014 at 9:14 AM, Grant Edwards
grant.b.edwa...@gmail.com wrote:
On 2014-04-22, DJ Delorie d...@redhat.com wrote:
I was surprised to see DJ's comment that there actually was no
standard system interface; the standard interface I was referring to
is the one documented at
On Wed, Apr 23, 2014 at 02:14:32PM +, Grant Edwards placed into existence:
] On 2014-04-22, DJ Delorie d...@redhat.com wrote:
]
] I was surprised to see DJ's comment that there actually was no
] standard system interface; the standard interface I was referring to
] is the one documented at
On 2014-04-23, Peter Bigot big...@acm.org wrote:
Again: whatever the environment wants it to do. In my case, I'm
using printf(3c) in my code, and I want it to output to one of the
UARTs, which newlib accommodates by using write(2) to descriptor 1,
just like any other standard C library.
On Wed, Apr 23, 2014 at 9:57 AM, Grant Edwards
grant.b.edwa...@gmail.com wrote:
On 2014-04-23, Peter Bigot big...@acm.org wrote:
Again: whatever the environment wants it to do. In my case, I'm
using printf(3c) in my code, and I want it to output to one of the
UARTs, which newlib accommodates
So I'm guessing DJ implemented a default hardware I/O implementation in
libgloss
that uses the CIO infrastructure (no idea what that is, but I'm guessing it
uses
the JTAG Mailbox system somehow to talk with the debugger host? in which case
I'd love to play with it that... assuming
But it's not called like a normal C function, it goes through some
sort of syscall interface so you don't actually link your _write()
function with newlib?
It *is* called like a normal C function. You really do just link
libgloss.a (or your equivalent) in with your app like you would any
On 2014-04-23, DJ Delorie d...@redhat.com wrote:
But it's not called like a normal C function, it goes through some
sort of syscall interface so you don't actually link your _write()
function with newlib?
It *is* called like a normal C function. You really do just link
libgloss.a (or your
I see. I guess to me a syscall interface implies something other
than a normal C function call to a function that's linked with the
caller.
It does to me too. The *implementation* of those standard C functions
may involve some sort of interface that's known to the
debugger/simulator as
+,
mspgcc-users-requ...@lists.sourceforge.net placed into existence:
] Date: Tue, 22 Apr 2014 10:34:30 -0500
] From: Peter Bigot big...@acm.org
] Subject: [Mspgcc-users] msp430-elf-gcc upcoming release
] To: GCC for MSP430 - http://mspgcc.sf.net;
] mspgcc-users@lists.sourceforge.net
Back in mid April GCC forked off a branch for 4.9.0, which will be the
first release of GCC that supports the MSP430. I've verified basic
functionality with:
binutils git://sourceware.org/git/binutils-gdb.git master
gcc git://gcc.gnu.org/git/gcc.git gcc-4_9-branch
newlib
* The only headers/linker scripts available are from
GCC_RH_20131206.zip; memory.ld and peripherals.ld for each MCU need to
be manually combined to get something binutils can process
Hmmm... I was under the impression that there were toplevel
chip-specific scripts that included the
It uses the TI CIO interface.
Interesting; is there any public documentation on how to use that?
Not that I know of.
An option to build MSP430 newlib with the standard system interface
would be even better.
I don't know of a standard interface. Each chip I've done has done
something a
On 2014-04-22, Peter Bigot big...@acm.org wrote:
I expect there'll be some issues with newlib as well; it appears to
use a unique syscall interface that I haven't tried to reverse
engineer.
I don't understand. A syscall API is usually the interface between
libc code (which is running in user
On Tue, Apr 22, 2014 at 10:34:30AM -0500, Peter Bigot wrote:
msp430-elf-gdb also doesn't appear to work with mspdebug:
(gdb) target remote :2000
Remote debugging using :2000
Reply contains invalid hex digit 59
I have a possible fix for this, but I haven't tried it myself. The
problem is
On Tue, Apr 22, 2014 at 5:00 PM, Daniel Beer dlb...@gmail.com wrote:
On Tue, Apr 22, 2014 at 10:34:30AM -0500, Peter Bigot wrote:
msp430-elf-gdb also doesn't appear to work with mspdebug:
(gdb) target remote :2000
Remote debugging using :2000
Reply contains invalid hex digit 59
I have a
On Tue, Apr 22, 2014 at 4:53 PM, Grant Edwards
grant.b.edwa...@gmail.com wrote:
On 2014-04-22, Peter Bigot big...@acm.org wrote:
I expect there'll be some issues with newlib as well; it appears to
use a unique syscall interface that I haven't tried to reverse
engineer.
I don't understand.
I was surprised to see DJ's comment that there actually was no
standard system interface; the standard interface I was referring to
is the one documented at http://neptune.billgatliff.com/newlib.html
The key to a successfully ported newlib is providing stubs that
bridge the gap between the
19 matches
Mail list logo
