UART asynchronous communication 115200 spacing 121us between bytes 8N1

[PCB.Wiz]

You need to study loop unroll some more.
The HC05 xtal does not matter, as there in a subsequent PLL, it is the peripheral MHz that matters.

[eneuro]

The HC05 xtal does not matter, as there in a subsequent PLL, it is the peripheral MHz that matters.

The peripheral MHz depends probably on stability of system clock and when it is based on external quartz connected to MPU by xtal pins it helps a lot.
I do not need to study any loop unroling - I've wrote a few lines of inline C AVR assembler code and it works.
It was written in a way that now it is easy by adding additional 125ns delays on 8MHz MPU with external quartz crystal clock to output UART frame byte as close as possible to choosen
baud rate and limit is one clock instruction execution time.



Anyway, it works and running this AVR MPU at 16MHz quartz @ 5Vcc instead of 8MHz@3.3Vcc will allow to be closer to given baud rate frequency. 

[eneuro]

Code: [Select]

(  1.0/(1.0/1000000 +1.0/12000000) -921600 )/921600 = 0.0016025641 ~1.6% @ ~923077 software AVR MPU UART baud rate 
/quote]
Are you sure your math is correct?

It doesn't make sense to solve this for 120MHz since I'm interested in 8Mhz@3.3Vcc and 16MHz@5Vcc AVR Attiny85,
anyway I forgot to adjust execution time delay of 8 system clock needed on 8MHz AVR in my developed inline C assembler code to toggle UART TX frame byte output bits based on given byte - it takes exactly 1us on 8MHz MPU, so yes on faster MPU we'll need more delay time to get as close as possible to baud rate 921600  since on 16Mhz AVR MPU we have 2Mb UART frames etc.:

Code: [Select]

8 clocks ->  1.0/1000000 s = 1us @ 8Mhz system clock
8 clocks ->  1.0/2000000 s = 0.5us @ 16Mhz system clock

So, for example on 16MHz AVR Attiny85 with external quartz I have F_CPU 16000000 this part of UART TX frame byte output code will be 2x times faster, so we need more delay and yes we can get closer to given  921600  baud rate ~2% frequency error and we need additional 9 clock delay 

Code: [Select]

t: 1.0/16000000;
1.0/(8*t+x*t)=921600  -> x=9.361   ~9

9*t= 562.5ns

1.0/(8*t+x*t)= 941176
(941176-921600)/921600= 0.0208 ~ 2%


[tridac]

Division ratios in baud generators often give slight error, which can be significant at high rates. One way around that, used in the past, is to vary the division ratio of the baud rate generator. Assuming a baud rate of x and available division ratios of x-1, x+1, then use the upper and lower values alternately, or in a count loop, to get a fractional division ratio. Using an interrupt driven timer as generator, it's easy to do that on alternative timer reload interrupts. Can get very high accuracy. Slight jitter on the baud rate, but the uart won't care about that...