Witam
Zaskoczył mnie mocno czas trwania operacji wysyłania komendy na terminal PUTT-y. Poniżej wklejam wycinek kodu, uproszczony tylko do komend wysyłających liczbę na terminal. W docelowym programie zamiast liczby jest wynik z ADC czyli prawie jak w poradniku Mirka na temat "kolorowego wyświetlacza UART". Specjalnie wyremowałem wszystko inne żeby mieć "goły" czas jaki zajmuje wysyłanie danych na UART. Czas jaki zajmuje obsłużenie wyświetlania/przesyłu danych to 37,2ms. Czyli pętla główna jeśli miałaby w sobie tylko poniższe operacje przesyłu danych po UART wykonywałaby się z częstotliwością ok 27Hz (co 37 ms). Gdybym chciał na bieżąco wysyłać wartość PWM programowego + wartość z ADC (np z kilku kanałów) to nie starczyło by mi czasu na nic innego). Czy to jest dobrze, tak ma być? Czy coś pokręciłem i dla tego u mnie to tyle trwa?

A może nam powiesz z jaką prędkością ten UART pędzisz? Druga sprawa czym dokonujesz pomiaru tego czasu?

_________________
sig off ;(

Fakt prędkość to dość istotna sprawa, zapomniałem .
Procesor ATmega32 8MHz, UART 19200
Pomiar czasu robię tak, że przed blokiem wysyłania komend na UART zapalam diodę a po zakończeniu od razu jest komenda gaszenia diody LED. Oscyloskop podłączony do diody pokazuje mi dokładnie ile czasu trwało włączenie led-a czyli ile czasu zajęło wykonanie instrukcji "obsługi" UART-a. Oczywiście dochodzi do tego czas włączenia diody i gaszenia. ale to nie istotne przy czasie rzędu 37ms.

No ale co ty liczysz tak w ogóle ? czas czego ? samej transmisji danych ? nie panie kolego - ty liczysz kompletnie tutaj, hmmm niepotrzebnie, żeby delikatnie to określić, - czas przesyłania KUPY (tak kupy) niepotrzebnych, ZUPEŁNIE zbędnych informacji na terminal - toż to masakra

Wywal więc te wrzystkie tr_locate(), tr_pen_color(), wysyłanie spacji, włączanie wyłączanie kursora ... itp itd - aż ci mina zrzednie gdy policzysz wtedy czas przesłania samego

uart_putint(200,10);
uart_putint(100,10);

po drugie co tu obliczać jakiś czas ręcznie w oparciu o to co leci na terminal kolorowy z bajerami....

toż ile masz tu bajtów do przesłania ? ja widzę dwie liczby w postaci ASCII po 3 bajty czyli łącznie 6 bajtów tak ?

No to panie kolego - ile czasu trwa przesyłanie bajtu po RS232 z konkretną prędkością - niech będzie twoje 19200 ? hmmm? Zakładając , że masz 1 bit startu, 1 bit stopu, bez bitu parzystości i ramkę 8 bit ?

19200 bodów oznacza 19200 pełnych ramek na sekundę tak ?

no więc

1/19200 = 0,000 052 .... czyli jedna ramka z jednym bajtem leci ci w ciągu ok 52 us !!! a że masz 6 takich pełnych ramek to ile ? to = ok 312 us !!!

o ile się nie pomyliłem 6 bajtów masz przesłane w ciągu ok 312 us panie kochany

tylko jak będziesz wysyłał to do sterowania jakimś urządzeniem to nie będziesz się przecież bawił w takie kolorowe chocki klocki z jakimś terminalem

zorganizujesz sobie przesył danych w ASCII w jakiejś ramce, ładnie z separatorami nawet czyli np:

"200,100"

i nawet jak będziesz miał 7 bajtów to nadal zajmie ci to tylko ok 364 us

teraz jaśniej ?

to sprawdź teraz sobie (przelicz) że wystarczy ci do tego nawet mniejsza prędkość jak 9600 bodów (nie na darmo używana jako standard w przemyśle)

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Program obsługuje dwa silniki DC sprzężone z potencjometrami których wartość chciałem przedstawić na ekranie PC. Na początku zrobiłem zwykłe wysyłanie wartość z ADC za pomocą komendy

Niestety taki sposób powoduje ciągłe przewijanie wartości na ekranie przez co jest bardzo nieczytelny. Zafascynowany poradnikiem o kolorowym wyświetlaczu chciałem to zrobić tak samo. Wysłałem na UART wartość dwóch potencjometrów, wartości dwóch PWM-ów silników, różnicę pomiędzy potencjometrami. Do tego opisy co dane wielkości znaczą i kicha. Niestety okazało się, że zabrakło procesorowi czasu na resztę programu. Nie wiedziałem jak to wyliczyć. Dzięki twojej wypowiedzi wyżej już wiem  ,więc w podłączyłem oscyloskop pod LED-a i w ten sposób sprawdzałem czasy poszczególnych instrukcji. Faktycznie okazało się, że wysłanie pojedynczych instrukcji „uart_putc('\r');” to naprawdę niewielki czas jaki zabieram procesorowi w porównaniu z wysyłaniem pozycjonowania, koloru, wygaszania kursora itd.
Oglądając wyżej wspomniany poradnik nie zanotowałem nigdzie uwagi, że jest to tak czasochłonne. Zachęcony przez Ciebie Mirku wstawiałem sobie to i to i jeszcze tamto do wyświetlenia. No i się dowiedziałem, że tak bezkarnie to ja nie mogę sobie szastać instrukcjami.


Mirku. Piszesz, że wysłanie uart_putint(200,10); to trzy bajty, a pełna ramka to 1 bit startu, 1 bit stopu, bez bitu parzystości i 8 bitów danych, tak? Czyli wysłanie uart_putint(200,10); to trzy ramki i przy prędkości 19200 to 156us. a…cha Takie proste a nie wiedziałem ciekawe ilu jeszcze rzeczy nie wiem, a wydaje mi się, że wiem.
Dzięki

Możesz - a kto ci zabroni to robić na terminalu ?

Po prostu nie rozumiesz całkowicie DWÓCH różnych podejść do tematu.

1. terminala używamy hmm albo do prezentacji wyników dla oka ludzkiego ew zdalnego sterowania - do wygody sterowania (zwykle wtedy nie zależy nam na szybkości przesyłanych danych)

2. gdy sterujemy jakieś urządzenie - to pomyśl - po co nam przesyłać całe te nadmiarowe dane, których i tak nikt nie zobaczy. Ot drugie urządzenie ma odebrać bajty i wykonać jakiś rozkaz

teraz jaśniej ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Myślę, że rozróżniam różnice. Wydaje mi się nawet, że jest to dla mnie logiczne.
W moim przykładzie chciałem zbudować funkcjonalny program obsługi dwóch silników gdzie użytkownik musi mieć informację w jakim położeniu jest jeden i drugi potencjometr. Chciałem to przedstawić właśnie na kranie PC w bajerancki kolorowy sposób. Po prostu nie do końca zrozumiałem poradnik o kolorowym wyświetlaczu, a właściwie to zabrakło mi podstawowej wiedzy o UART itp. Myślę, że jest to konsekwencja uczenia się programowania w dość chaotyczny i nieregularny sposób. Ale co tam, w końcu mam, mamy ciebie Mamy z czego czerpać.
Pozdrawiam serdecznie.

Spokojnie - najważniejsze to małymi kroczkami ale "do przodu!" .... poza tym jak sam widzisz - na takich doświadczeniach człowiek się na prawdę uczy. Gorzej gdy inni w tym czasie tylko teoretyzują zamiast coś fizycznie wykonać i sprawdzić, dotknąć - jak to działa

Jeśli chodzi zaś o prezentację wyników takiego sterowania to jak widzisz - taki kolorowy terminal ma pewne ograniczenia, ale ....

ale nawet na naszym forum masz fajne kursy (pisane przez naszych szanownych użytkowników) programowania na PC w języku C# z wykorzystaniem komunikacji Rs232. Napisanie takiej prostej apki do przechwytywania tych nadlatujących danych (samych danych do sterowania twoimi silnikami) bez tego nadmiaru do kolorowego terminala ... pozwoli ci zrealizować pewnie twoje pierwotne założenia. Bo to sama apka będzie robić ładne kolorowe ramki , ew wykresy czy inne bajery na ekranie .... Oczywiście jeśli to sobie ładnie oprogramujesz - a to też nie jest takie trudne - gdy poczytasz te poradniki na forum

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wiem, że temat był dość dawno ale wpadłem na niego szukając w internecie informacji o czasie trwania ramki rs232. Mirek pisze, że


czy on tutaj się pomylił czy to ja jakoś źle myślę? Nie powinno być, że 19200 bodów na sekundę to jest 19200 bitów na sekundę, czyli jak ma do wysłania liczbę 200 czyli 3 bajty, każdy po 10 bitów (1 start, 8 dane, 1 stop) to czas wysłania całości wyniesie 30 bitów x 52us=1,56ms a 6 bajtów to 60 bitów x 52us =3,12ms?
52us trwa jedna ramka czy raczej jeden bit?

Małe uściślenie: nie ma bodów na sekundę, są body (tutaj można przyjąć że: bod= bit na sekundę).

ps.
A a czasami somebody.

to po jakiego grzyba ktoś wymyśliłby jednostkę "bod" ??? pomyślałeś o tym?

a wystarczy zajrzeć chociażby do wikipedii

https://pl.wikipedia.org/wiki/Bod

szybko się przekonasz że bod nie oznacza bit/s

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Do dobrze, czyli body to jest ilość zmian sygnału w ciągu jednej sekundy. I jeżeli nie jest użyte żadne kodowanie sygnału tak jak w naszym przypadku to będziemy mieli ze 19200 bodów to 19200 bitów na sekundę (oczywiście dla naszego przykładu )

A moje obliczenia są dobre czy nie? Bo nie będę mógł spać w nocy i będa mi się te body siły :=)

Wysłane z mojego WAS-LX1 przy użyciu Tapatalka

Wyspałeś się, czy męczyły Cię w nocy body?

Przy prędkości 19200 bps i formacie ramki 8N1 czas przesłania jednej ramki (10 bitów = 1 bit startu + 8 bitów danych + 1 bit stopu), to 10/19200 s = 0.5208 ms.
A to nie jest Twoje 52 us ...

Przesłanie 3 znaków wymaga w naszym wypadku 30 bitów, czyli zajmie 30 / 19200 = 1.5625 ms (albo jak kto woli liczyć na ramkach to 3 * 0.5208 ms). A przesłanie 6 znaków trwa dwa razy dłużej, czyli 3.125 ms.

--
Pozdrawiam,
Robert

Wyspać się nie wyspałem ale to z innych powodów

Czyli dobrze obliczyłem. Moje 52us to czas jednego bitu.

Jestem wdzięczny za okazaną mi pomoc. Dawno nie robiłem nic na uC bo nie było czasu i teraz trzeba sobie wszystko przypominać

Wysłane z mojego WAS-LX1 przy użyciu Tapatalka