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. Works well for me.
Cheap debugging tools, software UART
Started by ●March 21, 2011
Reply by ●March 21, 20112011-03-21
"Jim Stewart" <jstewart@jkmicro.com> wrote in message news:im8feb$4rk$1@news.eternal-september.org...> 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. > > Works well for me. >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...
Reply by ●March 21, 20112011-03-21
Hi Jim, On 3/21/2011 2:20 PM, Jim Stewart wrote:> 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. > > Works well for me.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"! :> )
Reply by ●March 21, 20112011-03-21
while(1); wrote:> "Jim Stewart"<jstewart@jkmicro.com> wrote in message news:im8feb$4rk$1@news.eternal-september.org... >> 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. >> >> Works well for me. >> > > 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...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.
Reply by ●March 21, 20112011-03-21
On 3/21/2011 4:20 PM, Jim Stewart wrote:> Watching all this discussion about debugging > with an LED and such, I was wondering if anyone > else writes software UARTS for debug info.I do it all the time. LEDs too.
Reply by ●March 21, 20112011-03-21
On 2011-03-21, Jim Stewart <jstewart@jkmicro.com> wrote:> 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. >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.> 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. >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.> Add another 100-150 instructions and you can have > an nice little library of routines to print > strings, hex and binary. >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
Reply by ●March 21, 20112011-03-21
Jim Stewart wrote:> while(1); wrote: >> "Jim Stewart"<jstewart@jkmicro.com> wrote in message >> news:im8feb$4rk$1@news.eternal-september.org... >>> 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. >>> >>> Works well for me. >>> >> >> 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... > > 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. >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. http://www.aihaaps.ca/palm/pocketDAQ.htm 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.
Reply by ●March 21, 20112011-03-21
mike wrote:> Jim Stewart wrote: >> while(1); wrote: >>> "Jim Stewart"<jstewart@jkmicro.com> wrote in message >>> news:im8feb$4rk$1@news.eternal-september.org... >>>> 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. >>>> >>>> Works well for me. >>>> >>> >>> 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... >> >> 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. >> > 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. > http://www.aihaaps.ca/palm/pocketDAQ.htmnope this version times out. version 1.88 is the free one that's available all over the web.> 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.
Reply by ●March 22, 20112011-03-22
On 21/03/2011 21:20, Jim Stewart wrote:> 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. > > Works well for me. >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
Reply by ●March 22, 20112011-03-22
Jim Stewart wrote:> 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. > > Works well for me. >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
