GCC/ARM 4.7.0 for Windows

Started by Olivier Gautherot May 9, 2012
Hi,

for those interested, I have a working copy of GCC/ARM 4.7.0 and GDB
7.4. They seem to have improved the code optimization, from what I saw
on a sample app. The distributionis based on the YAGARTO building
scripts - I still owe the patches to Michael Fischer. I compiled the
toolchain under MinGW and added the requested libraries, so that it can
be used from a standard DOS box.

Cheers
Olivier
--

Olivier Gautherot
*Email:* o...@gautherot.net
*Cel:* +56 98 730 9361
*Web:* www.gautherot.net
*LinkedIn:* http://www.linkedin.com/in/ogautherot



An Engineer's Guide to the LPC2100 Series

Hi Oliver

May I have a copy?

regards

Nataraj S Narayan

On Thu, May 10, 2012 at 6:55 AM, Olivier Gautherot wrote:

> **
> Hi,
>
> for those interested, I have a working copy of GCC/ARM 4.7.0 and GDB
> 7.4. They seem to have improved the code optimization, from what I saw
> on a sample app. The distributionis based on the YAGARTO building
> scripts - I still owe the patches to Michael Fischer. I compiled the
> toolchain under MinGW and added the requested libraries, so that it can
> be used from a standard DOS box.
>
> Cheers
> Olivier
> --
>
> Olivier Gautherot
> *Email:* o...@gautherot.net
> *Cel:* +56 98 730 9361
> *Web:* www.gautherot.net
> *LinkedIn:* http://www.linkedin.com/in/ogautherot
>
>
>
>
>


Il 10/05/2012 03:25, Olivier Gautherot ha scritto:
>
>
> Hi,
>
> for those interested, I have a working copy of GCC/ARM 4.7.0 and GDB
> 7.4. They seem to have improved the code optimization, from what I saw
> on a sample app. The distributionis based on the YAGARTO building
> scripts - I still owe the patches to Michael Fischer. I compiled the
> toolchain under MinGW and added the requested libraries, so that it can
> be used from a standard DOS box.
>
Nice information.
Good work Olivier.
> Cheers
> Olivier
> --
>
> Olivier Gautherot
> *Email:* o...@gautherot.net
> *Cel:* +56 98 730 9361
> *Web:* www.gautherot.net
> *LinkedIn:* http://www.linkedin.com/in/ogautherot
>
>



Hi Nataraj,

I've loaded it here:
http://www.gautherot.net/doku.php?id=firmware:homeprogramming
(I'll add the scripts during the day)

Cheers
Olivier
Nataraj S Narayan wrote:
> Hi Oliver
>
> May I have a copy?
>
> regards
>
> Nataraj S Narayan
>
> On Thu, May 10, 2012 at 6:55 AM, Olivier Gautherotwrote:
>
>> **
>> Hi,
>>
>> for those interested, I have a working copy of GCC/ARM 4.7.0 and GDB
>> 7.4. They seem to have improved the code optimization, from what I saw
>> on a sample app. The distributionis based on the YAGARTO building
>> scripts - I still owe the patches to Michael Fischer. I compiled the
>> toolchain under MinGW and added the requested libraries, so that it can
>> be used from a standard DOS box.
>>
>> Cheers
>> Olivier
>> --
>>
>> Olivier Gautherot
>> *Email:* o...@gautherot.net
>> *Cel:* +56 98 730 9361
>> *Web:* www.gautherot.net
>> *LinkedIn:* http://www.linkedin.com/in/ogautherot
>>
>>
>>
>
>
Hi Olivier,

I'm thinking over creating an opensource, plugin based IDE using Qt, with
JTAG debugging support using FTDI's FT2232.

Sounds interesting ??

cheers !!
Rakesh Ranjan
On Thu, May 10, 2012 at 5:39 PM, Olivier Gautherot wrote:

> **
> Hi Nataraj,
>
> I've loaded it here:
> http://www.gautherot.net/doku.php?id=firmware:homeprogramming
> (I'll add the scripts during the day)
>
> Cheers
> Olivier
> Nataraj S Narayan wrote:
> > Hi Oliver
> >
> > May I have a copy?
> >
> > regards
> >
> > Nataraj S Narayan
> >
> > On Thu, May 10, 2012 at 6:55 AM, Olivier Gautherot > >wrote:
> >
> >> **
> >>
> >>
> >> Hi,
> >>
> >> for those interested, I have a working copy of GCC/ARM 4.7.0 and GDB
> >> 7.4. They seem to have improved the code optimization, from what I saw
> >> on a sample app. The distributionis based on the YAGARTO building
> >> scripts - I still owe the patches to Michael Fischer. I compiled the
> >> toolchain under MinGW and added the requested libraries, so that it can
> >> be used from a standard DOS box.
> >>
> >> Cheers
> >> Olivier
> >> --
> >>
> >> Olivier Gautherot
> >> *Email:* o...@gautherot.net
> >> *Cel:* +56 98 730 9361
> >> *Web:* www.gautherot.net
> >> *LinkedIn:* http://www.linkedin.com/in/ogautherot
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
On Mon, May 14, 2012 at 7:41 AM, rakesh ranjan wrote:

> Hi Olivier,
>
> I'm thinking over creating an opensource, plugin based IDE using Qt, with
> JTAG debugging support using FTDI's FT2232.
>
> Sounds interesting ??
>
> cheers !!
> Rakesh Ranjan
>
> Why would you do that? There is plenty of IDEs out there already, you just
have to choose the right one. I'm using Code::Blocks for everything (for
Windows, for Linux, for ARM, for PIC, for 8051). It supports GDB but I
never used it with JTAG. I think it's better to enhance some existent IDE
than to create a new one from scratch.

--
Best regards,
Mario.


Hi Mario,

Sounds good to me too :)
Any pointers on IDE that could be enhanced to integrate JTAG debugging (
OpenOCD ) ??

cheers !!
Rakesh
On Mon, May 14, 2012 at 11:20 AM, Mario Ivancic wrote:

> **
> On Mon, May 14, 2012 at 7:41 AM, rakesh ranjan > >wrote:
> > Hi Olivier,
> >
> > I'm thinking over creating an opensource, plugin based IDE using Qt, with
> > JTAG debugging support using FTDI's FT2232.
> >
> > Sounds interesting ??
> >
> > cheers !!
> > Rakesh Ranjan
> >
> > Why would you do that? There is plenty of IDEs out there already, you
> just
> have to choose the right one. I'm using Code::Blocks for everything (for
> Windows, for Linux, for ARM, for PIC, for 8051). It supports GDB but I
> never used it with JTAG. I think it's better to enhance some existent IDE
> than to create a new one from scratch.
>
> --
> Best regards,
> Mario.
>
>
>
>


Having written a target interface for GDB in the past I really wouldn't
recommend that approach.
Because of the way GDB interfaces with the IDE and the 1ms latency for USB
you are limited by the way in which GDB sends commands. When the CPU is
halted each request from the GUI for a variable to display has to be
serviced before the next request is sent and latency is more important than
actual target interface speed.
You can get a much bigger improvement in speed by having a local
microprocessor that performs speculative reads and caches the result
returning data to GDB from the cache whenever possible.

The best way to do this is use a microcontroller to locally perform the JTAG
interface and a clever target interface stub for GDB that locally caches the
read data so that it can return results to GDB immediately if the processor
has not been stepped since the last fetch.

That way when displaying structures after a single step the individual
fetches that are generates by GDB do not need to be transferred over USB,
only each non-contiguous fetch.

A few years ago I worked on the Leon ( SPARC based microcontroller ) using
serial debug, the speed of stepping using a local serial port was orders of
magnitude faster than using a USB based serial port even though the USB port
was running 4x faster, the bottleneck is the USB latency.

Coding in this way made even the USB interface orders of magnitude faster
than using a local serial port.

The problem is partly caused by the way the GUI integrates to GDB, but
caching data in target interface this way hides that affect, particularly
for C++ and for structure display where it is much more likely that
variables being displayed are adjacent in memory.

Regards

Phil.
-----Original Message-----
From: l... [mailto:l...] On Behalf Of
rakesh ranjan
Sent: 14 May 2012 06:41
To: l...
Subject: Re: [lpc2000] GCC/ARM 4.7.0 for Windows

Hi Olivier,

I'm thinking over creating an opensource, plugin based IDE using Qt, with
JTAG debugging support using FTDI's FT2232.

Sounds interesting ??

cheers !!
Rakesh Ranjan
On Thu, May 10, 2012 at 5:39 PM, Olivier Gautherot
wrote:

> **
> Hi Nataraj,
>
> I've loaded it here:
> http://www.gautherot.net/doku.php?id=firmware:homeprogramming
> (I'll add the scripts during the day)
>
> Cheers
> Olivier
> Nataraj S Narayan wrote:
> > Hi Oliver
> >
> > May I have a copy?
> >
> > regards
> >
> > Nataraj S Narayan
> >
> > On Thu, May 10, 2012 at 6:55 AM, Olivier
> >Gautherot > >wrote:
> >
> >> **
> >>
> >>
> >> Hi,
> >>
> >> for those interested, I have a working copy of GCC/ARM 4.7.0 and
> >> GDB 7.4. They seem to have improved the code optimization, from
> >> what I saw on a sample app. The distributionis based on the YAGARTO
> >> building scripts - I still owe the patches to Michael Fischer. I
> >> compiled the toolchain under MinGW and added the requested
> >> libraries, so that it can be used from a standard DOS box.
> >>
> >> Cheers
> >> Olivier
> >> --
> >>
> >> Olivier Gautherot
> >> *Email:* o...@gautherot.net
> >> *Cel:* +56 98 730 9361
> >> *Web:* www.gautherot.net
> >> *LinkedIn:* http://www.linkedin.com/in/ogautherot
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
Hi Phil,

I really appreciate your help and insight.

I'm aiming at something like insight debugger within the IDE something on
the lines of Qt Creator.

i plan this to be a low cost solution primarily for educational use, for
the introductory lessons on JTAG debugging etc. I'm sure the 1ms latency
would not be an issue for me at all.
Can you suggest me something that i need to read to implement such an
interface to GDB, such that it can be hooked up with a GUI.
best regards
rakesh

On Mon, May 14, 2012 at 12:13 PM, Phil Young wrote:

> **
> Having written a target interface for GDB in the past I really wouldn't
> recommend that approach.
> Because of the way GDB interfaces with the IDE and the 1ms latency for USB
> you are limited by the way in which GDB sends commands. When the CPU is
> halted each request from the GUI for a variable to display has to be
> serviced before the next request is sent and latency is more important than
> actual target interface speed.
> You can get a much bigger improvement in speed by having a local
> microprocessor that performs speculative reads and caches the result
> returning data to GDB from the cache whenever possible.
>
> The best way to do this is use a microcontroller to locally perform the
> JTAG
> interface and a clever target interface stub for GDB that locally caches
> the
> read data so that it can return results to GDB immediately if the processor
> has not been stepped since the last fetch.
>
> That way when displaying structures after a single step the individual
> fetches that are generates by GDB do not need to be transferred over USB,
> only each non-contiguous fetch.
>
> A few years ago I worked on the Leon ( SPARC based microcontroller ) using
> serial debug, the speed of stepping using a local serial port was orders of
> magnitude faster than using a USB based serial port even though the USB
> port
> was running 4x faster, the bottleneck is the USB latency.
>
> Coding in this way made even the USB interface orders of magnitude faster
> than using a local serial port.
>
> The problem is partly caused by the way the GUI integrates to GDB, but
> caching data in target interface this way hides that affect, particularly
> for C++ and for structure display where it is much more likely that
> variables being displayed are adjacent in memory.
>
> Regards
>
> Phil.
> -----Original Message-----
> From: l... [mailto:l...] On Behalf
> Of
> rakesh ranjan
> Sent: 14 May 2012 06:41
> To: l...
> Subject: Re: [lpc2000] GCC/ARM 4.7.0 for Windows
>
> Hi Olivier,
>
> I'm thinking over creating an opensource, plugin based IDE using Qt, with
> JTAG debugging support using FTDI's FT2232.
>
> Sounds interesting ??
>
> cheers !!
> Rakesh Ranjan
>
> On Thu, May 10, 2012 at 5:39 PM, Olivier Gautherot
> wrote:
>
> > **
>
> >
> >
> > Hi Nataraj,
> >
> > I've loaded it here:
> > http://www.gautherot.net/doku.php?id=firmware:homeprogramming
> > (I'll add the scripts during the day)
> >
> > Cheers
> > Olivier
> >
> >
> > Nataraj S Narayan wrote:
> > > Hi Oliver
> > >
> > > May I have a copy?
> > >
> > > regards
> > >
> > > Nataraj S Narayan
> > >
> > > On Thu, May 10, 2012 at 6:55 AM, Olivier
> > >Gautherot > > >wrote:
> > >
> > >> **
> > >>
> > >>
> > >> Hi,
> > >>
> > >> for those interested, I have a working copy of GCC/ARM 4.7.0 and
> > >> GDB 7.4. They seem to have improved the code optimization, from
> > >> what I saw on a sample app. The distributionis based on the YAGARTO
> > >> building scripts - I still owe the patches to Michael Fischer. I
> > >> compiled the toolchain under MinGW and added the requested
> > >> libraries, so that it can be used from a standard DOS box.
> > >>
> > >> Cheers
> > >> Olivier
> > >> --
> > >>
> > >> Olivier Gautherot
> > >> *Email:* o...@gautherot.net
> > >> *Cel:* +56 98 730 9361
> > >> *Web:* www.gautherot.net
> > >> *LinkedIn:* http://www.linkedin.com/in/ogautherot
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
Il 14/05/2012 10:54, rakesh ranjan ha scritto:
> Hi Phil,
>
> I really appreciate your help and insight.
>
> I'm aiming at something like insight debugger within the IDE something on
> the lines of Qt Creator.
>
> i plan this to be a low cost solution primarily for educational use, for
> the introductory lessons on JTAG debugging etc. I'm sure the 1ms latency
> would not be an issue for me at all.
> Can you suggest me something that i need to read to implement such an
> interface to GDB, such that it can be hooked up with a GUI.
Why don't use or collaborate in an already existing open source project
instead of re-inventing the wheel?
Eclipse, Codelite and others may be a good starting point.
> best regards
> rakesh
> On Mon, May 14, 2012 at 12:13 PM, Phil Young wrote:
>
>> **
>> Having written a target interface for GDB in the past I really wouldn't
>> recommend that approach.
>> Because of the way GDB interfaces with the IDE and the 1ms latency for USB
>> you are limited by the way in which GDB sends commands. When the CPU is
>> halted each request from the GUI for a variable to display has to be
>> serviced before the next request is sent and latency is more important than
>> actual target interface speed.
>> You can get a much bigger improvement in speed by having a local
>> microprocessor that performs speculative reads and caches the result
>> returning data to GDB from the cache whenever possible.
>>
>> The best way to do this is use a microcontroller to locally perform the
>> JTAG
>> interface and a clever target interface stub for GDB that locally caches
>> the
>> read data so that it can return results to GDB immediately if the processor
>> has not been stepped since the last fetch.
>>
>> That way when displaying structures after a single step the individual
>> fetches that are generates by GDB do not need to be transferred over USB,
>> only each non-contiguous fetch.
>>
>> A few years ago I worked on the Leon ( SPARC based microcontroller ) using
>> serial debug, the speed of stepping using a local serial port was orders of
>> magnitude faster than using a USB based serial port even though the USB
>> port
>> was running 4x faster, the bottleneck is the USB latency.
>>
>> Coding in this way made even the USB interface orders of magnitude faster
>> than using a local serial port.
>>
>> The problem is partly caused by the way the GUI integrates to GDB, but
>> caching data in target interface this way hides that affect, particularly
>> for C++ and for structure display where it is much more likely that
>> variables being displayed are adjacent in memory.
>>
>> Regards
>>
>> Phil.
>> -----Original Message-----
>> From: l... [mailto:l...] On Behalf
>> Of
>> rakesh ranjan
>> Sent: 14 May 2012 06:41
>> To: l...
>> Subject: Re: [lpc2000] GCC/ARM 4.7.0 for Windows
>>
>> Hi Olivier,
>>
>> I'm thinking over creating an opensource, plugin based IDE using Qt, with
>> JTAG debugging support using FTDI's FT2232.
>>
>> Sounds interesting ??
>>
>> cheers !!
>> Rakesh Ranjan
>>
>> On Thu, May 10, 2012 at 5:39 PM, Olivier Gautherot
>> wrote:
>>
>>> **
>>>
>>> Hi Nataraj,
>>>
>>> I've loaded it here:
>>> http://www.gautherot.net/doku.php?id=firmware:homeprogramming
>>> (I'll add the scripts during the day)
>>>
>>> Cheers
>>> Olivier
>>>
>>>
>>> Nataraj S Narayan wrote:
>>>> Hi Oliver
>>>>
>>>> May I have a copy?
>>>>
>>>> regards
>>>>
>>>> Nataraj S Narayan
>>>>
>>>> On Thu, May 10, 2012 at 6:55 AM, Olivier
>>>> Gautherot >>>> wrote:
>>>>
>>>>> **
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> for those interested, I have a working copy of GCC/ARM 4.7.0 and
>>>>> GDB 7.4. They seem to have improved the code optimization, from
>>>>> what I saw on a sample app. The distributionis based on the YAGARTO
>>>>> building scripts - I still owe the patches to Michael Fischer. I
>>>>> compiled the toolchain under MinGW and added the requested
>>>>> libraries, so that it can be used from a standard DOS box.
>>>>>
>>>>> Cheers
>>>>> Olivier
>>>>> --
>>>>>
>>>>> Olivier Gautherot
>>>>> *Email:* o...@gautherot.net
>>>>> *Cel:* +56 98 730 9361
>>>>> *Web:* www.gautherot.net
>>>>> *LinkedIn:* http://www.linkedin.com/in/ogautherot
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>