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