Hej mam taki problem z kompilatorem AVR GCC - na moj gust zglupial lub pewnei robie cos zle. jest takie powiedzenie, jesli twierdzisz ze kompilator jest glupi - idz spac. ale nie w tym rzecz. mam wynik pomiaru w postaci liczby 32 bit (wynik z ukladu TCD pomiaru czasu z rozdzielczoscia 7ps(sic!)) i potrzebuje go przemnozyc przez stala 7.629453 nie chce uzywac arytmetyki zmiennoprzecinkowej, zreszta z jakis powodow ona tez nie dziala.
Wynik wydaje zawijac sie gdzies na 16 bitach lub wczesniej. nie pomaga zadeklarowanie liczb jako 1000000ULL, jedyny efekt uboczny to taki ze objetosc kodu zwieksza sie o 4KB - widac kompilator wlacza biblioteki 64bit?? o robie zle? pewnie znow sie okaze ze gdzies do zmiennej powinienem byl dodac jakas literke...
z innej beczki: czy spotkaliscie sie z bibliotekami w C konwerujacymi np U32 na BCD? napisalem sobie wlasne,ale na pewno nie sa optymalne jesli chodzi o kod, a pewnie istnieja gdzies eleganckie napisane w ASM...
Didn't find your answer? Ask the community — no account required.
I
invalid unparseable
Witam.
U¿ytkownik "Greg(G.Kasprowicz)" snipped-for-privacy@gmail.com napisa³ w wiadomo¶ci news:eg6er3$dk$ snipped-for-privacy@news.onet.pl...
A jeste¶ pewien, ¿e TDC daje Ci to czego oczekujesz ? Na którym TDC pracujesz ? Acam ? MSC ? jeszcze inne ? Ja czasami dostaje dziwne wyniki z TDC GP1
Pozdrawiam
Jarek Grolik
G
Greg(G.Kasprowicz
tak, TDC GP1 - ogldam w hexie i jest idealnie. Obok porownuje ze zgrubnym odczytem z oscyloskopu
ten sam problem mam z odczytem czasomierza zaimplementowanego w FPGA - chce przemnozyc liczbe 32bit przez 6.66666ns, i identyczny problem..
BTW: do czego uzywasz GP1?
- ja do pomiaru szeroksoci impulsow z akceleratora oraz dlugosci impulsow laserowych w dalmierzach.
M
mk
Oj zdarza siê, ¿e kompilator robi psikusy. Kto mia³ do czynienia z MSVC6 ten wie :-)
W ostatniej linii prowadzisz obliczenia na liczbach 32 bitowych. Dopiero przy przypisaniu nastêpuje konwersja na liczbê 64 bitow±. To za pó¼no.
pzdr mk
A
Adam Dybkowski
Greg(G.Kasprowicz) napisał(a):
[...]
Musisz pamiętać, że sposób obliczania jest niejako narzucony przez pierwszą operację. Czyli w powyższym mnożeniu liczby 32-bitowej calc_temp1 przez 32-bitową stałą 7629453UL już masz problem - będzie przepełnienie i obcięcie. Potem dzielisz to przez kolejną 32-bitową stałą 1000000UL i nic sensownego z tego działania nie pozostanie.
Powinno zadziałać takie rozwiązanie (sprawdź): uint64_t a, b, c; a = TDC_Read(0); b = (a * 7629453ULL) / 1000000ULL;
Jeżeli a jest 32-bitowe to przed mnożeniem zrzutuj je na 64 bity: b = (uint64_t) a * 76294... I jak poszło? Pamiętaj, że stałe 64-bitowe w AVR wymagają dopisku LL / ULL.
G
Greg(G.Kasprowicz
tak tez podejrzewalem. dlatego probowalem z tym ULL, tyle ze troche widac za pozno.
tylko teraz, dlaczego dlugosc kodu wzrasta o te 4kB? az tyle zajmuja procedury mnozenia 64 bit? w asemblerze 8051 mnozylem nawet liczby 96bit i zajmowalo kilkaset Bajtow. Czy da sie jakos ograniczyc ilosc tego marnowanego kodu?
A
Adam Dybkowski
Greg(G.Kasprowicz) napisał(a):
Obejrzyj w mapie linkera (i ew. listingu po deasemblacji) jakie funkcje zajęły najwięcej. Mnożenie 64-bitowe bez problemu napiszesz na kolanie i zajmie mniej niż kilkaset bajtów. Albo ściągnij gotowe z Sieci.
J
J.F.
No i jak chcesz przemnozyc przez 7,629453 to moze szybciej bedzie przemnozyc przez 32768251121 a potem "podzielic" przez 2^32
J.
J
J.F.
Hi hi - a duzo masz czasu ?
Bo jesli na jedno wejscie sumatora podasz liczbe, a na drugie jego wyjscie podzielone przez 4, to po chwili wyjscie narosnie do we*1.33333(3)
przemnozmy to przez 2, otrzymamy 2.666666(6), pozostaje dodac 4*we.
Glowy nie dam czy wynik bedzie zawsze stabilny, no i przydaloby sie dla wiekszej dokladnosci najpierw wejscie "przemnozyc" np *8, a na koniec podzielic/4
Swoja droga byc moze to ma calkiem ladna postac funkcji zminimalizowanej .. tylko czym ja wygenerowac :-)
J.
I
invalid unparseable
U¿ytkownik "Greg(G.Kasprowicz)" snipped-for-privacy@gmail.com napisa³ w wiadomo¶ci news:eg6gsm$5t4$ snipped-for-privacy@news.onet.pl...
Ja staram siê zrobiæ na nim precyzyjn± i szybk± hercmiarkê, ale niestety nie uda³o mi siê z nim dogadaæ zbyt dok³adnie poprzez LPT i teraz bêdê go wpierw podpina³ pod uC i dopiero do kompa. U¿ywam trybu MB2 i dostaje stabiln± czê¶æ ca³kowit± , natomiast FineCount gania w te i we w te. Uprzedzê , ¿e czêstotliwo¶æ odniesienia to wzorzec rubidowy :-) Robiê to do pomiarów QCM.
Pozdrawiam
Jarek Grolik
PS: Jak odczytujesz z niego kolejne wyniki z rejestrów 16 bitowych , to CS jest ca³y czas aktywny i tylko podajesz kolejne stroby READ , czy te¿ CS równie¿ podnosisz ? Móg³by¶ podrzuciæ kawa³ek kodu odpowiedzialnego za inicjalizacjê i odczyt ?
PS2 : Jest te¿ ciekawy TDC innej firmy. TDC502 nawet chyba lepiej dopracowany
J
J.F.
hi hi - jeszce jedno podobne: - nie dodawac, tylko odejmowac polowe. Wynik sie ustali na 0.666666(6) .. czyli najpierw przemnozyc przez 10 [jeden sumator].
Hm, z sumowaniem chyba bedzie, ten z odemowaniem to nie dam glowy :-)
J.
G
Greg(G.Kasprowicz
tez o tym pomyslalem, bedzie chyba szybciej,skoro i tak juz mnoze, to odpadnie dzielenie, bo potem tylko wezme starsza czesc
ja dla odroznienia uzywam trybu 1-szego interesuje mnei zakres 2ns...1us kody podalem w innym watku
G
Greg(G.Kasprowicz
dzieki, zadaialalo jednakze ostatecznie podzielilem wynik pomiaru na 3 zakresy co 1024 :) i od razu mi wyswietla w ns, us, ms co jest bardziej intuicyjne niz rzad 9 cyfr, z czego i tak 2 ostatnie mrugaj na najwyzszym zakresie (1s range/6ns bin)
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.