tak naprawdę trzeba by zmierzyć jak kod zachowuje się dla VFO QRG 1 MHz 10MHz i 100MHz ... czy szybkość liczenia dla danego języka zależy od długości liczby :-)
i ważne... nie róbmy w pętli (często powtarzane to samo) ... tego co nie musimy czyli liczenie "stałych" ... a zwłaszcza po co dzielić jeśli nie trzeba :-)
jak znajdę czas to zmierzę ile to zajmuje czasu... ale praktycznie np 10000 powtórzeń dla liczny 1 MHz i 10 i 100 MHz..
jak widac u mnie jest tylko jedno MNOŻENIE i niejawne ROUND :-)
ci co śledzili moje wypowiedzi w wątku o C ... zauważyli że do tesowania programu użyłem "debugowania" przez RS232 :-) o którym podpowiadałem że jest bardzo przydatne do podglądania wyników pośrednich :-)
na święta. ... szybko liczącego zajączka ... :-) od Jarka dla Wszystkich
(Ten post był ostatnio modyfikowany: 06-04-2012 18:11 przez SP3SWJ.)
06-04-2012 18:09
SQ6OXK
Paweł
Liczba postów: 317
Dołączył: 23-06-2010
Oczywiście masz rację, że w warunkach "naturalnych" nie liczymy co chwila 2^32*f_vfo/f_clk i co drugi z czytających pewnie już zuważył, że ciagłej zmianie ulega tylko f_fvo.
Podobnie jest ze nazwami zmiennych, zastosowanie krótkich nazwy daja na potrzeby testów większą przejrzystości kodu.
Jeden z moich pierwszych nauczycieli programowania (PASCAL na PC) mawiał, że nazwy zmiennych powinny byc jednoznaczne, ale nie przesadzajmy z ich długości, bo w pewnym momencie sami zaczniemy się na nie denerwować, gdy poraz 40-ty bedziemy musieli wklepać tak długa nazwę.
Z historii:
Pamiętam, że starcze dosowe komilatory, chyba nawet niektóre na '51, rozpoznawały w nazwie zmiennej tylko pewną część poczatku, chyba pierwsze 30 znaków. Sam miałem kiedyś taki kłopot
Jak wpomniał Adam celem tego wątku nie jest nauka pisania i opytamilacji kodu, ale prównanie konkretnego przykładu, napisanego analogiczne w różnych językach.
Jarku dal Ciebie oraz dla wszystkich pozostałych czytaleników forum wszystkiego najlepszego z okazji Świąt.
--= SWL SP6-01-396 =--
06-04-2012 23:15
SP3SWJ
Jarek
Liczba postów: 653
Dołączył: 20-03-2010
:-) Paweł - po pierwsze dzięki że zwróciłes moją uwage na NOWY typ zmiennych DWORD jaki pojawił się w BASCOM - to zwiększa możliwości. można używać jej do 4,2 GHz
(06-04-2012 23:15)SQ6OXK napisał(a): .....
Podobnie jest ze nazwami zmiennych, zastosowanie krótkich nazwy daja na potrzeby testów większą przejrzystości kodu.
....
Niestety będę uparty jak świąteczny baranek :-) aliasy krótkie tak... ale w jakikolwiek związane z zagadnieniem które reprezentują...
Nie traktuj tego że Ciebie palcami wytykam ... chodzi mi tylko by potencjalny "co drugi" się nie zastanawiał za długo zanim zrozumie.
Robiąc porównanie - starajmy się wycisnąć maksymalnie co się da z danego języka... i dlatego .... kilka kolejnych "porad"
A może na początek pewna propozycja założeń praktycznego porównania języków - wykonanie najprostszego VFO o określonej podstawowej funkcjonalności
1 - obsługa encodera graya ( np na jednej lini przerwania)
2 - wpisywanie QRG i konfigurowanie zegara przez RS232 (RS pracuje w przerwaniu i można zapytać o QRG jakie mamy ustawione.
3 - i LEDka która miga z 1 Hz taktem... a normalnie procesor czeka sobie w "pustej pętli"
... LCD narazie można sobie odpuścić.. to można dać w drugim kroku zabawy... ale taka obsługa LCD by nie wysyłac nowego QRL na LCD cześciej niż co 10 ms ... ważniejsza jest płynna obsługa naszej gałki... bo w odbiorniku SSB ucho jest bezwzględne ... a oko nie zauważy problemu
Czyli kto ma czas przystępuje do "eksperymentu" robi VFO sobie znanym środowiskiem ...
Zadaniem jest takie napisanie kodu by maksymalnie (sensownie) szybko kręcąc gałką VFO nie przeskakiwało. Optymalizacja kodu ma na celu by szybko liczyło.... ale także by w przypadku VFO kręcąc gałka z enkoderem 256 impulsów... VFO nie rwało a płynnie się przestrajało...
Czyli dodawanie QRG VFO robimy na zmiennych "maksymalnie małych" jakie nam wystarczą u nas będzie to DWORD jeśli zakładamy 1Hz rozdzielczość ..
a dopiero przy wysyłaniu do DDS robimy liczenie...
.... może coś znajdę czas na wyjeździe świątecznym coś naskrobię... ale kurcze nie wziąłem enkodera..
Beeeeee :-) pozdrowienia od Baranka...
07-04-2012 0:12
SQ6OXK
Paweł
Liczba postów: 317
Dołączył: 23-06-2010
Bo trzeba by było stworzyć jednolite warunki do testów i to zarówno sprzętowe jaki i programowe.
Jest jeszcze problem jak określić szybkość działania kodu?
W poprzednim przypadku program liczył i kończył prace co dawało jasny obraz ile na to potrzebował cykli procesora.
W Twojej propozycji trzeba by było wykonać, pomiar kilku określony kawałków kodu, bo program pracuje w pętli, a do tego może sobie "wyskoczyć" w jakieś przerwanie.
Moja propozycją jest taka, zaproponuj kod, a ja go przerobię na C (WinAVR), a jeśli masz bazę sprzętową do testów będziesz mógł sprawdzić czy nie popełniłem błędu.
--= SWL SP6-01-396 =--
07-04-2012 8:08
SP3SWJ
Jarek
Liczba postów: 653
Dołączył: 20-03-2010
(07-04-2012 8:08)SQ6OXK napisał(a): I tu Jarku pojawia się problem.
.....
Moja propozycją jest taka, zaproponuj kod, a ja go przerobię na C (WinAVR), a jeśli masz bazę sprzętową do testów będziesz mógł sprawdzić czy nie popełniłem błędu.
1. :-) nie "problem" a .... ZADANIE :-) hihihi
2. i tu nie chodzi o klonowanie/odwzorowywanie kodu... ale o napisanie programu naturalnie bez sugerowania się - tak jak to robi sie naturalnie w danym języku.
Testowanie - ja do pomiarów szybkości fiuzycznej mogę użyć analizatora stanów logicznych który będzie podglądał pewne nogi procesora które będa wystawiały "1" jako punkty kontrolne. a inny pomiar to zapis sygnału DDS podczas kręcenia gałka na Waterfall odbiornikiem SDR czy nie ma uskoków przypełnym obrocie gałki 256 impulsów i pomiar QRG końcowej czy nie zgubił impulsu
dziś w nocy zrobiłem mały test - jakoże mam ograniczone narzędzia bo jestem na wyjeździe - do pomiaru uzyłem terminala co ma time stamp dla odebranego znaku.
Napisałem kod co:
- iteruje QRG
- liczy FTW
- wysyła do DDSa
zrobiłem pętlę FOR TO NEXT 10000 razy
zaczynając sywyła znak S ..... iteruje 10000 razy QRG i wysyła do DDS ... i wysyła literkę E
pomiar wyszedł
1.687s >> 1700 ms / 10000 => 0,168 ms jeden "cykl" iteracji+liczenia+wysłania SPI
bez wysyłania do DDS 0.936 s >>> ~~0,093 ms jeden cykl iteracji i liczenia FTW
procesor M128 ma zegar 11 MHz - kod testowany w pętli pomiarowej....
/ EDIT - czyli kompletna ITERACJA VFO=VFO+1 i obliczenie FTW i wysłanie do DDSa to poniżej 200 us :-)
EDIT2...
mogę za pomoca >>> analizatora stanów logicznych monitorować:
- obie nogi impulsatora
- nogę testową procka "1" wejście liczenie FTW "0" wyjście z liczenia FTW
- nogę testową procka "1" wejście w wysyłanie SPI "0" wyjście z wysyłania SPI
- wszystkie nogi SPI i dekodowanie
- nogi RS232 i dekodowanie
- itd ...
rozdzielczość pomiaru jest wystarczająco dobra :-)
mogę zakręcić impulsatorem i prześledzić szybkość odpowiedzi procka na przerwanie
itd itd...
Pomysł TESTOWANIA szybkości "języka" polega na tym by:
- mieć porównywalne wyniki.. :-)
- każdy robi na dowolnym AVR... i tuninguje ale najlepiej na tym samym modelu procka
- finalny kod testowy jest skompilowany i testowany na tym samym hardware
... najpierw testujemy same HEXY :-) nie podglądając... co kto wykombinował ( hihih element współzawodnictwa :-)
potem odkrywamy karty i pokazujemy nasz kod .. może każdy od każdego coś się nauczy :-)
ja już zdradziłem kilka sztuczek szybkiego używania BASCOMA ( dzięki Adam SP5FCS za dawniejsze testy z podglądaniem kodu i szukaniem "cyklożernych" operacji ....)
dlatego nie zawsze należy używac "wygód" języka .... FUNKCJE - owszem jak najbardziej ale nie do czegoś co trzeba powtórzyć kilka set racji w ułamku sekundy... ;-)
Ja się nie upieram "tylko bascom" .... bo pomału sam się przesiadam na COdeVision.... ale zobaczcie ...
to jest napisane w BASCOM:
- odczyt danych z karty SD (dos) - plik z filmem
- wurzucenie filmu na LCD KS0108
- Atmega 128 11MHz
..... około 20 klatek na sekundę :-)
SP3SWJ napisał(a):/ EDIT - czyli kompletna ITERACJA VFO=VFO+1 i obliczenie FTW i wysłanie do DDSa to poniżej 200 ns :-)
ale w to ci nie wierze chyba pomyliles jednostki.
Wysylasz do AD9951 ?? czy innego DDSa ?
Oczywista oczywistość błąd....
:-) Zdecydowanie 0,2 ms >> czyli 200 us :-) czyli słownie MICROSEKUND :-)
Pamietam jak robiłem pewna testową kompilację na CodeVisionn wysyłania danych na LCD to przełączając Kompilator pomiędzy optymalizacja rozmiaru i szybkość była duża zauważalna różnica w szybkości działania.
Biorąc do projektu procka z dużą ilością pamięci ( np szybki Xmega128A3 ) i lekko overclokując go na 48 MHz można już uzyskać coś całkiem szybkiego :-)
(Ten post był ostatnio modyfikowany: 09-04-2012 21:43 przez SP3SWJ.)
Czy ktoś próbował avr gcc z "-Os -mcall-prologues"? Według "AVR Libc - FAQ - Which -O flag to use?", ta kombinacja flag daje "najlepszy uniwersalny" poziom optymalizacji (a "-O3" daje kod dłuższy ale szybszy).
(Ten post był ostatnio modyfikowany: 12-04-2012 21:47 przez JaHo.)
12-04-2012 21:45
SQ8NVF
Bartłomiej
Liczba postów: 144
Dołączył: 05-12-2009
-Os -mcall-prologues to opcje, które zawsze mam włączone -Os to "opcja ta włącza optymalizację pod względem rozmiaru kodu wynikowego. Włączane są wszystkie optymalizacje z poziomu -O2 za wyjątkiem tych, które mogą skutkować zwiększeniem rozmiaru kodu wynikowego (...)" Natomiast opcja -mcall-prologues "powoduje użycie kodu prologu i epilogu wspólnego dla wszystkich funkcji, zamiast generowania go dla każdej z funkcji oddzielnie (...)" (cytaty za: Andrzej Witkowski - "Mikrokontrolery AVR programowanie w języku C")
Ta ostatnia funkcja daje duży zysk w ilości kodu, gdy mamy większą ilość funkcji, szczególnie krótkich. Wadą jest generowanie skoku do prologu i epilogu co wydłuża czas o wykonanie skoków.
(Ten post był ostatnio modyfikowany: 13-04-2012 10:13 przez SQ8NVF.)
13-04-2012 10:11
SQ6OXK
Paweł
Liczba postów: 317
Dołączył: 23-06-2010
można używać jej do 4,2 GHz
i dlatego .... kilka kolejnych "porad"
