Lpc2000

James,

> Something occurred to me.. most of the discussion here is for 
> C development, and what I need is C++ capability because I 
> have an endless library of embedded C++ code I'm cutting and 
> pasting together for this project.  I had nightmare problems 
> using C++ with the Aymel AVR JTAG emulator, although a lot of 
> this was some weird decisions Atmel made about support GCC in 
> general.  The C++ code itself worked great, although the 
> emulator was useless and we had to bring up the board with printf's..
> 
> So.. before I get into more trouble..Is anyone using the 
> Nohau or Ashling or Wiggler to debug C++ code?

CrossWorks supports development and debugging of C++ code using a
Wiggler or compatible.  We're developing a USB-based solution for JTAG
on ARM too.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors

I just checked Olimex's website and they have released their LPC2106 
development boards and tools(JTAG).

http://www.olimex.com/dev/index.html

/Robert

Something occurred to me.. most of the discussion here is for C development,
and what I need is C++ capability because I have an endless library of
embedded C++ code I'm cutting and pasting together for this project.  I had
nightmare problems using C++ with the Aymel AVR JTAG emulator, although a
lot of this was some weird decisions Atmel made about support GCC in
general.  The C++ code itself worked great, although the emulator was
useless and we had to bring up the board with printf's..

So.. before I get into more trouble..Is anyone using the Nohau or Ashling or
Wiggler to debug C++ code?

Thanks for any opinions!

> I just checked Olimex's website and they have released their LPC2106 
> development boards and tools(JTAG).
> 
> http://www.olimex.com/dev/index.html

Wow, that's some handy stuff at good prices!  I really like the
lpc2106 on a 40 pin header.  If they had just used *pins* so it
fit in a 40 pin DIP socket.  It sort of reminds me of the custom
COB parts Samsung made for us so we could in circuit test their
ROM only based parts.  I think I may still have one....

Cheers,
David

>Something occurred to me.. most of the discussion here is for C development,
>and what I need is C++ capability because I have an endless library of

#pragma RELIGION PAUSE

I have two unloaded questions:

What exactly is it you need to do in C++?
Are you working on hobby code or commercial code?

#pragma RELIGION RESUME

(I'm actually asking for real reasons, btw. If the answer is that you 
inherited a boatload of C++ code from something else, then I'm curious 
about how you've analyzed the maintenance and testing overhead).

-- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20

> What exactly is it you need to do in C++?
> Are you working on hobby code or commercial code?

I understand that the use of C++ in embedded applications is controversial,
and I respect those who choose not to use it.  In fact, several people on
our staff do not see eye-to-eye with me on this point.  However, I
personally use it almost exclusively.  I probably have 8,000 lines of C++
code in service for the Atmel AVR -- not so-called 'eC++' but true C++ even
with templates and multiple inheritance and virtual functions.  These
features come at a cost, but if you have a complex problem to solve, I have
found that using OOD compiler features brings jobs to conclusion faster that
explicitly coding the equivalent in C.  Not everyone feels this way, but my
team completes projects on time using C++ so I get very little argument
outside of an occasional passing comment.  And yes we have analyzed our code
thoroughly.  The complex structures are more expensive to analyze and test
(and design) than the simple structures, but I don't see C bringing an
advantage over C++ here.. they are both awful.  Ideally, we'd prefer ADA,
and perhaps if we can really transition from AVR to ARM this may become a
possibility.

The one real increase in risk that I have run into with C++ is with
emulators and debugging environments.  Because C++ is not used as often as C
in the embedded arena, the source-level debugging support does not have the
testing history that C has.  I've gotten stuck in this mire and it CAN
severely impact effort and schedule... so this is why I ask for experience
here as well as sending questions directly to the tool vendors.

Thanks.