@Albert B.:
albertb napisał: Zwróć uwagę, że ja także podaję to jako alternatywę nie krytykując Twojego rozwiązania.
Przepraszam, nie chciałem nikogo urazić czy krytykować. Sam początkowo pomyślałem: przecież to banalnie proste, więc w czym problem. Zacząłem kombinować podobnie jak Ty, ale właśnie napotkałem problemy, o których napisałem powyżej.
albertb napisał: Te 960 taktów nie musi być zmarnowane. Równie dobrze możesz ustawić timer i dalszą transmisję inicjuje jego przerwanie.
No właśnie tak to próbowałem rozwiązać, tylko skoro już uruchomimy ten timer, to co stoi na przeszkodzie odmierzyć dwa czasy Break i Mark After Break (MAB) wykorzystując przerwanie od porównania do zmiany stanu pinu w międzyczasie, a później rozpocząć normalną transmisję UART.
albertb napisał: Trzeciego zarzutu nie rozumiem. On nie ma nic wspólnego z proponowaną metodą
Chodziło mi o to, że oparłeś swoje rozwiązanie o umiejętność wysyłania ramek przez autora wątku. Jednak funkcja wysyłająca dane, z której korzysta, oczekuje na zwolnienie rejestru UDR. Jeśli będzie wysyłał dane w pętli, to procesor będzie cały czas trwania transmisji w stanie oczekiwania. Moim zdaniem lepiej podawać dane w przerwaniu UDRE, a flagi TXC użyć do określenia końca transmisji. Autor wątku pisał o chęci rozbudowy tego programu w przyszłości, więc dobrze byłoby gdyby transmisja nie konsumowała zbyt wiele czasu procesora.
Dar.El napisał: Dla BREAK ustawiasz 125kHz, 9 bitów danych i jeden bit stopu. Wystarczy tylko UART.
Faktycznie to powinno zdać egzamin. Wprawdzie daje to (w przeliczeniu na 250kHz) 20 zer i 2 jedynki (Break powinien chyba mieć min. 22 zera), ale gdyby odpowiednio dobrać częstotliwość transmisji UART'a (trochę mniejszą od 125kHz) to może się udać.
Ja próbowałem rozwiązać to za pomocą timera, ponieważ daje on możliwość dokładnego i łatwego odmierzenia praktycznie dowolnego czasu. Nie wziąłem pod uwagę, że dokładność nie jest tu de facto krytyczna. "Minimum 22 takty" to nie "dokładnie 22 takty" itd. Rozwiązanie Dar.El zapewne zda egzamin i pozwoli zaoszczędzić timer, który może przydać się do czegoś innego.
Nigdy nie ośmieliłbym się twierdzić, że moje rozwiązanie jest najlepsze czy jedynie słuszne. Jeśli ktoś w ten sposób odebrał moje wypowiedzi, to przepraszam jeszcze raz. Starałem się tylko znaleźć sposób, który będzie najmniej obciążał procesor podczas transmisji, aby można było powierzyć mu jeszcze inne zadania.