J.C. Wren wrote:
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.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
Regards, Steve
