EmbeddedRelated.com
Forums

Replace Keil/ARM tools

Started by MK May 14, 2014
On 2014-05-16, David Brown <david.brown@hesbynett.no> wrote:
> On 16/05/14 02:17, Grant Edwards wrote: >> >> Yep. There are a variety of frontends for gdb: Eclipse, DDD, emacs, >> KDbg, and a handful of others whose names escape me. [Is the Tcl/Tk >> based one that used to be "included" with gdb sources still around?].
There's also a character cell frontend as well at: http://cgdb.github.io/
> > You mean "Insight"? I believe it is no longer included in modern gdb, > and the last version of gdb with Insight does not work with the latest > version of OpenOCD as it supports newer methods of talking to gdb.
Insight was indeed a separate project in recent years and it's development stalled at gdb 6.8. The website is: http://www.sourceware.org/insight/ As you say, the major disadvantage of Insight is that it's tightly bound to the gdb source instead of the more typical communication via a gdb protocol you have with the other GDB frontends. (IIRC, Insight also came with it's own copy of the gdb source). That makes it unusable with later gdb versions and I switched to using ddd which works ok for my needs. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
On 16/05/14 13:54, Simon Clubley wrote:
> On 2014-05-16, David Brown <david.brown@hesbynett.no> wrote: >> On 16/05/14 02:17, Grant Edwards wrote: >>> >>> Yep. There are a variety of frontends for gdb: Eclipse, DDD, emacs, >>> KDbg, and a handful of others whose names escape me. [Is the Tcl/Tk >>> based one that used to be "included" with gdb sources still around?]. > > There's also a character cell frontend as well at: > > http://cgdb.github.io/
That looks nice. I sometimes like to use gdb from the command line for speed and convenience - a bit of colour would be pretty. Thanks for the tip.
> >> >> You mean "Insight"? I believe it is no longer included in modern gdb, >> and the last version of gdb with Insight does not work with the latest >> version of OpenOCD as it supports newer methods of talking to gdb. > > Insight was indeed a separate project in recent years and it's > development stalled at gdb 6.8. The website is: > > http://www.sourceware.org/insight/ > > As you say, the major disadvantage of Insight is that it's tightly bound > to the gdb source instead of the more typical communication via a gdb > protocol you have with the other GDB frontends. (IIRC, Insight also > came with it's own copy of the gdb source). > > That makes it unusable with later gdb versions and I switched to using > ddd which works ok for my needs. > > Simon. >
On 2014-05-16, David Brown <david.brown@hesbynett.no> wrote:

>> Yep. There are a variety of frontends for gdb: Eclipse, DDD, emacs, >> KDbg, and a handful of others whose names escape me. [Is the Tcl/Tk >> based one that used to be "included" with gdb sources still around?]. > > You mean "Insight"?
Yes, that's it.
> I believe it is no longer included in modern gdb,
That's what I thought. I usually use gdb from command line or emacs, but very occasionally when working on startup code I used to use Insight because it made it simple to watch register and a block of memory change as you single-step through assembly language. Other debuggers provide the same thing, but back then Insight was sort of "built in", so that's what I used.
> and the last version of gdb with Insight does not work with the > latest version of OpenOCD as it supports newer methods of talking to > gdb. That's the disadvantage of having the gui tied into gdb itself.
Definitly.
> There are a number of other IDEs that support debugging via gdb, such as > jedit and Code Blocks, as well as gvd (I used to like that one) which is > part of GPS, the GNAT Programming System for those that like Ada on > their ARMs.
I've always wanted to try Ada on an embedded system, but never got around to it. About 30 years ago I spent a tiny amount of time working with Ada for a 16-bit Navy CPU, and the dev environment was horrible. It ran on on VAX/VMS, but the Ada environment was completely stand-alone: it didn't even use the host filesystem directly. it had it's own editor and filesystem, and it was miserable. -- Grant Edwards grant.b.edwards Yow! The FALAFEL SANDWICH at lands on my HEAD and I gmail.com become a VEGETARIAN ...
On 2014-05-16, MK <mk@nospam.co.uk> wrote:
> On 15/05/2014 15:07, Anders.Montonen@kapsi.spam.stop.fi.invalid wrote: >> MK <mk@nospam.co.uk> wrote: >>> We had seen the odd hard fault and today pinned it down - the UART >>> driver is GARBAGE ! It uses a circular buffer and will fall over (hard >>> fault the processor) every time an incoming message wraps round the end >>> of the buffer. We didn't see it at first because the device sending data >>> happens to use 8 byte packets but as soon as we started real testing for >>> exceptions the fault was obvious. >> >> Is the driver actually Keil's handiwork, or was it part of the chip >> vendor's support libraries? I haven't used MDK5, but in previous >> versions most of the bundled support software was simply the same >> libraries you could grab from the chip vendor's website (except slightly >> outdated). The quality of those libraries can be... /varying/. >> >> -a >> > The driver file in question says: > > * Copyright (C) 2013 ARM Limited. All rights reserved.
Ding, ding, ding: you lose! Never, never, never, ever use any software (development tools or target source) written by a silicon/chip vendor/designer. They are _all_ incompetent when it comes to software.
> at the top of the file so it can't be blamed on ST !
I'd be very wary of using anything from ST either... -- Grant Edwards grant.b.edwards Yow! I haven't been married at in over six years, but we gmail.com had sexual counseling every day from Oral Roberts!!
On Fri, 16 May 2014 09:43:20 +0100, MK <mk@nospam.co.uk> wrote:


>Rowley has got pricey ($1500 per seat, $300 for a Ulink like debug >interface that you can get for $25 from Amazon) and CodeSourcery seems >to be $1000 - $3000+ depending on edition.
CrossWorks works well with Rowley's own JTAG but it also supports many of the other "usual suspects" out there, including Segger's J-LINK and the $25 interface plus quite a few that I've never heard of before. An Olimex ARM-USB-JTAG is a little slow but it works fine otherwise; I use one at home when the rest of the kit is on the bench at work.
Grant Edwards wrote:

> Never, never, never, ever use any software (development tools or > target source) written by a silicon/chip vendor/designer. They are > _all_ incompetent when it comes to software. >
[ ... ]
> I'd be very wary of using anything from ST either...
I've been using ST supplied libraries like STM32F4xx_StdPeriph_Driver, up to now only in prototypes. At that level, they've worked OK so far. It seemed like a quick way to a running program, OTOH, it's a different level of API to learn above the vital hardware register level, and using it to substitute for knowing the hardware is risky. About the 3rd thing I had to do was write my own function for full-duplex SPI, adapted to the API idiom. That idiom imposes a thin layer of complication all its own. And it doesn't do one thing I really want it for: parameterizing the choice of resources like UARTS, SPI ports, I2C, and so on. Once these get distributed among different peripheral buses, you may have to change quite a few setup function calls if you change your mind. C++ could probably implement this in some horribly opaque way, but ... that would be C++. Mel. P.S. Hardware guys' C code is a whole other area, whither I will not go. I'll just accept their hardware contributions and be happy.
On 16/05/2014 15:56, Rich Webb wrote:
> On Fri, 16 May 2014 09:43:20 +0100, MK <mk@nospam.co.uk> wrote: > > >> Rowley has got pricey ($1500 per seat, $300 for a Ulink like debug >> interface that you can get for $25 from Amazon) and CodeSourcery seems >> to be $1000 - $3000+ depending on edition. > > CrossWorks works well with Rowley's own JTAG but it also supports many > of the other "usual suspects" out there, including Segger's J-LINK and > the $25 interface plus quite a few that I've never heard of before. An > Olimex ARM-USB-JTAG is a little slow but it works fine otherwise; I > use one at home when the rest of the kit is on the bench at work.
I compromised with an Olimex one that works for the most part with Crosworks for an NXP device. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
On 16/05/2014 01:17, Grant Edwards wrote:
> A few years ago I remember hearing a lot of good things about Rowley > CrossWorks (gcc/binutils ARM toolchain with proprietary debugger and > libraries).
Rowley is terrific. Takes away the guesswork, flattens the learning curve. And it works.
On 16/05/2014 19:52, Tim wrote:
> On 16/05/2014 01:17, Grant Edwards wrote: >> A few years ago I remember hearing a lot of good things about Rowley >> CrossWorks (gcc/binutils ARM toolchain with proprietary debugger and >> libraries). > > Rowley is terrific. Takes away the guesswork, flattens the learning > curve. And it works.
I have to agree, it works straight out of the box and you get good support. However, I was peeved when in Rowley's very early days they promised lifetime updates. Of course it went from version 1.7 to 2.0, and I was told I had died and was no longer eligible for updates, or something like that. Sort of rankled with me. I then moved to the STM32 devices and there us a wealth of open source support plus libraries. I started with Yagarto but this was made obsolete by GCC-ARM tools. Coupled with Eclipse, OpenOCD (though reverted back to 0.6.0 due to bugs) I feel I have a pleasant and effective IDE. One very significant point of using open sourced tools is that you can set all this up on your customer's PC as a mirror of my own system without any issues of dongles or magic codes. Where the customer is also free to make his own mods and changes to his code. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
On 2014-05-16, David Brown <david.brown@hesbynett.no> wrote:
> On 16/05/14 13:54, Simon Clubley wrote: >> >> There's also a character cell frontend as well at: >> >> http://cgdb.github.io/ > > That looks nice. I sometimes like to use gdb from the command line for > speed and convenience - a bit of colour would be pretty. Thanks for the > tip. >
You are welcome. Be warned however, I've only played with it briefly back from when I was evaluating frontend alternatives to Insight and my notes from that time (I've just re-read them) say I considered it to be too limiting for my requirements. It appears I stopped the evaluation when I had trouble while trying to debug Ada code. My notes are also silent on the subject of remote target debugging support and whether I could easily switch between various cross-compiled and native gdb builds (as you can with ddd by using a option on the ddd command line). Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world