Does The Atmel JTAGic-MK2 Always Slow Things Down So Much???

Go To Last Post
33 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been using my new ATJTAGice-MK2, trying to look at the outputs of a hand operated quadrature encoder. I find that when I'm in debug with the JTAGice-MK2 in AVRStudio, things go really slow.

When I rotate the encoder, it's about a full second before the accumulator LEDs update on the STK600. When I take the JTAGice-MK2 off line, rotating the encoder results in instantaneous updates of the accumulator LEDs on the STK600.

Is it that I do not have the JTAGice-MK2 set up properly, or is this just the way it is with the JTAGice-MK2?

If this is the way it is with the JTAGice-MK2, I'm thinking that a logic analyzer might be more useful to me.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using a good quality (about $35.00) Grayhill optical encoder. Once testing is complete, I'll be using a more expensive (about $60.00) Grayhill optical encoder. This will be mounted to a Pittman brushed DC servo motor and refinement of the closed loop servo controller will begin.

I had to stop development on that project because the poorly written encoder code was causing PID instability problems at direction changes.

This code seems to be very stable.

When I finally get the closed loop aspects working properly, I'll be adding glitch detection like that used in the Aglent (they've been recently renamed to something else) HCTL20xx series encoder translators.

In addition, I'll be moving away from polling the A & B encoder channels, and using the Pin-Change interrupts.

Note that there are no software delays in this code. With a glitch detector, software delays won't be needed - but it'll be at the expense of additional hardware.

I could understand the JTAGice-MK2 interfering with any software delays, but there aren't ant. So I don't understand why the execution of this code would slow down to the extent that it does.

The code follows...

//ICC-AVR application builder : 10/5/2008 2:19:34 PM
// Target : Mega644
// Crystal: 14.7456Mhz

/*
CHANNEL_A 2 // Encoder 'A' channel input 
CHANNEL_B 3 // Encoder 'B' channel input 
      _____       _____       _____
 A __|     |_____|     |_____|     |__
         _____       _____       _____    
 B _____|     |_____|     |_____|   	 
      
         >----- Forward ----->
         <----- Reverse -----<
			
ENCODER_STATE[] = {0x04, 0x0C, 0x08, 0x00}			
 
        |  Last   || Current ||  Next   |
        |  State  ||  State  ||  State  |
        +---------++---------++---------+ 
        |   B:A   <-   B:A   ->   B:A   |
        +---------++---------++---------+
        |   1:0   <-    0:0  ->   0:1   |
        +---------++---------++---------+ 
        |   0:0   <-    0:1  ->   1:1   |
        +---------++---------++---------+
        |   0:1   <-    1:1  ->   1:0   |
        +---------++---------++---------+ 
        |   1:1   <-    1:0  ->   0:0   |
        +---------++---------++---------+
*/

#include 
//#include "macros.h"

const unsigned char ENCODER_STATE[] = {0x04, 0x0C, 0x08, 0x00}; 

#define ENCODER PIND
#define CHANNEL_A 2 // Encoder 'A' channel input 
#define CHANNEL_B 3 // Encoder 'B' channel input 
#define CHANNEL_MASK ((1<<CHANNEL_A) | (1<<CHANNEL_B))
#define DIR_LED 7   // Encoder direction bit 

void GetEncoderStatus (void);
void Init_Devices(void);
void Port_Init(void);

char EncoderCount = 0;
unsigned char EncoderLast = 0x00;
unsigned char EncoderCurrent = 0; 
unsigned char EncoderIndex = 0x00;
unsigned char EncoderStatus;

void main(void) {
	 Init_Devices(); 

	 EncoderCurrent = ENCODER & CHANNEL_MASK;
	 EncoderIndex = (EncoderCurrent>>2);
	 EncoderLast = EncoderCurrent;	

	 do { // Assuming the encoder is connected to PORTD 
		GetEncoderStatus();
		
		if (EncoderStatus & (1<<DIR_LED)) PORTB |= (1<<DIR_LED);
		else PORTB &= ~(1<<DIR_LED);
	 } while(1); 
} 

void GetEncoderStatus (void) {
	 EncoderLast = EncoderCurrent;	
	 EncoderCurrent = ENCODER & CHANNEL_MASK;

	 if (EncoderCurrent != EncoderLast) {
		if ((EncoderCurrent & CHANNEL_MASK) != ENCODER_STATE[EncoderIndex]) {
		   // Going in reverse direction
		   EncoderIndex = --EncoderIndex & 0x03;
		   --EncoderCount;
		   EncoderStatus |= (1<<DIR_LED);
		} 
		else {
			 // Going in forward direction
			 EncoderIndex = ++EncoderIndex & 0x03;
			 ++EncoderCount;
			 EncoderStatus &= ~(1<<DIR_LED);
		}
		PORTB = EncoderCount; // This instruction will be removed, once testing is complete
	 }
}

void Port_Init(void) {
	 PORTA = 0x00;
	 DDRA  = 0x00;
	 PORTB = 0xFF;
	 DDRB  = 0xFF;
	 PORTC = 0x00; 
	 DDRC  = 0x00;
	 DDRD  = 0x00;
	 PORTD = CHANNEL_MASK; // Turn on internal pullup resistors	 
}

//call this routine to initialize all peripherals
void Init_Devices(void) {
	 //stop errant interrupts until set up
//	 CLI(); //disable all interrupts
	 Port_Init();

//	 MCUCR = 0x00;
//	 GICR  = 0x00;
//	 TIMSK = 0x00; //timer interrupt sources
//	 SEI(); //re-enable interrupts
	 //all peripherals are now initialized
}

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Carl,

This looks a little fishy:

void GetEncoderStatus (void) {
    EncoderLast = EncoderCurrent;   
    EncoderCurrent = ENCODER & CHANNEL_MASK;

    if (EncoderCurrent != EncoderLast) { 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
Hi Carl,

This looks a little fishy:

void GetEncoderStatus (void) {
    EncoderLast = EncoderCurrent;   
    EncoderCurrent = ENCODER & CHANNEL_MASK;

    if (EncoderCurrent != EncoderLast) { 


Hi Mike,

Well, it makes perfect sense to me. And, it isn't the reason for the extremely slow operation with AVRStudio in JTAGice debug mode. That is the problem that I need an answer to.

If JTAGice slows the operation down to the snail's pace that I'm experiencing with real-time debugging, then JTAGice is not very useful to me - as it applies to run-time debugging. Sure, I can single-step (and that might be useful to me), but not while manually rotating an encoder in real-time. What would that accomplish?

Do you care to elaborate on your reasoning on the "Fishy " comment?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Do you care to elaborate on your reasoning on the "Fishy " comment?

It just seemed that since EncoderLast was being overwritten first thing just didn't seem right. Of course I'm down with a bad case of the flu right now so everything looks a little off :(

I was under the impression that the JTAGII could run at full speed. Maybe try deleting all break points to make sure there isn't something slowing things down?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
Quote:
Do you care to elaborate on your reasoning on the "Fishy " comment?

It just seemed that since EncoderLast was being overwritten first thing just didn't seem right. Of course I'm down with a bad case of the flu right now so everything looks a little off :(

I was under the impression that the JTAGII could run at full speed. Maybe try deleting all break points to make sure there isn't something slowing things down?

Note that:

#define ENCODER PIND
#define CHANNEL_A 2 // Encoder 'A' channel input 
#define CHANNEL_B 3 // Encoder 'B' channel input 
#define CHANNEL_MASK ((1<<CHANNEL_A) | (1<<CHANNEL_B))

And:

unsigned char EncoderLast = 0x00;
unsigned char EncoderCurrent = 0;

are global, and unchanged anywhere else within the program.

So:

	 EncoderLast = EncoderCurrent;	
	 EncoderCurrent = ENCODER & CHANNEL_MASK;

Will work just fine.

Well, I don't have any break-points set. I was just trying to run the program and watch PORTD for encoder inputs, and then see if that data was qualified to cause direction change.

Other then the program running, the observation was pretty static, once the encoder was incremented or decremented by +/- one encoder shaft detent.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Mon. Oct 6, 2008 - 04:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with CirMicro, I haven't seen the JTAGICE MkII affect the speed of operation. I see a breakpoint where I need to inspect the state and the application runs at full-speed until the breakpoint is reached.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kmr wrote:
I agree with CirMicro, I haven't seen the JTAGICE MkII affect the speed of operation. I see a breakpoint where I need to inspect the state and the application runs at full-speed until the breakpoint is reached.

I am using the generic setup for JTAG. I don't even see any setting options to change JTAG. I'm also using the most current version of AVRStudio, which also upgraded the JTAGice-MK2 firmware when I first connected it to the computer USB port. Of course, I was asked if that's what I wanted, and I said yes.

I have the ImageCraft ICCAVR plug-in installed. Then all I'm doing is loading the program via a *.cof file generated by the ImageCraft C compiler.

Once the controller is programmed with the freshly compiled code, I close the programming pop-up, and enter debug mode in AVRStudio. Then I hit run.

Now when I rotate the encoder, it's about a full second before I see any update, both in AVRStudio, as well as on the actual hardware.

But if I exit debug mode, when I rotate the encoder, the hardware updates instantaneously. And of course, I can no longer see any changes within AVRStudio, as I've left debug mode.

And all during this time, I have no break-points active. In fact, I haven't yet used any break-points in AVRStudio - ever.

Any clues, Kevin?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe a better approach would be to modify your code to save the information you want to a separate area in RAM and then use the JTAG to read that once in a while, instead of reading the port. Just a suggestion - I don't even have a debugger. :P

If you think education is expensive, try ignorance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

emuler wrote:
Maybe a better approach would be to modify your code to save the information you want to a separate area in RAM and then use the JTAG to read that once in a while, instead of reading the port. Just a suggestion - I don't even have a debugger. :P

Thanks, emuler.

I'll give that a try in the morning, as I'll off work tomorrow. I'm working 4 ten hour days a week, and tomorrow is my scheduled day off.

Thanks for the suggestion...

The problem that I'm trying to track down is that, the direction flag hasn't been reliable in other renditions of this code. I was hoping to prove that I have the problem solved, before I incorporated this new code into the PID based servo control software.

But it seems that I am at a loss (temporarily, anyway) to finding that proof.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Once the controller is programmed with the freshly compiled code, I close the programming pop-up, and enter debug mode in AVRStudio. Then I hit run.

Are you selecting run or autostep? As far as I know when you select run nothing will update until you hit a breakpoint or pause it. Autostep will update things while running but it will be very slow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From my experience with JTAG (both models) with ICC and AVRStudio (older versions, BTW), IAR (that includes its own debugging facilities) and WinAVR+AVRStudio, is that when you hit Run, the program works in realtime until you stop it or it reaches a breakpoint.

But there are another issue: the pins used for JTAG should be used only for JTAG when debugging, and JTAG should be enabled in all conditions (there are two fuses and some bits in certain registers, depending on your AVR model).

Ah, and AFAIK, you don't need to manually reload the program to the Flash memory, since the debugger will do it by itself (unless you had deactivated the option, though) when starting the debug session.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, and I almost forget: when you have a large amount of data to be watched, it need more time to read back the data and display it. So I usually limit the amount of data to be watched to the minimum.

Hope this helps.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
Quote:

Once the controller is programmed with the freshly compiled code, I close the programming pop-up, and enter debug mode in AVRStudio. Then I hit run.

Are you selecting run or autostep? As far as I know when you select run nothing will update until you hit a breakpoint or pause it. Autostep will update things while running but it will be very slow.

Right, as far as my experience goes with the JTAGICEmkII, the watch window is only updated when the debugger halts, being, as a result from a breakpoint, or when manually halting the debug session.

How are you checking the input Carl, do you use autostep as mentioned, or do you use a data break point with auto resume? (although you’re saying that you’re not using any break points at this moment)

I’m also using a Grayhill encoder, but a manual one, this is the code that I use to scan for user input (only the encoder part)

	// get encoder pin state
	enc_a_now = (ENC_PIN & (1<<ENC_PIN_A))>>ENC_PIN_A;
	enc_b_now = (ENC_PIN & (1<<ENC_PIN_B))>>ENC_PIN_B;
	
	// 	encoder type 62P22-H6 or L6
	//	encoder pin output table
	//  --------------------------------
	// | turn	 |	right	|	left	|
	// | pin	 |	A	B	|	A	B	|
	//  --------------------------------
	// | state 1 |	0	0	|	0	0	|
	// | state 2 |	1	0	|	0	1	|
	// | state 3 |	1	1	|	1	1	|
	// | state 4 |	0	1	|	1	0	|
	// | state 1 |	0	0	|	0	0	|
	//	--------------------------------
	// decode rotation direction

	// check for pin change
	if((enc_a_prev != enc_a_now) | (enc_b_prev != enc_b_now)){ 			
		// XOR previous state from pin A with pin B, when turning to the right, 
		// previous state of pin A will always be equal to pin B
		// if not, the direction is to the left.
		// Depending on the 'selector_dir' state, the returned direction
		// is inverted or not.											
		if (selector_dir^(enc_a_prev^enc_b_now)) key_now |= ENC_UP;
		else key_now |= ENC_DOWN;
		enc_a_prev = enc_a_now; 										
		enc_b_prev = enc_b_now; 
	}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I just got up. I'll get a cup of coffee, and do some more experiments, hoping to answer your questions (and mine) that have come up overnight.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done some more checking, and it seems that I have a bit to learn about using JTAG and debug in AVRStudio.

Evidently, I was using the single-step mode.

I used the run button, and the PORTB outputs driving the LEDs update immediately, but nothing within AVRStudio. When I run the debugger in single-step mode, I get updates in AVRStudio, and those updates in AVRStudio happen pretty quick, but the updating of PORDB takes at least a second.

I guess it just goes to show, a good night sleep has a tendency to remove the fog of the day.

I'll work with the break-points a bit more and see if my feeble mind can make more sense of it.

While JTAG might be great for debugging near static code, I can see that to really prove that my encoder code is working as desired, I'll still need to revert back to the hardware prototype, my scope, and real-time testing.

As you should all be aware (as I stated it so many times in the past) I usually use hardware methods (LCD, I/O, scope, etc...) to debug my projects. JTAG and debugging in AVRStudio is a new twist to my debugging techniques and it'll take some time getting use to.

Maybe a combination of JTAG, my 8-channel BitScope logic analyzer, my TDS2012 Oscilloscope, as well as my other usual debugging techniques will work together to provide more powerful debugging facilities. We'll see how all that works out.

Then too, maybe I'm just expecting too much from the JTAGice-MK2.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Although a JTAGICE is a really good tool, for certain applications is not the best or is not suitable at all.

When I was developing my Ultrasonic Level Controller, I used it only for certain parts of the program, but for the real time distance measurement, I used the 'scope. Altough the JTAG allowed to debug the ISR's I had for the ICP and ADC during this time, using breakpoints.

It's a totally different way to debug programs, and it needs certain knowledge and practice to use all its potential, but is only a complement to the 'scope and logic analyzer.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like I said above, the scoot and snoop approach should serve you better. That allows your data acquisition program to run in real time, but gives you the information you need.

Say you want to know what the AVR is reading from the encoder. Add lines in your code to save pertinent port data to the RAM (even to the extent of the RAM available (deep memory)). This should not affect the speed of your program significantly (3 clock cycles to save a byte to RAM), so it will be running at full speed.

When you feel you've run long enough (sufficient data in RAM) go into debug mode and examine the data you have in RAM.

If you think education is expensive, try ignorance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcarl wrote:
Maybe a combination of JTAG, my 8-channel BitScope logic analyzer, my TDS2012 Oscilloscope, as well as my other usual debugging techniques will work together to provide more powerful debugging facilities.
I think that you'll find the combination powerful. JTAG debugging, in terms of effort, is fairly free. Wherever possible, I program my projects with debugWIRE or JTAG. So, I'm also hooked up with the JTAGICE MkII during development/testing. Most of the time I use the debugger just as a programmer. But, if I ever need to use the debugger, it's all hooked up and ready to assist me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
a new twist to my debugging techniques and it'll take some time getting use to.
You mean you NEVER used a monitor program with the HC11 like BUFFALO, Pbug or Jbug? Not much difference in operation with an ICE (of any brand).

Pretty much any controller I have worked with (von newman) has a monitor program written for it where you can do pretty much all you can do with a JTAG ice. Unfortunately with a Harvard chip you can't run code from ram otherwise you would not really need a JTAG ice, the monitor would be sufficient but for the most complex jobs.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Mon. Oct 6, 2008 - 09:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Carl, I suggest you take a look at the latest AVRTV episode on JTAG debugging. It will show you a few good debugging methods.

Usually, you'd want to run the code at full speed, and only examine sections periodically or in reponse to a changing condition. You can set a breakpoint in your code at one main location, and configure the debugger to continue when the breakpoint fires. That means that for the most part the application runs at full speed, with only a slight delay when the JTAG reaches the break point, halts the program, updates the window and then continues.

I use my JTAG heavily to determine if certain sections of code are being executed as they should (occasionally single-stepping through routines) as well as to check registers to test if any error bits have been set.

Once used properly you'll never want to do without it, but it's mostly a part of a full debugging setup, and not a complete debugging setup by itself.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Dean!

I'll check into the AVTTV episode.

I finally got through some of my ignorance about JTAG today. I'll just keep working at it until I get it - like everything else.

Again, thanks!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

..AND I just realised you are making life hard on yourself by NOT using the Studio plugin from Imagecraft (down the bottom of the D/L page). Install that and you can do it all from within Studio like asm or winAvr.

Then you can switch easily from ICC to winAvr by getting to know winAvr's quirkness.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
..AND I just realised you are making life hard on yourself by NOT using the Studio plugin from Imagecraft (down the bottom of the D/L page). Install that and you can do it all from within Studio like asm or winAvr.

Then you can switch easily from ICC to winAvr by getting to know winAvr's quirkness.

JS, you need to go back and re-read the first page of posts. I clearly stated that I'm using the ImageCraft ICCAVR plug-in.

And I've done some editing of the source code, as well in AVRStudio. I'd rather use the ICCAVR editor, as it is a full screen. Using AVRStudio for even viewing source code is kind of like attempting to look at the Queen Mary through a keyhole, while standing ten feet away.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I clearly stated that I'm using the ImageCraft ICCAVR plug-in.
I see that now :oops: (7th post down) I just wasn't sure why you don't do just a "Build and Run" and the code, if compiled correclty, will be automatically downloaded into your chip without having to even knowing what format it needs to be in. It just happens.

You can close all other windows if you want and just have the editor window but I don't have any problems as all my debuging windows are down the bottom so they take about 10-20% of the bottom part of the screen. A well known project example... :)

You can see all the other windows tabbed at the bottom.

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, JS!

I'll look into the build & run.

As I've only really used AVRStudio for programming environment (and one failed attempt at simulating a FAST PWM program) I don't really know the ins & outs of AVRStudio as a debugger.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, John -- that's what I do as well with AVR Studio -- build and run. IAR's debugger has a similar option.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
IAR's debugger has a similar option.
...they must have copied Studio interface... :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unluckily, IAR debugging windows are not a good copy of 'Studio's ones. For peripheral setup and registers settings, I still prefer AVRStudio. While I used IAR for complex parts of a program, like startup, or to have traces of what happened.

Different point of views for everything, huh?

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Carl, happy with the JTAGICE, and does your code work now?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

fleemy wrote:
Hi Carl, happy with the JTAGICE, and does your code work now?

Well, I ran the servo most of the weekend, without issue. But I didn't modify the code. I had made some changes the last time I had it up & running, and those changes seem to have solved the problem. But I did learn a little bit about the JTAGice-MK2. I'll probably use it more as time progresses, and I become better equipped knowledge wise as to its capabilities. But without a doubt, my trusty, tried & true debugging methods will prevail.

My next move with the servo project is to lay out a PCB. But I haven't yet decided on the communications method. I'm leaning toward SPI, but I'm also considering TWI. I've never done anything with TWI, so that might be an interesting approach.

TWI might be the better of the two, as I'll have at least 5 servo controls (X, Y, Z, A & the spindle), not to mention about 20 I/O bits for coolant (flood & mist), home switches (X, Y, Z, A & spindle index), axis limit switches (X+, X-, Y+, Y-, Z+, Z-, A+, A-). So there is a lot of planning yet to do.

Thanks for asking, though.

The fact is, I'm still not sure that I need the JTAGice-MK2 for debugging, though I do have some development boards that seem to exclusively use the JTAG interface for programming - like the EVK1100.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just some thoughts: SPI is much simplier than TWI. And to debug TWI, an 'scope and JTAG will be a really good combination.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

to debug TWI, an 'scope and JTAG will be a really good combination.

If you can afford it (wish I could :( )a Tek MSO (mixed signal oscilloscope) can decode most of the serial communication formats out there. :D

If you think education is expensive, try ignorance.