AVR Freaks

The table that clawson provided is for device with a hardware UART.  The ATtiny48 does not have a UART.  That info is not relevant.

Incorrect.  It is equally relevant.  Indeed, it is conservative.  The RX half of software UART implemented by TinyBoot takes only a single sample of each bit, rather than the three samples taken by the hardware UART, so no majority vote takes place.  Furthermore, the timing loops used to detect and generate the bit times are not especially accurate.

But that's not your problem.

The problem is that TSB's auto-baud calculation code has a minimum baud rate it can reliably detect, depending on the CPU clock speed.

For 1 MHz it is about 52 baud, so you might wonder why 300 baud won't work for you.

Note, however, that the minimum baud rate for 8 MHz is about 415 baud.

So the question I have for you is 'How do you know your AVR is running at 1 MHz?'

The exact error in rate in the table provided is specific to a hardware UART implementation.

Still incorrect.  It is the error rate of >>any<< UART implementation which employs majority vote sampling of the centre three samples from a sixteen (or eight for the double-speed table) sample bit.  There is absolutely no correlation to a specific implementation, whether in hardware or in software.  A software UART can employ the same majority vote method, and indeed such software can be found.  And as mentioned, for a single-sample UART (hardware or software), the errors are actually >>worse<<.  For a software UART they are often worse still due to sample jitter.

The general concept may be relevant but it doesn't in any way explain the issue I am seeing.

Where did I hear that before?  Oh yeah:

But that's not your problem.

Not sure why you are discussion a minimum baud rate.  I am asking about a maximum for the 1 wire mode.  

If look at how the TSB autobaud, you'll see it uses a 16-bit counter to accumulate 17 low bit times from the '@@@' autobaud characters.  Each tick of the counter is 5 cpu cycles.  If you do the arithmetic for a 16-bit counter, it overflows for '@@@' at speeds lower than 52 baud for 1 MHz, and at speeds lower than 415 baud at 8 MHz.

300bps does work fine for me in 1 wire or 2 wire mode.  I can't go higher than that in 1 wire mode though.

That's the part I missed.  I misunderstood that 300 baud wasn't working at all.  Re-reading the OP I see that overflow in the autobaud counter doesn't apply.

Sorry for all the fuss here.

No fuss.  Everyone likes a mystery.  Unless it's their own ;-)

I may hook up my Saleae serial protocol analyzer at some point and see if it sheds some light on this.

But:

Signals all look very clean.  I see no indication that the levels are an issue.

???

Probably something in the Tx/Rx direction change...

TSB does nothing special for this.  It uses exactly the same code for both, nothing is conditionally compiled.  The only difference is what happens when you define TXDDR/TXPORT/TXBIT to be the same as RXDDR/RXPORT/RXBIT:

WaitRX:
        sbi TXDDR, TXBIT                ; if RX=TX (One-Wire), port is
        cbi RXDDR, RXBIT                ; driven open collector style,
        sbi RXPORT, RXBIT               ; else RX is input with pullup
        sbi TXPORT, TXBIT               ; and TX preset logical High

Trx1:
        sbi TXDDR, TXBIT                ; if RX=TX (One-Wire), result is
        cbi RXDDR, RXBIT                ; pullup to Vcc for "1" (high-Z)
        sbi TXPORT, TXBIT               ; else portbit actively driven
        rjmp Waitbitcell
Trx0:
        sbi TXDDR, TXBIT                ; set TX driver for output
        cbi TXPORT, TXBIT               ; set portbit to active "0"
;       rjmp Waitbitcell                ; continue with Waitbitcell

WaitRX:
        sbi TXDDR, TXBIT                ; if RX=TX (One-Wire), port is
        cbi RXDDR, RXBIT                ; driven open collector style,
        sbi RXPORT, RXBIT               ; else RX is input with pullup
        sbi TXPORT, TXBIT               ; and TX preset logical High

Cycle counts will be the same, and all bit times are handled in the same way.  The only deviation from a fully open-collector bus is that when a '1' TX follows a '1' TX, the line is driven high for 2 cycles before it is released to the pull-up (external, then internal too), but that should have no effect since the other end will be configured for open-collector RX while TSB is transmitting.

What does your CI-V circuit on the other end look like?

Wow, OK...  I guess it is possible I forgot how UARTs work after doing microprocessor development with UARTs of all kinds hardware and software since 1982, but I doubt it.

Wow.  I guess it's possible I'll spend more of my time trying to help you, but I doubt it.  Guess you got it covered.  Good luck with your project.