Cheap debugging tools, software UART

Or, instead of 9600, you can use any other arbitrary speed (say, fastest possible) and one of those cheap USB logic analyzers that have RS-232 decoding so the period with interrupts off will be as short as possible...

In the past, I have implemented a crude stub that would write values to a predictable location (this assumes you have an external bus available) that I could *optionally* hang hardware off of to capture those values. If you arrange for those values to be "ordered" conveniently, you can tell how far your code has progressed just by watching the most recent value.

[of course, with a logic analyzer, this is *too* trivial!]

I've also worked in systems where an *input* was periodically polled (yet another "task" -- of whatever priority seems appropriate!) that could "commands" to the run-time debugger. In one such case, we had a little box with a keypad and 6 digit LCD display with which we could monitor (and modify) memory locations on-the-fly.

While this sounds to be of dubious use, you can actually do a lot with it if your code plans on it's potential presence! E.g., if a task sets a flag and blocks waiting for a particular event, you could *watch* that "flag location" (i.e., tell the debugger to display its value each time the debugger task gets a timeslice). When *you* recognize the "set" value, you can then key in the keystrokes that will ultimately tell the debugger to "set" the event (in the appropriate memory location).

It's crude but amazingly effective! And, since it can be left in the production system, all you need to do is carry this little "control panel" with you and you can debug a running system by simply hanging it on the bus.

(of course, this is infinitely better than my first product debugged via "scope loops"! :> )

possible) and

with

You certainly could. I've stuck to 9600 because it seems to be a good compromise between speed, simplicity and timing loop accuracy. Anything faster and the timing can get tricky.

All I'm trying to do is send some simple status messages from time to time.

I do it all the time. LEDs too.

Yes, but as part of a more general AVR UART library I wrote in which tty 0 is the hardware UART and tty 1 is a software Tx only UART.

I use a spare clock so the timing loop on the software UART is hardware driven. I also implement a buffer so that output can be queued for both UARTs and program execution can continue while the data is been output.

It's a big deal for me unfortunately, hence the hardware timing. For example, one pair of AVRs I'm working on implement a over-the-air comms protocol so I can only tolerate a small amount of extra jitter when outputting debug messages and I certainly cannot stall for dozens of bit lengths within a software timing loop.

Likewise here. My API is the same for both the software and hardware UARTs as you specify the tty number required when performing I/O.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

If you've got the i/o lines, a series of leds to indicate the status, stack depth, whatever interests you is pretty easy.

I've used morse code for status.

Serial IR works well. A led and resistor is a lot simpler than adding a hardware rs232 interface. Just point your PDA at it to read status.

This is a newer version. The unlimited trial of the older version does everything I need. Not sure what this one does.

But there are other programs available.

nope this version times out. version 1.88 is the free one that's available all over the web.

I've done this and I've also used an uncommitted SPI block to do the timing and bit shifting for me. You need two writes because of the stop and start bits but that's cheaper than having to time the individual bits.

Andrew

I use a timer channel ISR instead of loop timing and I prefer to use a hardware UART for the debug I/O even if that means I have to use a software UART for "work" I/O. But that's just my implementation; having debug I/O is *required* to prevent forcible hair removal.

Bob

Oh, and the debug port is usually active even in production release. I bring it out to a 4 pin header: Tx, Rx, Vcc, Gnd. The level translators are on a "debug" PCB that is powered by the target. The debug PCBs are so popular (and useful for the test and calibration techs) that I recently had another batch of 20 boards fab-ed.

Bob

Why build custom transceiver boards? These days the following cables make far more sense. Just provide 1x6 headers on your board at TTL levels of async data flow and have it show up at your PC over a USB virtual COMM port into something like TeraTerm.

I've deployed 100s of these cables as test, debug and validation tools and find the cost less than trying to build my own transceiver board.

--

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com