A full-duplex software UART for tiny AVRs

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

I've written it for the ATtiny13, ATtiny85, and ATtiny84 series.  Other AVRs with an 8-bit timer/counter having output compare could be supported with minor modifications to the code.

It is truly full-duplex, in that a frame can be transmitted concurrently with a frame being received.  Received bits are typically sampled within 5 cycles of the center of each bit.  With a baud rate of 57.6kbps and F_CPU of 8Mhz, less than 50% of the CPU cycles are used during continuous send and receive.

 

http://nerdralph.blogspot.com/20...

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good work! The question is of course whether you still have to use these old AVRs without Hardware-UART today.
Can you also offer a pure assembler version? A version that can be easily integrated into own assembler projects?

Last Edited: Sun. Jun 21, 2020 - 10:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
Good work! The question is of course whether you still have to use these old AVRs without Hardware-UART today. Can you also offer a pure assembler version? A version that can be easily integrated into own assembler projects?

I'm unlikely to write it in pure asm, partly because I haven't written a good set of asm portability macros.  Something like:

PCMSK |= 1<<WGMRXBIT;

Can compile into a single sbi, in + ori + out, or lds + ori + sts, depending on the address of PCMSK.  There's also a few types of optimizations that gcc can do that are hard or even impossible to do in asm, so I still write a lot in C/C++.

The whole example program when built is around 150 lines of asm, so you could just use objdump or save temps to get asm code for a specific target.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ralphd wrote:
I'm unlikely to write it in pure asm

 

A pity.

 

ralphd wrote:

asm portability macros

a few types of optimizations that gcc can do

 

You could say, trying to keep it portable prevents simple asm code.

 

ralphd wrote:
so you could just use objdump or save temps to get asm code for a specific target

Sure. But often applies here: Before you understand someone else’s code it is faster to write your own angel

OK, but thanks for your work, I guess high level language programmers will be happy wink

Last Edited: Tue. Jun 23, 2020 - 07:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure. But often applies here: Before you understand someone else’s code it is faster to write your own angel

 

ralphd has written the code in relative high level, and I had a quick look at the code and that is not that hard to read (when you have a good idea of what happen).

 

With that in mind you can write your own code.

The main thing is to understand how you set the baud rate, ISR type for RX (and find sample time) and TX, and that you enable ISR from one of the ISR's to avoid that they block each other.

 

 

Add:

And if you use newer tinyAVR's (based on xmega design), the interrupt handling will be different (they have more than 1 level of interrupt).

 

 

 

 

 

Last Edited: Tue. Jun 23, 2020 - 01:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
use newer tinyAVR's (based on xmega design), the interrupt handling will be different (they have more than 1 level of interrupt)

And in most cases there are (enough) hardware-uarts.
And more SRAM buffer size for serial data...

Last Edited: Tue. Jun 23, 2020 - 04:51 PM