Watching all this discussion about debugging with an LED and such, I was wondering if anyone else writes software UARTS for debug info.
I've written a 9600 baud tx-only UART for AVR's in 35 assembly instructions. The data out can be inverted so that you can connect the tx I/O pin directly to your terminal without an inverter or driver.
Timing is by software timing loops so interrupts must be off during transmit, but I've not found that to be such a big deal.
Add another 100-150 instructions and you can have an nice little library of routines to print strings, hex and binary.
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"! :> )
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.
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
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.
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.
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.
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.
formatting link
formatting link
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.