On Tue, Apr 22, 2014 at 1:00 PM, DJ Delorie 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 appreciate
e, Apr 22, 2014 at 06:57:55PM +,
mspgcc-users-requ...@lists.sourceforge.net placed into existence:
] Date: Tue, 22 Apr 2014 10:34:30 -0500
] From: Peter Bigot
] Subject: [Mspgcc-users] msp430-elf-gcc upcoming release
] To: "GCC for MSP430 - http://mspgcc.sf.net";
]
] Message-
> 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
On 2014-04-23, DJ Delorie 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 equiva
> 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
o
> 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
On Wed, Apr 23, 2014 at 9:57 AM, Grant Edwards
wrote:
> On 2014-04-23, Peter Bigot 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
On 2014-04-23, Peter Bigot 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.
>
> This works
On Wed, Apr 23, 2014 at 02:14:32PM +, Grant Edwards placed into existence:
] On 2014-04-22, DJ Delorie 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:/
On Wed, Apr 23, 2014 at 9:14 AM, Grant Edwards
wrote:
> On 2014-04-22, DJ Delorie 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/new
On 2014-04-22, DJ Delorie 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 prov
> 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
On Tue, Apr 22, 2014 at 4:53 PM, Grant Edwards
wrote:
> On 2014-04-22, Peter Bigot 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
On Tue, Apr 22, 2014 at 5:00 PM, Daniel Beer 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 possib
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 2014-04-22, Peter Bigot 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 mode) and
> > 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
somet
On Tue, Apr 22, 2014 at 1:00 PM, DJ Delorie wrote:
>
>> * 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 wer
> * 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 sub-scri
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 git://sourceware.org/git/
20 matches
Mail list logo
