16 bit Div durch 100 bei AVR Mega32

Wenn es Teil der Wandlung 16Bit -> ASCII sein soll, dann findest Du 
Beispiele in der Cidesammlung und auch im restlichen Forum. Einfach mal 
nach "LCD" suchen, da diese Aufgabe meist in Verbindung mit LCDs zu 
lösen ist.

MfG, Blaubär

Mal 655 dann die leztzten 16Bit nehmen ist zwar nicht 100% exakt aber je 
nach Einsatzgebiet recht das dicke X*655/65536 = X/100.055. Besser wäre 
mit 41943 Multiplitzieren (2^22) wäre dann X/100.0001 braucht aber auch 
entsprechen 38bit. -wiebel

Wolfram Quehl wrote:

> Ich hatte da was mit über 600 Takte gesehen, aber das ist mir zu
> viel. Das soll kein Selbstzweck sein, sondern ist Teil einer
> Ergebnisumwandlung.

Was meinst Du damit, etwa für eine Anzeige ?

Dann sind 600 Zyklen bei weitem schnell genug, kein Mensch kann so 
schnell ablesen.

Im Gegenteil, Du mußt extra noch ~200ms (4.000.000 Zyklen) Delay 
einfügen, damit die Zahlen nicht flimmern.

Max 2..5 Anzeigewerte pro Sekunde sind ergonomisch.


Peter

Nailpainter wrote:
> Das steht aber nicht im Zusangehang mit einer Mittelung ? Div 128 ist
> viel oekonomischer.

Ich finde schon, daß man jemand darauf hinweisen sollte, wenn er 
Probleme sieht, die gar keine sind.

Gerade Anfängern fällt es schwer, die benötigten CPU-Zeiten richtig 
einzuschätzen.


Peter

das Meßergebnis muß linearisiert werden und da steht in der Formel durch 
100. Da kann ich nicht durch 128 teilen. Der Fehler erscheint mir dann 
zu groß. Aber der Ansatz von Wiebel erscheint mir gut. Ich habe ja auch 
geschrieben Teilaufgabe, daher wird das Ergebnis nicht angezeigt. Ich 
neige zwar dazu, die optimale Geschwindigkeit zu programmieren, weil ich 
vorher noch nicht weiß, wie das Ergebnis aussehen wird. Langsamer wird 
alles von alleine. Das sieht man ja an Windows. Das hat auch nichts mit 
LCD zu tun.
Nur eine kleine Abweichung könnte ich zulassen.

mfg

Wolfram wrote:

> Es steht dir natürlich auch
> frei jeden anderen Teiler mit 2^n zu nehmen.

Genau, mein Favorit wäre 256, das spart Shifterei.

MfG, Blaubär

@ Troll Blaubär (blaubeer)

>> Es steht dir natürlich auch
>> frei jeden anderen Teiler mit 2^n zu nehmen.

>Genau, mein Favorit wäre 256, das spart Shifterei.

Ist alles ne Frage der Genauigkeit.

1/100 = 2,56/256 = 655,36/65536 = 167772,16/16777216 = 42949672,96 / 
4294967296

Wenn man nun auf ganze Zahlen rundet

1/100 = 3/256 = 655/65536 = 167772/16777216 = 42949673 / 4294967296

ergibt das ein Fehler von

0%     -14,6%    -0,054%      -0,0000953%       0,0000000931%

Na, immer noch ein Fan von 256?

MfG
Falk

> Genau, mein Favorit wäre 256, das spart Shifterei.

Nachtrag: Oder eine Potenz davon (2^8, 2^16, 2^24, 2^32), je nachdem, 
was für den Einzelfall sinnvoll ist. Aber möglichst so, dass hinterher 
keine (oder möglichst wenig) Bitscheberei erforderlich ist.

Falk Brunner wrote:
> Na, immer noch ein Fan von 256?

Ja sicher doch, immer noch ein Fan von ganzen Bytes. Wenn die ersten 256 
nicht reichen, dann werden eben die nächsten hinzugefügt. Vielleicht 
solltest Du einen eingebrachten Gedanken mal zu Ende denken ehe Du 
darüber herfällst. ;-)

Die von mir genannten 256 sollten nur die zuvor genannte 128 in Frage 
stellen und zum Weiterdenken animieren.

MfG, Blaubär

@Wiebel und Falk Brunner

Danke, diese Ideen sind noch die Besten.
Bei 16 bit wie im Betreff angegeben werde ich aber keine höhere 
Genauigkeit erreichen, wenn ich die 24 bit oder 32 bit Multiplikation 
verwende. Max. kommen immer 655 raus. Auch wenn ich die 4 mille 
verwende. Darum hat die 4 mille keine bessere Genauigkeit als die 65536 
Version.
Aber für andere Zwecke oder Aufgaben kann das sicher sinnvoll sein, das 
dann ggf. auch mal zu betrachten.

mfg

Diese Lösung hat +0.097% Fehler, kommt aber ohne Multiplikation aus:

1/100 ~ (1+1/4+1/32)/128, also q=(x+(x>>2)+(x>>5))>>7;

Cheers
Detlef

Detlef _a wrote:
> Diese Lösung hat +0.097% Fehler, kommt aber ohne Multiplikation aus:
>
> 1/100 ~ (1+1/4+1/32)/128, also q=(x+(x>>2)+(x>>5))>>7;
>
> Cheers
> Detlef

Der Mega32, mit dem das realisiert werden soll, hat 
Hardware-Multiplikation, kann also innerhalb 2 Takte zwei Bytes 
multiplizieren. Beim Shiften fehlt im aber die Leistung, da er in einem 
Takt nur um 1 Bit innerhalb eines Bytes shiften/rotieren kann, mehr gibt 
seine Architektur nicht her. Deshalb ist Deine Lösung, die auf anderen 
Controllern (die mit einem Befehl über mehrere Stellen shiften/rotieren 
können) höchst effizient sein mag, beim Mega32 vermutlich etwas 
aufwendiger als die Hardware-Multiplikation.

MfG, Blaubär

>> kann also innerhalb 2 Takte zwei Bytes multiplizieren.

ja genau, Bytes. Wolfram will 16Bit verarbeiten und die '655' paßt auch 
nicht in ein Byte, dadurch wird der m.E. der Aufwand bei Multiplikation 
sehr viel höher. Machen wir uns nix vor, die Megas können schlecht 
multiplizieren UND schlecht schieben.

Cheers
Detlef

@ Detlef _a (detlef_a)

>> kann also innerhalb 2 Takte zwei Bytes multiplizieren.

>ja genau, Bytes. Wolfram will 16Bit verarbeiten und die '655' paßt auch
>nicht in ein Byte, dadurch wird der m.E. der Aufwand bei Multiplikation
>sehr viel höher. Machen wir uns nix vor, die Megas können schlecht
>multiplizieren UND schlecht schieben.

???

eine 16x16 Bit Multiplikation besteht aus maximal 4 8x8 Bit 
Multiplikationen, der GCC schafft es irgendwie mit 3. Das Schieben 
dürfte deutlich länger dauern.

<C>
#include <avr/io.h>

int main (void) {
  uint16_t a,b;
  uint32_t c;

  c = a*b;

  return 0;
}
</C>

<AVRASM>
  c = a*b;
  96:  29 81         ldd  r18, Y+1  ; 0x01
  98:  3a 81         ldd  r19, Y+2  ; 0x02
  9a:  8b 81         ldd  r24, Y+3  ; 0x03
  9c:  9c 81         ldd  r25, Y+4  ; 0x04
  9e:  28 9f         mul  r18, r24
  a0:  a0 01         movw  r20, r0
  a2:  29 9f         mul  r18, r25
  a4:  50 0d         add  r21, r0
  a6:  38 9f         mul  r19, r24
  a8:  50 0d         add  r21, r0
  aa:  11 24         eor  r1, r1
  ac:  ca 01         movw  r24, r20
  ae:  aa 27         eor  r26, r26
  b0:  bb 27         eor  r27, r27
  b2:  8d 83         std  Y+5, r24  ; 0x05
  b4:  9e 83         std  Y+6, r25  ; 0x06
  b6:  af 83         std  Y+7, r26  ; 0x07
  b8:  b8 87         std  Y+8, r27  ; 0x08

</AVRASM>

MFg
Falk

Überzeugt, Multiplikation.

Dann aber die 16Bit Multiplikation richtig ausnutzen:

1/100 ~ 10486/(2^20) also q=(10486*x)>>20;

macht +0.0023% Fehler.

Das ist mit int16 Multiplikationen das Optimum. Der shift um 20 läßt 
sich umgehen mit Zuweisungen und dem 'swap' Befehl der Megas.

Schieben/aaddieren ist das Verfahren der Wahl bei FPGAs: addieren ist 
billig und schieben kost nix.

Cheers
Detlef

@ Detlef _a (detlef_a)

>Überzeugt, Multiplikation.

Uups, das klappt ja nicht. Es fehlt der Cast auf 32 Bit, die Rechnung 
macht nur 16x16 und einen schönen Überlauf! Mit Cast ist die 
Schiebevariante wieder schneller, denn die 32x32 Bit Multiplikation 
braucht 10 MUL.

>Schieben/aaddieren ist das Verfahren der Wahl bei FPGAs: addieren ist
>billig und schieben kost nix.

Yep.

MfG
Falk

Es soll aber in Assembler gearbeitet werden.

MfG, BlauBär

Na, wenns denn mit der Multiplikation doch nich geht, hier nochmal ne 
Variante 0.0023% mit nur schieben:

1/100 ~ (1+1/2+1/16-1/512-1/2048)/256

q=x+x+(x>>1); // 1 mal schieben
x>>=4       ; // 1mal swap
q+=x        ;
x>>=1       ; // 1mal schieben
x>>=4       ; // 1mal swap
q-=x        ;
x>>=2       ; // 2 mal schieben
q-=x        ;
q>>=8       ;

Cheers
Detlef

Detlef _a wrote:
> 1/100 ~ (1+1/2+1/16-1/512-1/2048)/256

Ähm, so:

 1/100 ~ (2+1/2+1/16-1/512-1/2048)/256


Cheers
Detlef

Dir ist aber schon bewusst, dass beim AVR SWAP nicht um 4 Stellen 
schiebt, sondern oberes und unteres Nibble vertauscht, oder?

MfG, Blaubär

ja.

So:
//0xabcd
highbyte=swap(Highbyte); //0xbacd
lowbyte =swap(lowbyte) ; //0xbadc
lowbyte =(lowbyte&0xf)|(highbyte&0xf0);//0xbabc
highbyte=highbyte&0xf;//0x0abc

Vielleicht auch nicht viel kürzer als 2*4 shifts durch das carry. Mit 
nem scharfen Blick auf den Befehlssatz des AVR sollte sich 
möglicherweise noch was besseres finden lassen, der Tausch der Bytes z.B 
mit XOR oder so. Den Megas fehlt der Barrelshifter.

Cheers
Detlef

@lippy:

x >>=2 ist die Kurzform von x= x >> 2, das schiebt die Bits von x 2 
Stellen nach rechts, teilt den Wert also durch 4.

Cheers
Detlef