[F0 uSart] Dlaczego wymagany delay po wysłaniu danych i wyłączanie CLK?

Bawię się USART'em na F0 przesyłając między dwoma prockami testowy bajt, Wszystko mi działa, ale nie mogę dojść, dlaczego muszę wprowadzać po wysłaniu danych do drugiego procka delaya(?). Bez niego testowe echo nie działa prawidłowo. Obecnie mam przebiegi jak na poniższym zdjęciu (transmisja bardzo wolna póki co):

Gdzie kanał 0 i 2 to crossy TX/RX procków, kanał 1 clock, a kanały 3 i 4 to zapalenie diodki kontrolnie.
Czy flaga od pustego bufora nadawczego nie pojawia się nieco wcześniej zanim ostatnie bity z bajtu zostaną 'wypchnięte' ?
Drugiej rzeczy jakiej nie rozumiem, to dlaczego układ, który odbiera dane musi mieć wyłączony bit od nadawania zegara na pinie z peryferium USART_CLK? Stąd moje dwie funkcje 'init_to_transmit/receive' w której w(y)łączam clocka, ponieważ włączone CLK po obu stronach nie działa. Przeczy to idei szybszej transmisji wykorzystując zegar i omijając bity startu/stopu/parity itd. Docelowo chcę to zrobić na różnicówce gdzie będzie jeden master oraz kilka slave. Chcę też wykorzystać adresowanie, które jest w tym peryferium wpisując do tych rejestrów ich 'unique id' lecz to trochę później.
Program:

Prosiłbym o wskazówki, nie gotowe rozwiązanie, więcej się nauczę, tylko już mi się pomysły skończyły.

Zobaczmy co piszą o bicie TXE:
"Bit 7 TXE: Transmit data register empty
This bit is set by hardware when the content of the USARTx_TDR register has been
transferred into the shift register. It is cleared by a write to the USARTx_TDR register.
An interrupt is generated if the TXEIE bit =1 in the USARTx_CR1 register.
0: data is not transferred to the shift register
1: data is transferred to the shift register)
Note: This bit is used during single buffer transmission."
Użycie tego bitu w tym kontekście:

to tak jakbyś zakładał, że skoro masz w ręku potwierdzenie nadania, to znaczy, że paczka jest już u klienta. I Ty właśnie w tym momencie zgłaszasz reklamację w firmie kurierskiej, że po otrzymaniu potwierdzenia nadania musisz jeszcze czekać dzień albo dwa zanim klient rzeczywiście dostanie paczkę.

Wytłumaczenie powyżej - szczególnie przykład z potwierdzeniem nadania (; - bardzo dobre. Dodam wiec jedynie tyle, że bit o który Ci chodzi to TC, a nie TXE.

Jeden bit, a tyle radości z działania
Czytając RM o tym bicie (TC) nie chciałem co wysłanie bajtu generować przerwania, ale przecież nie muszę Dla potomnych podmiana sprawdzenia flagi z TXE w pętli od wysyłania danych na TC (Transmission Complete) rozwiązała problem wstawiania delaya.

Jednak wciąż mam problem z linią CLK. Wciąż muszę po wysłaniu wyłączyć CLK jeśli mam czekać na dane a na czas wysłania go włączyć.
Tak wygląda transmisja bez wyłączania CLK


A tak wygląda jak go wyłączam, a nie chcę tego robić bo to strata czasu, i pewnie tak być nie powinno

No ale czy masz pewność, że tak właśnie nie powinno być? Bit można wyłączyć w przerwaniu od TC (albo po tym jak bit TC się ustawi), natomiast włączyć zegar trzeba przed rozpoczęciem wysyłania.

Istnieje pewna szansa, że po prostu "tak ma być"... W moim rozumieniu USART działa jak SPI, a w SPI jest tylko jeden master i tylko on może wysyłać zegar. Datasheet zdaje się to potwierdzać: "This means that it is not possible to receive synchronous data without transmitting data." No i właśnie tak powinna wyglądać u Ciebie komunikacja - jak chcesz cos odebrać od drugiego urządzenia, to "wysyłasz" mu zero, aby pojawił się zegar, a tamto urządzenie wtedy odpowiada.

Z początku wydawało mi się trochę nadmiarowe patrząc po cyklach CPU wskakując w przerwanie co przesłany bajt, dlatego wolałem sprawdzać czy już się wysłało w pętli. Absolutnie masz rację, że w tym czasie blokuje program, piszemy na przerwaniach itd. jednak w tym wypadku podczas odsyłania nic innego procek nie będzie robił - chcę to jak najszybciej odesłać do 'mastera'.

Gdzieś wyczytałem już, że USART to taki SPI właśnie tak jak piszesz, jednak myślałem, że po prostu coś źle robię. Jeśli "tak ma być" z CLK to tak zostawie.

Owiec_ napisał:

Z początku wydawało mi się trochę nadmiarowe patrząc po cyklach CPU wskakując w przerwanie co przesłany bajt, dlatego wolałem sprawdzać czy już się wysłało w pętli

Jeśli będziesz wysyłał dane odpowiednio szybko, to przerwanie od TC będzie tylko jedno - na samym końcu. Jeśli użyjesz DMA, to właśnie tak będzie, jeśli nie, to tak czy iak co bajt będziesz musiał mieć przerwanie (od TXE).

Niemniej jednak nie przejmowałbym się tym aż tak bardzo. Z Twoich zrzutów wynika, że używasz zawrotnej prędkości 9600 bps, więc jedno przerwanie co 1 ms nie jest aż takim dramatem. W końcu w czasie tej 1 ms rdzeń zdąży wykonać dobre kilkadziesiąt tysięcy rozkazów, więc te ~100 na wejście do przerwania, zrobienie w nim czegoś i powrót nie zrobią mu specjalnej różnicy.

Prędkość docelowo będzie znacznie większa (~ 500000 bodów) ale póki co na przewodach wszystko jest i celowo zwolniłem transmisję do tej zawrotnej "dziewięć sześćset".

DMA na pewno ogarnę, ale jeszcze do niego nie dojrzałem.

Owiec_ napisał:

Prędkość docelowo będzie znacznie większa (~ 500000 bodów)

Dla naszej percepcji większa, ale dla mikrokontrolera - wcale nie. Przy podanej przed Ciebie prędkości 500 kbps i z przerwaniem co bajt występowałoby ono co 20 us. Jeśli ustawisz układ na pracę z częstotliwością 48 MHz, to w takim czasie realizuje on ~1000 instrukcji, więc Twoje przerwanie (powiedzmy ~100 cykli) to 10%. Wciąż nie ma dramatu (;