Re: [Openocd-development] Embedding OpenOCD on low endmicrocontroller.

[Martín Sebastián Baudino]

After reading all of your posts you've convinced me that Linux is the way
to go and
I think we're going to try to use a BeagleBord. The ZY1000 looks really
cool, but I
think that for now it would be much more than we need.

I had also thought about using either SPI or GPIO, but now I'm thinking that
if we are
buying a BeagleBoard, we might as well try to make it work with a USB dongle
and
therefore avoid the use of level shifters.

I want to thank everyone for your help, I'll try to keep you posted as I
advance and I
promise to ask for your advice for the OpenGL JTAG animations :-)

Martín
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Embedding OpenOCD on low endmicrocontroller.

[Nico Coesel]

 -Original Message-
 From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
 development-boun...@lists.berlios.de] On Behalf Of David Brownell
 Sent: zaterdag 14 november 2009 20:26
 To: openocd-development@lists.berlios.de
 Subject: Re: [Openocd-development] Embedding OpenOCD on low
 endmicrocontroller.
 
 On Friday 13 November 2009, Martín Sebastián Baudino wrote:
  But now I'm been asked to look at the code and see if it is possible to
  actually embed it on an STR7 board, which we use to automatically test
 other
  boards. Our goal would be (for now) to just flash another ARM
  microcontroller with a small program, to test some peripherals like UARTs
  and SPIs.
 
  At first hand, I don't see this as a trivial task, and I'd like to ask for
  your advice, since you know the code and are surely more experienced with
 it
  than I am.
 
 I think you'll find that OpenOCD relies on a bunch of other
 infrastructure, and you'd need to start by finding what parts
 of that already exist.  TCP networking, file system access,
 and I/O to the JTAG adapter are places to start.
 
 As noted already, one trivial solution is to build on top
 of Linux.  You would have a little work to drive the JTAG

Linux is the way to go. Altough you might be able to do without. This depends 
whether your environment is POSIX / BSD sockets compliant. I have created such 
an environment on an ARM7TDMI and I do manage to get some Linux applications to 
compile (for example an SSL stack). Stuff like file I/O needs to be disabled or 
worked around.

 efficiently -- SPI can give you high speed shift operations,
 and GPIOs can solve the state changes -- but this is is well
 within the capabilities of a 32-bit uC once the other software
 support is resolved.

Getting fast JTAG isn't really an issue. I'm using OpenOCD on a 330MHz MIPS 
platform (together with a fast buffered JTAG interface in an FPGA). It turns 
out 99% of the time is spend putting the JTAG stream together. If I used 
bit-banging it wouldn't have made a difference. I solved this by bypassing the 
OpenOCD JTAG core for most used JTAG operations.

Nico Coesel


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development