---

Hey

Først, dette er uC relatreret og jeg regner med at bruge keil...

Jeg legede lige med at gange 2 floats sammen, og det ser ud til at tage alt
for lang tid...

Er der nogle der ved om det er muligt kun at bruge 16bit float i keil, og
evt hvordan ?

Kan man komme til at regne med 16 bit fixed point, for det vil vel gå
stærkere..

jeg skal gerne så langt ned i tid jeg kan nå at lave 2 gange og nogle adder
på 20uS hvilket svarer til mindre end 330 cycles og en normal muliply tager
vidst omkring 9 cycles...

er der nogle måder jeg kan gange decimal tal sammen på hurtigere.. evt et
lib eller helst integreret i keil

Kasper

---

Repzak <repzak@GEDhotmail.com> wrote:

> Først, dette er uC relatreret og jeg regner med at bruge keil...
>
> Jeg legede lige med at gange 2 floats sammen, og det ser ud til at
> tage alt for lang tid...
>
> Er der nogle der ved om det er muligt kun at bruge 16bit float i
> keil, og evt hvordan ?

Keil C51 - jeg gætter på at du kører 8051 - understøtter kun 32-bit float.

> Kan man komme til at regne med 16 bit fixed point, for det vil vel gå
> stærkere..

Ja, det vil det normalt. Keil understøtter det ikke direkte, så du må selv
styre kommaet og bruge integers. Husk at når du ganger to 16-bit int's i
C51, bliver resultatet de nederste 16 bit. Det er normalt ikke dem du
ønsker ved fixed point, så du må caste operanderne til long (32 bit) før du
ganger. Dermed laver compileren en 32-bit multiplikation, hvilket også er
temmeligt langsomt på 8051. Ellers må du selv lave multiplikationsrutiner i
assembler som kun regner den del af resultatet ud, som du skal bruge.

> jeg skal gerne så langt ned i tid jeg kan nå at lave 2 gange og nogle
> adder på 20uS hvilket svarer til mindre end 330 cycles og en normal
> muliply tager vidst omkring 9 cycles...

Det kan du ikke med en standard 12 MHz 8051. En 8x8->16 unsigned mul tager
4 cycles à 12 clocks = 48 clocks, og dem skal du bruge mindst 3 af for at
lave en 16x16->16 mul. Derudover kommer en mængde mov og add, som nok tager
længere tid.

> er der nogle måder jeg kan gange decimal tal sammen på hurtigere..
> evt et lib eller helst integreret i keil

Find en hurtigere processor. Mange laver 8051-kompatible processorer med
hurtigere clock og færre clocks pr. cycle (Philips, Analog Devices, Silicon
Labs).

Eller vælg en ARM7 baseret processor, som f.eks. Philips LPC2xxx eller Atmel
AT91SAM7Sxx. Sådan en kan sagtens lave 32-bit floating point i software med
din krævede hastighed. Brug Keils nye ARM-compiler, eller GNU gcc
( http://www.gnuarm.com ). Jeg bruger selv Philips LPC2114 sammen med gcc
og vil nødig gå tilbage til 8051.

Karl Olsen
http://karl.rudbaek-olsen.dk

---

> 4 cycles à 12 clocks = 48 clocks, og dem skal du bruge mindst 3 af for at
> lave en 16x16->16 mul. Derudover kommer en mængde mov og add, som nok
> tager
> længere tid.

single cycle...


> hurtigere clock og færre clocks pr. cycle (Philips, Analog Devices,
> Silicon
> Labs).
det er en aduc842



> Eller vælg en ARM7 baseret processor, som f.eks. Philips LPC2xxx eller
> Atmel
> AT91SAM7Sxx. Sådan en kan sagtens lave 32-bit floating point i software
> med
> din krævede hastighed. Brug Keils nye ARM-compiler, eller GNU gcc
> ( http://www.gnuarm.com ). Jeg bruger selv Philips LPC2114 sammen med gcc
> og vil nødig gå tilbage til 8051.

Jae tror jeg vil igang med aduc's arm7 7000 serien...
men i princippet var det ikke fordi jeg skal bruge det filter i den uC til
noget, det er mere bare for at lave det og se det kører så derfor regnede
jeg måske med man kunne få et lille filter til at køre ved 1khz eller
noget..

jeg har set nogle lave det i en atmega163 med 8Mhz... så de burde kunne give
sig

Kasper

---

> > jeg skal gerne så langt ned i tid jeg kan nå at lave 2 gange og nogle
> > adder på 20uS hvilket svarer til mindre end 330 cycles og en normal
> > muliply tager vidst omkring 9 cycles...
>

Er det fordi du SKAL bruge så stor dynamik område som float tilbyder ?
Signalbehandlingshajer betragter tit floats som snyd. Det er meget bedre at
få sin signalgraf passet til, så man kan klare det med 8/16 bit integers.

Mega128 linien har hardware fractional multiplier, hvilket er som skabt til
dette formål. (Fractional tal er altid mellem -1 og 1, og når man ganger dem
kan de altid være i samme størrelse register).

tpt

---

Troels Thomsen wrote:

[SNIP]

>
> Er det fordi du SKAL bruge så stor dynamik område som float tilbyder ?
> Signalbehandlingshajer betragter tit floats som snyd. Det er meget bedre at
> få sin signalgraf passet til, så man kan klare det med 8/16 bit integers.
>
> Mega128 linien har hardware fractional multiplier, hvilket er som skabt til
> dette formål. (Fractional tal er altid mellem -1 og 1, og når man ganger dem
> kan de altid være i samme størrelse register).

Det er ikke helt rigtigt, hvis man ganger to 16 bit værdier fylder
resultatet 32 bits. For to fixed point 1.15 værdier bliver resultatet
1.31, og det er nødvendigt at trunkere eller afrunde, for at komme ned
på 1.15 igen. Derfor er mange DSP'er også forsynet med "lange"
MAC-resultat registre (f.eks. 40 bit i ADSP-21xx).


--
Med venlig hilsen / Kind regards
Jesper Larsen
Dansk Forening for Rosport: www.roning.dk
Aarhus Studenter Roklub: www.asr.dk

---

> > (Fractional tal er altid mellem -1 og 1, og når man ganger dem
> > kan de altid være i samme størrelse register).
>
> Det er ikke helt rigtigt, hvis man ganger to 16 bit værdier fylder
> resultatet 32 bits. For to fixed point 1.15 værdier bliver resultatet
> 1.31, og det er nødvendigt at trunkere eller afrunde, for at komme ned
> på 1.15 igen. Derfor er mange DSP'er også forsynet med "lange"
> MAC-resultat registre (f.eks. 40 bit i ADSP-21xx).
>

Ja, det var dårligt formuleret, men er du ikke enig i at ét af argumenterne
for at bruge fractional er netop at det er så let/billigt at tage dette
aktive valg at trunkere?

tpt

---

Troels Thomsen wrote:
>> > (Fractional tal er altid mellem -1 og 1, og når man ganger dem
>> > kan de altid være i samme størrelse register).
>>
>> Det er ikke helt rigtigt, hvis man ganger to 16 bit værdier fylder
>> resultatet 32 bits. For to fixed point 1.15 værdier bliver resultatet
>> 1.31, og det er nødvendigt at trunkere eller afrunde, for at komme ned
>> på 1.15 igen. Derfor er mange DSP'er også forsynet med "lange"
>> MAC-resultat registre (f.eks. 40 bit i ADSP-21xx).
>>
>
> Ja, det var dårligt formuleret, men er du ikke enig i at ét af argumenterne
> for at bruge fractional er netop at det er så let/billigt at tage dette
> aktive valg at trunkere?

Jeg er ikke helt sikker på, at jeg forstår hvad du mener her...
(Man kommer ikke uden om at trunkere eller afrunde et eller andet sted
efter en multiplikation.)

Men så vidt jeg husker fra studierne er en af de store fordele, at
resultatet af en multiplikation altid er mindre en 1.

I øvrigt er det vel også et spørgsmål om vane, og at det er nemmere at
håndtere værdiområdet -1-1 end -32768-32767 (16 bit)?


--
Med venlig hilsen / Kind regards
Jesper Larsen
Dansk Forening for Rosport: www.roning.dk
Aarhus Studenter Roklub: www.asr.dk

---

> >
> > Ja, det var dårligt formuleret, men er du ikke enig i at ét af
argumenterne
> > for at bruge fractional er netop at det er så let/billigt at tage dette
> > aktive valg at trunkere?
>
> Jeg er ikke helt sikker på, at jeg forstår hvad du mener her...
> (Man kommer ikke uden om at trunkere eller afrunde et eller andet sted
> efter en multiplikation.)
>
> Men så vidt jeg husker fra studierne er en af de store fordele, at
> resultatet af en multiplikation altid er mindre en 1.
>

..... og dermed kan man med en simpel mov instruktion få det tilbage i et
register af samme størrelse (hvis man er tilfreds med at miste præcisionen)

Når et filters s-plans koefficienter (poler/nulpunkter) z tranformeres
(noget med at mappe hele venstre halvplan ind i enhedscirklen, svjh), så
vil disse koefficienter dermed også ligge i dette interval.

tpt