Hail the mighty USART! (or who needs the JTAGICE mkII)

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

I just finished debugging the bulk of my code last night using the mighty USART. I was contemplating buying the JTAGICE mkII to aid in debug, but felt the $300 was a bit too much.

So, I figured I would use the USART to dump out all kinds of information while the program was running. It was awesome. I had multiple bugs and in a few hours I had most of them licked. This project involved reading and parsing GPS module sentences and using double variables with lots of trig functions. Obviously, speed is not paramount here for this task.

Sure, the JTAGICE mkII would have been nice with its single stepping and breakpoint ability, but the USART did the trick and saved me lots of $$$.

So, take the pain of getting the USART running reliably (using a nice crystal value like 1.8432 MHz). Then, build up a few serial subroutines and have at it!

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

Quote:
Then, build up a few serial subroutines and have at it!

But only if you happen to have positioned the printf()s at the location where the fault is occuring. Also try debugging fast ISRs with just serial output!

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

Good job, and congratulations.

Now try to improve speed using LUTs for trig functions, and replace double by longints. You wouldn't need JTAG to do it, and it would be more or less 'quick'.

But if possible, try to do it with JTAG, and then compare your effort. I always thought that an ICE would add only relative benefits. Once I tried JTAG, I never could switch back, but that doesn't mean that one can't do what you had done.

And remember, the experience that you had adquired with that program wouldn't hurt you, but teach you.

Congratulations again. Have fun.

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

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

You saved $$$, but if this was done commercially, you likely lost money.

What if the USART is already used? A bigger AVR might not have the features you need.

A JTAGICE needs to be bought only once, but all the hours and associated costs you fiddle with printf's, studying endless logs, time spent waiting for recompilation, reprogramming ICs and the time and energy spent thinking on where to put yet another printf() keep on adding up. Professionally, $300 is an negligible investment that pays itself back in no-time.

You could always consider a Dragon.

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

Clawson, I didn't use printf because of the overhead. I created simpler and faster versions myself. And, of course, the printf affects the speed of execution as well. I took this into account.

Guillem, speed is not a concern for this app. It took about 75ms to do my computation in the simulator. But, it could have taken seconds and I wouldn't care. It only needs to do this calculation very infrequently. If I had the JTAGICE, I would have definitely used it. I'm not saying the USART is better, only cheaper.

jayjay1974, I totally agree that in a commercial environment, the JTAGICE debugger is the way to go. The cost is minor. In fact, we do have one at work, if I ever need to borrow it. I'm using the ATMEGA324P which has 2 USARTs. One for GPS and one for debug. The dragon only supports devices less than 32kbytes, correct? I had to re-compile and re-flash many times to debug this app, which would be un-needed if I had a debugger.

If I every turn pro, I'll buy the debugger. I may still wind up buying one eventually.

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

I was using "printf" figuratively. I mean any generic "write string to UART" routine. The argument stands.

As a Dragon only costs $50 I don't see why anyone wouldn't at least buy one of those if only (initially) because it can do ISP and HVPP (put the JTAG and dW off to one side for a while)

Cliff

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

...oops the stack has been overwritten...why doesn't my printing routine work???

Now, if I could just put a breakpoint somewhere. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Code review, UART output, toggling LEDs, emulators, etc. are all wonderful tools to have in your debugging toolbox. The more you have in there, the better equipped you are to solve a variety of unique problems.

I waited to purchase my JTAGICE MKII until Arrow had a deal going for ~$150. If I somehow roast my JTAGICE, I'll pay the $300 for a replacement without hesitation.

The JTAGICE has saved well over it's cost in my time.

I have too many hobbies.
s-conductor.com

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

js wrote:
...oops the stack has been overwritten...why doesn't my printing routine work???

Now, if I could just put a breakpoint somewhere. :)

Ahhh, but even no output can be just as helpful ;)

While debuggers definitely have value and their place an experienced programmer that has worked without a proper debugger could probably find the bugs in at least 75% of the programs just as fast.

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

mhatter wrote:
Code review, UART output, toggling LEDs, emulators, etc. are all wonderful tools to have in your debugging toolbox. The more you have in there, the better equipped you are to solve a variety of unique problems.

Well said!

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

I use a bit of both... sometime when you see a bit of code is doing something strange, it's simple enough to just chuck a printf statement in before and after.

And for checking the state of something, it's also really nice. just let the thing run and watch hyperterminal tell you what's going on.

but yeah - JTAG is amazing and catches all sorts of things like array overflows into other variables... (not that I do things like that too often... :oops: )

PS, you do not need double precision floats for GPS - I have an app here where I'm using an AVR with an OEM GPS card to make a GPS RTCM base station - and the next revision of this product will use an RTK (cm resolution!) all my maths is in 32 bit unsigned ints.

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

JulianHigginson wrote:

PS, you do not need double precision floats for GPS - I have an app here where I'm using an AVR with an OEM GPS card to make a GPS RTCM base station - and the next revision of this product will use an RTK (cm resolution!) all my maths is in 32 bit unsigned ints.

Do you have fixed-point math routines for all the trig functions? How does it compare to floating-point in terms of speed and code density?

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

debugging is a preference of style, I suppose. Over the years, I've found I can debug most quickly using printf/puts then sit back and T-H-I-N-K. When I try to use breakpoints, my thought process is too disrupted by the mechanics of the use of the tools. So my JTAG is used as a downloader only. Also, most all of my microcomputer code is I/O timing sensitive, so breakpoints are hard to actually do - other than changing the code in the problem area to have a "this should never happen" conditional branch.

But on a big program for a PC class computer, breakpoints in VB or C are what I prefer.

When I was a puppy, computer time was so rare that you had to think (there's that word again) of what you were going to do in your session to test case a, b, c and get results d, e and f as printouts, then go back to your desk and t*k again.

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

stevech wrote:
most all of my microcomputer code is I/O timing sensitive
For I/O time sensitive debugging, such as timing when nested interrupts happen in big-banged serial protocols, I often like to toggle unused I/O pins and watch the sequence with a logic analyzer. For the highly time-sensitive areas, there isn't enough time to output UART characters.
Quote:
When I was a puppy, computer time was so rare that you had to think (there's that word again) of what you were going to do in your session to test case a, b, c and get results d, e and f as printouts, then go back to your desk and t*k again.
Yeah, computer accounting is an anachronism today. I feel a bit fortunate that in my first year of undergraduate study, it was the last year students were required to submit batch jobs via punched cards along with having a limited budget where CPU, memory, and page printed were all debited from your account. Certainly encourage taking time to think rather than making a quick guess of the issue and then resubmitting and hoping for the best.

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

Je, je. When I was developin my ultrasonic level controller, I had to use both techniques. Since time of flight couldn't be debugged with JTAG, I had to use unused pins (I had many), the 'scope, and an LCD. But the math routines, also a little bit 'time sensitive' (I couldn't take 50 ms to do all of them), were debugged easily with JTAG.

And at the end, when testing in 'real applications', where I don't have a PC, 'scope or JTAG, I finally used an LCD and extra keyboard to tweak parameters.

It was a really good school for me. I learned many debug tricks, and I found that JTAG is a good tool, but no the only one.

After all, even when the program works fine, this application needed data logging to an external PC to check for stability, temperature compensation, directivity fluctuation and other issues. But this was not a problem of firmware, but of application itself, that makes me choose certain math algorithms in front of others.

So, the lesson is that a big amount of debug tools help a lot to any programmer. Specially to the bad ones like me ;).

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

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

Agreed, a big bag of debug tricks is what you need :) I think debugging is a bit of an art too.

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

I have enough experience so that solving that same problem all over again yields fairly few bugs. My debugging effort is usually experimenting with some chip or device whose interface or characteristics are unclear from the vendor's literature.

One of my many pet peeves is schools that encourage students to jump into coding skipping requirements analysis and overall design. Then secondary schools teach bad habits like unstructured BASIC and hacking on the keyboard until by accident case A works. And then it's done. (Case B? oh, is there a Case B?). And can someone else later understand this design? Not.

I'm too preachy.

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

The JTAG has more uses than just debugging your software. I use AVRs with FPGAs. Generally connected up to the external memory bus on a M128 or M256x. The JTAG really comes in handy for verifying that the hardware in the FPGA is really doing what I want. I could not live without a JTAG (especially after a couple of months ago when my MKII died...I tried to get by without...but ended up getting another one).

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers