Grant Edwards wrote:> > I don't know if there are other debuggers out there that still talk > the Angel protocol, but Embest (and their customers) might be > well-served by either implimenting the standard GDB remote protocol or > providing a daemon that translates between "GDB remote" and whatever > they do speak. >Embest don't tell you that the adapter runs angel, but I was curious about the protocol used and was looking for a way to use the adapter from Sol 10 / Gdb. The embest toolchain and ide runs on windows and is gnu based, but has what looks like a knockoff, or perhaps custom licensed Keil like ide. I just ran wireshark on the network and then found that you can telnet into the box, where all was revealed. I don't know if any other adapters still run angel, but how easy would it be to do the work to get it back into the build ?. This is coming from someone who knows nothing about gdb internals, its configuration etc, but it might be a good spare time project, given enough background info... Regards, Chris
Eclipse ARM toolchain for the Linux
Started by ●February 22, 2011
Reply by ●February 25, 20112011-02-25
Reply by ●February 25, 20112011-02-25
On 2011-02-25, ChrisQ <meru@devnull.com> wrote:>> I don't know if there are other debuggers out there that still talk >> the Angel protocol, but Embest (and their customers) might be >> well-served by either implimenting the standard GDB remote protocol >> or providing a daemon that translates between "GDB remote" and >> whatever they do speak. > > Embest don't tell you that the adapter runs angel, but I was curious > about the protocol used and was looking for a way to use the adapter > from Sol 10 / Gdb. The embest toolchain and ide runs on windows and is > gnu based, but has what looks like a knockoff, or perhaps custom > licensed Keil like ide. I just ran wireshark on the network and then > found that you can telnet into the box, where all was revealed. > > I don't know if any other adapters still run angel, but how easy > would it be to do the work to get it back into the build?I don't know. It's been 10 years since I mucked about inside gdb. If the gdb internal APIs have changed significantly, getting the RDI target stuff back in may involve a lot of work> This is coming from someone who knows nothing about gdb internals, > its configuration etc, but it might be a good spare time project, > given enough background info...If you asked on the gdb developer mailing list, somebody would probably be able explain why it was removed and what it would take to put it back in. It might actually be easier to write a daemon that translates between the gdb remote protocol and ADP (Angel Debugging Protocol). There are several reasons why that might be a better approach: 1) The GDB remote protocol is well documented and very stable. Gdb internals aren't. 2) You can use Wireshark to debug both interfaces. 3) You can use a modern, high level language (e.g. Python). The main drawbacks to a translator daemon is the increased command/response latency may have an adverse impact on performance when doing things like handling breakpoints on-the-fly. A third choice would be to add ADP support to OpenOCD. -- Grant Edwards grant.b.edwards Yow! I'm a fuschia bowling at ball somewhere in Brittany gmail.com
Reply by ●February 25, 20112011-02-25
ChrisQ <meru@devnull.com> wrote:> I'd like to develop this theme of debug adapter pricing. At the far end > of the scale, you have offerings from Abatron, which cost an > astronomical 2000 ukp here in the uk.I wouldn't mind the pricing of Abatron, Ronetix et al. if it weren't for the fact that even though they're advertised as being multi-protocol you have to pay separately for every family. Last time I found a price list for one of these devices, the additional family licenses were something like 50% of the initial cost. -a
Reply by ●February 25, 20112011-02-25
ChrisQ <meru@devnull.com> writes:> John Devereux wrote: > >> Of course openocd itself can function as a "network based debug >> adaptor". I often run it on the lab laptop with a cheap jtag pod while >> talking to it from my main development machine. > > This sound pretty good, as you could even use a pocket pc with network > and usb to provide a very compact solution. Could you give a few more > details of what software lives at each end and hints / pointers on > where to find info on configuration ?. Can do some legwork to get it > going, but have no in depth knowledge of gdb internals at all. Could > be a good spare time project.Hi Chris, sure, I have no knowlege of gdb internals either! Laptop ====== In my case the laptop has a "Amontec jtag-key" connected to it, with its drivers. There are probably dozens of other even cheaper jtag pods you can use these days. On the laptop I have openocd installed. A command line like openocd -f interface/jtag-key.cfg -f target/lpc2478.cfg -f pcb.cfg ...starts up the openocd daemon. The file pcb.cfg contains some commands specific to my hardware, for many single-chip micro targets you may not need it. There is extensive documentation in the openocd manual and an active mailing list. The openocd project web site is <http://openocd.berlios.de/web/>. From then on everything can be done from the main "desktop" machine. Desktop ======= There I have a gnu arm toolchain including arm-elf-insight. Normally for local debugging I would have a .gdbinit file including a line target remote locahost:3333 This is the usual way to tell gdb to talk to a local debug agent, e.g. a locally running openocd. This is simply changed to point to the IP address of the laptop e.g. target remote 192.168.1.123:3333 Then gdb talks to the remote copy of openocd running on the laptop. Openocd acts just like e.g. an Abatron at the same address, i.e. it speaks the gdb remote debug protocol. You can use insight to program flash, single step etc as usual. I use linux on both ends of the link, but it is basically the same for windows once you have installed your toolchain and/or openocd + jtag adapter drivers. In fact I use the same openocd configuration for a windows laptop that is used externally for board test and firmware programming. Installation / Config ===================== For windows Freddie Chopin has made available some openocd binaries <http://www.freddiechopin.info/index.php/en/download/category/4-openocd>. For linux you can compile from source. I made a local git mirror and compile from that. For the arm toolchain I use my own script to fetch+compile but the summon-arm-toolchain one looks good too. For insight I used the latest one I could find here: <ftp://sourceware.org/pub/insight/snapshots/current/>. This is still behind the latest gdb so I might have a go at building it myself, substituting the latest gdb as discussed here just now. Anyone tried that? -- John Devereux
Reply by ●February 25, 20112011-02-25
On 2011-02-25, ChrisQ <meru@devnull.com> wrote:> Simon Clubley wrote: > > Apologies, you are correct. Just checked the insight build directory and > there is a subdir labelled gdb !, so it looks like it's included as part > of insight download. I wonder what would happen if you create a new gdb > subdir, untgz a different version and run configure ?. The interesting > question would be, what's changed to prevent this working ?. >I tried that but it failed. I don't remember if it failed during the configure or the make, but I had already decided I was probably going to have to go looking for another front end at that point, so I only made a couple of attempts at making it work.> It was August 2008 and I do remember having to go back quite a way with > gcc and binutils to get a clean build under Solaris. > > Gnu software used to be so easy to build. Now you almost need a degree > in osf makefiles to do anything non standard... >:-) Although all my Internet facing machines are running current versions of Linux, I have some older boxes which are not Internet connected and run older versions of Linux, even back to RH9, as they still do the job just fine. Installing newer software on those boxes soon reveals which pieces of software have been tested against something other than a Linux distribution released in the last 6 months. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●February 25, 20112011-02-25
On 2011-02-25, David Brown <david@westcontrol.removethisbit.com> wrote:> > The cheapo debuggers are typically made from an FTDI2232 device and a > couple of level converters. These work fairly well, and it's easy to > integrate them into your own boards. There is good OpenOCD support for > a whole range of combinations of pinning on these devices.And if you are a hobbyist and want to use something even cheaper than that with a suitable ARM board, there's also the parallel port based Wiggler clones. :-) (Assuming of course you still have hardware with a real parallel port.) The Olimex one (so far) works a lot better for me than I expected. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●February 25, 20112011-02-25
On 2011-02-25, John Devereux <john@devereux.me.uk> wrote:> > For the arm toolchain I use my own script to fetch+compile but the > summon-arm-toolchain one looks good too. For insight I used the latest > one I could find here: > ><ftp://sourceware.org/pub/insight/snapshots/current/>. > > This is still behind the latest gdb so I might have a go at building it > myself, substituting the latest gdb as discussed here just now. Anyone > tried that? >Yes, but with the GDB 7.1 kit and the released Insight 6.8 kit. That combination failed, but I don't remember why and I only made a couple of attempts (as I had already decided that I was probably going to have to look for another front end) so I don't know if it was a basic incompatibility issue or a integration issue on my part. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world
Reply by ●February 25, 20112011-02-25
John Devereux wrote:> > Hi Chris, sure, I have no knowlege of gdb internals either! > > Laptop > ====== > > In my case the laptop has a "Amontec jtag-key" connected to it, with its > drivers. There are probably dozens of other even cheaper jtag pods you > can use these days. > > On the laptop I have openocd installed. A command line like > > openocd -f interface/jtag-key.cfg -f target/lpc2478.cfg -f pcb.cfg > > ...starts up the openocd daemon.So openocd is effectively standalone, input debug data at one side and usb jtag or <other> at the target hw side. Assuming a Linux / unix box,the daemon listens directly on a port, or gets called by inetd, depending on the system ?. What i'm trying to do is build a model of how all the bits fit together in terms of data flow between modules, but if the above or similar is the case, it fills in a lot of the gaps.> > The file pcb.cfg contains some commands specific to my hardware, for many > single-chip micro targets you may not need it. There is extensive > documentation in the openocd manual and an active mailing list. The > openocd project web site is <http://openocd.berlios.de/web/>. > > From then on everything can be done from the main "desktop" machine. > > Desktop > ======= > > There I have a gnu arm toolchain including arm-elf-insight. Normally for > local debugging I would have a .gdbinit file including a line > > target remote locahost:3333 > > This is the usual way to tell gdb to talk to a local debug agent, e.g. a > locally running openocd. This is simply changed to point to the IP > address of the laptop e.g. > > target remote 192.168.1.123:3333 > > Then gdb talks to the remote copy of openocd running on the > laptop. Openocd acts just like e.g. an Abatron at the same address, > i.e. it speaks the gdb remote debug protocol. You can use insight to > program flash, single step etc as usual. > > I use linux on both ends of the link, but it is basically the same for > windows once you have installed your toolchain and/or openocd + jtag > adapter drivers. In fact I use the same openocd configuration for a > windows laptop that is used externally for board test and firmware > programming. > > Installation / Config > ===================== > > For windows Freddie Chopin has made available some openocd binaries > <http://www.freddiechopin.info/index.php/en/download/category/4-openocd>. > > For linux you can compile from source. I made a local git mirror and compile > from that. > > For the arm toolchain I use my own script to fetch+compile but the > summon-arm-toolchain one looks good too. For insight I used the latest > one I could find here: > > <ftp://sourceware.org/pub/insight/snapshots/current/>. > > This is still behind the latest gdb so I might have a go at building it > myself, substituting the latest gdb as discussed here just now. Anyone > tried that? >Thanks for all that. One neat solution might be a s/hand netbook running Linux, with built in usb and net, even wireless, then use one of the lower cost usb solutions to talk to the target. Try it on an old laptop first of course, but might be fun to build for other targets, even older stuff like Sun lx, just to be perverse :-). Have printed this out, to go to file. Again, thanks... Regards, Chris
Reply by ●February 25, 20112011-02-25
On 02/25/2011 01:49 AM, Andy Sinclair wrote:> On 23/02/11 23:18, Tim Wescott wrote: >> Eclipse is always Eclipse, it has an editor that has about 98% of what I >> want in an editor (being able to select columns of data, as you can do >> in Codewrite, is really nice but not available in Eclipse), and if I >> don't get your add-ons then you can't make me do things your way. > > Eclipse finally got block selection in version 3.5 (Galileo). > > You can toggle block selection mode with Alt+Shift+A. > > AndyInteresting -- in C (and presumably C++), but not makefiles. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●February 26, 20112011-02-26
ChrisQ <meru@devnull.com> writes:> John Devereux wrote: > >> >> Hi Chris, sure, I have no knowlege of gdb internals either! >> >> Laptop >> ====== >> >> In my case the laptop has a "Amontec jtag-key" connected to it, with its >> drivers. There are probably dozens of other even cheaper jtag pods you >> can use these days. >> >> On the laptop I have openocd installed. A command line like >> >> openocd -f interface/jtag-key.cfg -f target/lpc2478.cfg -f pcb.cfg >> >> ...starts up the openocd daemon. > > > So openocd is effectively standalone, input debug data at one side and > usb jtag or <other> at the target hw side. Assuming a Linux / unix > box,the daemon listens directly on a port, or gets called by inetd, > depending on the system ?.That's right. Never tried it via inetd, I just manually start it. I have various configurations anyway for different boards/processors, so I have to tell openocd what it is talking to by using the correct command line to it. (You can also run a script from the command line to e.g. erase and program flash, when using just to flash firmware. You don't need the toolchain for that.)> What i'm trying to do is build a model of how all the bits fit together > in terms of data flow between modules, but if the above or similar is > the case, it fills in a lot of the gaps.That's it AFAIK. [...]> Thanks for all that. One neat solution might be a s/hand netbook running > Linux, with built in usb and net, even wireless, then use one of the > lower cost usb solutions to talk to the target. Try it on an old laptop > first of course, but might be fun to build for other targets, even older > stuff like Sun lx, just to be perverse :-).Absolutely, go for it! I have an old eeepc 701 that should work fine for that, it's already running debian. Here are my notes for building openocd on debian: Compiling OpenOCD for Linux =========================== Debian Prerequisites: automake libftdi-dev libusb-dev git libtool make Purge any existing installation (debian one seems to override source-compiled one) aptitude purge openocd If don't have existing copy, git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd Else just cd openocd git pull To update it. cd openocd ./bootstrap git submodule init git submodule update ./configure --enable-maintainer-mode --enable-ft2232_libftdi --enable-parport --enable-parport_ppdev --enable-amtjtagaccel --disable-shared make sudo make install (Actually I don't think the "submodule" lines above are needed any more) -- John Devereux