"This might suit your personal style well (of course, some of us think
printfs are for wimps, and real debugging is based on scope traces). It
might also suit people doing things like small scale production device
programming."
Do I need to get my digital camera and take a picture of the HP-1630G,
Tek
2445, and HP-4952A sitting here on the floor, rats-nested up to the MSP430
talking to an AVR, with the 3 laptops, cellular and GPS antennas connected?
--John
(OK, so the test equipment is a little antiquated, but a personal budget
forbids a modern digital scope, or even a 2465B. And a 16500 with 80
channels of state and 2 channels of 500Mpb/s sampling doesn't really fit in
my 6x8 office on my boat...)
-----Original Message-----
From: [email protected]
[mailto:[email protected]]on Behalf Of Steve
Underwood
Sent: Friday, October 25, 2002 00:39
To: [email protected]
Subject: Re: [Mspgcc-users] JTAG MSP-FETP430IF status
J.C. Wren wrote:
> Well, that's certainly good news. I've used gdb in the past, and find
> the
>whole gdb process rather a PITA. I do debugging the old fashioned way:
>printf() and wiggling I/O lines. All I need from the JTAG end is erasing,
>programming, and telling it to run. Sounds like that's all there, so I
>shall give that a try.
>
> I should be slightly more specific about IAR. I only use C-Spy. IAR
tools
>are *way* too expensive for small shops, so no matter how good they are,
>they're out on their ear. C-Spy is junk. Trash. Garbage. Crap. Unfit
>for human consumption. It's unreliable, it can't remember defaults, it
>exits on many errors. I'm surprised it remembers what directory you last
>downloaded from. It requires too much mousing around to do anything. Each
>time you download, you have to reselect the programming interface to use.
>What moron thinks you're going to be changing the interface *everytime* you
>download? Sometimes it works for 20 or 30 downloads in a row, other times
>it doesn't work at all 20 or 30 times in a row. "Retry? What's a retry?
>We've never heard of that idea..."
>
> If I released software that bad, not only would I not be surprised that
> no
>one bought it, I'd be surprised if *anyone* bought it. C-Spy is an
>excellent exercise in how to write as poor a user interface as possible,
and
>still actually have it run periodically.
>
> One day I shall be interested in hearing why TI (and Atmel, for that
>matter) think that protecting parts of the JTAG command structure is a
>useful idea. I believe in IP, and I believe there are some things that
>users don't need to know about. But the fact they're willing to share that
>information with some parties and not others is disturbing. It seems to
>indicate a managerial structure that doesn't really understand what a user
>wants, but rather a structure based on unfounded fears. Do they really
>think some is going to clone the core because someone knows how to read a
>register with JTAG? And if they aren't going to tell, the least they could
>do is say why they think they shouldn't.
>
> --John
>
>
One of the nice side effects of using a proxy approach to the JTAG
interface is it totally encapsulates not only the TI's IP, but all the
messy device specific details of handling the MSP430 (or any other
processor). You have a fairly straightforward, fairly device
independant, fairly well standardised, TCP interface to the debug
environment. If you don't like gdb, it wouldn't be a major activity to
write a program that connects to msp430-rproxy, and just says "erase
that chip", "stuff this code into it", and so on. This might suit your
personal style well (of course, some of us think printfs are for wimps,
and real debugging is based on scope traces). It might also suit people
doing things like small scale production device programming.
Regards,
Steve
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
