Jak utrzymać stan wysoki na pinie Arduino podczas pełnej transmisji danych przez UART?

Sat Aug 25, 2018 3:43 pm   

Hejka.
Fragment kodu:

digitalWrite(pin, HIGH);
Serial.print(dane);
digitalWrite(pin, LOW);

Czyli ustawiam stan wysoki na pinie, wysyłam jakieś dane na sprzętowy
port szeregowy, ustawiam stan niski na pinie. Chcę by stan wysoki na
pinie był obecny przez czas trwania transmisji przez port szeregowy, a
nie, jak się domyślam, tylko podczas pisania do bufora (stan wysoki jest
tylko przez chwilę, podczas gdy dane wysyłane są przez uart dalej).
Jak to zrobić programowo?

Sat Aug 25, 2018 3:43 pm   

On 25.08.2018 15:43, Michał Czarkowski wrote:


Arduino ma pod spodem zwyczajny toolchain AVR od Atmela. Wciąż możesz
używać nazw rejestrów mikrokontrolerów z tej rodziny. Napisz więc sobie
kilka podstawowych funkcji, odwołujących się bezpośrednio do rejestrów.

Najpierw coś w rodzjaju:

void uart_putc (char data) {
BUFOR_NADAWCZY = data;
while (REJESTR_STANU_UART & MASKA_PINU_STANU_NADAJNIKA);
}

a potem:

void uart_puts (char *str) {
while (*str) {
uart_putc(*str);
str++;
}
}

Oczywiście nazwy rejestrów musisz podmienić na te odpowiadające
konkretnemu UART-owi w mikrokontrolerze użytym w danym Arduino.

Potem po prostu w programie wywołujesz uart_puts.

Sat Aug 25, 2018 5:31 pm   

W dniu 2018-08-25 o 15:43, Michał Czarkowski pisze:

A kolega to cokolwiek przeczytał w dokumentacji?
https://www.arduino.cc/en/Serial/Flush
https://forum.arduino.cc/index.php?topic=487082.0

--
Pozdrawiam
Piotrek

Sat Aug 25, 2018 8:34 pm   

Sat Aug 25, 2018 8:40 pm   

W dniu Sat, 25 Aug 2018 16:36:30 +0200, użytkownik Atlantis napisał:


Dzięki za podpowiedź. Właśnie zrobiłem sobie przerwę w czytaniu pdf od
microchipa i kolega w poscie poniżej naprowadził mnie na Serial.flush().
To rozwiązuje mój mały problem.

Sun Aug 26, 2018 6:51 pm   

Piotr Dmochowski <imie_nazwisko@poczta.onet.pl> wrote:

Flush zawsze służył do asynchronicznego opróżnienia buforów portu
szeregowych w przygotowaniu na nową transmisję.

Dziwna to dla mnie decyzja zmiany tej funkcjonalności i wykorzystanie
istniejącej funkcji do drastycznie innego celu...
Nie lepiej było dodać nową funkcję biblioteczną o nazwie np.
waitTXbuffempty(int timeoutSeconds) z argumentem w postaci timeoutu?
Co, jeśli transmisja jest z handshake CTS/RTS i jest zablokowana sygnałem
CTS i program zwiśnie na zawsze??

Sun Aug 26, 2018 8:47 pm   

Pszemol <Pszemol@PolBox.com> napisał(a):

Jak najbardziej racja. To typowy przykład wynajdywania przez Arduino koła na
nowo. A potem ludzie się dziwią, że miało być prościej a jest trudniej :)

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Wed Aug 29, 2018 12:06 am   

Pszemol <Pszemol@polbox.com> wrote:


Wejściowych.

Domyślam się, że zachowanie jest podobne do fflush(3).

http://man7.org/linux/man-pages/man3/fflush.3.html

For output streams, fflush() forces a write of all user-space
buffered data for the given output or update stream via the stream's
underlying write function.

For input streams associated with seekable files (e.g., disk files,
but not pipes or terminals), fflush() discards any buffered data that
has been fetched from the underlying file, but has not been consumed
by the application.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

Wed Aug 29, 2018 12:07 am   

Queequeg <queequeg@trust.no1> wrote:


A jednak miałeś rację, wyjściowych też :)

https://linux.die.net/man/3/tcdrain

#v+
tcdrain() waits until all output written to the object referred to by fd
has been transmitted.

tcflush() discards data written to the object referred to by fd but not
transmitted, or data received but not read, depending on the value of
queue_selector:
#v-

Czyli powinni nazwać drain, a nie flush...

--
https://www.youtube.com/watch?v=9lSzL1DqQn0