HomeMade

to może moje 3 grosze...

starajmy sie pisac nazwy zmiennych tak by one coś znaczyły ( czytelność kodu)

INIT - ' to liczymy tylko raz po aktualizacji DDS_CLOCK - więc nie ma sensu tego umieszczać w pętli :-)

CALC ' funkcję jest elegancko użyc ale marnujemy dużo czasu na przeładowania stosu :-) lepiej G|OSUB i zmienna globalna - będzie dużo szybciej !!!




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 :-)

[attachment=5067]

---

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

Jarku,

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.

:-) 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...

I tu Jarku pojawia się problem.

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.

(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ę :-)

jak ktoś ma MAX6 - >>> może przetestować czy to prawda :-) ... po zabawie trzeba wgrać normalny program do MAX6 .

(07-04-2012 11:25)SP3SWJ napisał(a): [ -> ]bez wysyłania do DDS 0.936 s >>> ~~0,093 ms jeden cykl iteracji i liczenia FTW

w to jestem w stanie uwierzyc

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 ?

---

(01-04-2012 23:59)SP5FCS napisał(a): [ -> ]... Wynik końcowy TEST_1, assebmler AVR dla ATmega32
Kod: 162 bajt (8+154) - inicjowanie, program główny, funkcja obliczania FTW
Cykle: 1774 (4+1770)
RAM: 12 bajt - 3 zmienne w RAM po 4 bajty
Wynik: 0x0CCCCCCC ...

Adam, robiac ten kod nastawieales sie bardziej na predkosc dzialania czy maly rozmiar programu ???

(09-04-2012 19:29)SP4EJT napisał(a): [ -> ]

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 :-)

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).

(12-04-2012 21:45)JaHo napisał(a): [ -> ]Czy ktoś próbował avr gcc z "-Os -mcall-prologues"? Według "AVR Libc - FAQ - Which -O flag to use?"(...)

-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.

No niestety Jarku mnie filmiki nie chcą działać

Próbowałem z dowma kartami SD, ale niciewo nie widać (tylko krzaczki)