In article <haCdnUkqm_NwRBXQnZ2dnUVZ5h6dnZ2d@giganews.com>, 
SkiBoyBob@excite.com says...
> 
> Bob wrote:
> > 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
> 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.

http://www.mouser.com/ProductDetail/FTDI/TTL-232R-5V/?
qs=sGAEpiMZZMtf8aSAtgR7DpPMdam%2fwe00

http://www.mouser.com/ProductDetail/FTDI/TTL-232R-3V3/?
qs=sGAEpiMZZMvYU0Oh5y3R5sMdbLgwj41z

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

Bob wrote:
> 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
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

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

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

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.htm

nope 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.

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.

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

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.

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.

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"!  :> )