Vervierfachung der Latenzzeit bei Multiplikation

Danke für die Antwort...

>Tja, schon mal überlegt wie lange so eine Multiplikation, und erst recht
>ein DIVISON dauert?

Ist mir völlig egal wie lang das dauert. Die Frequenz benötige ich nach 
der Berechnung und der Interrupt geht vor. Der PIC18F ist auch sehr 
schnell mit Multiplikationen. Das ist nicht das Problem.

>>??? :-)
Betreibe den PIC mit den internen 8Mhz mitt eingeschaltenem PILL = 
32MHz. Der  Systemtakt beträgt dann 8MHz.
Allein das schreiben eines / oder * Zeichens irgendwo im Programm (auch 
wenn es nicht ausgeführt wird) verursacht eine miese Latenzzeit bei den 
Interrupts. Der Zähler rennt aber normal mit 8Mhz.
Keine Ahnung wiso. Ich weiss nur dass dann die Routinen für "/* float" 
in mein Programm geschrieben werden. (Bin mit C18 noch nicht allzu 
versiert).
Wird irgend eine Einstellung verändert?

>>Glaub ich nicht.
Der Compiler erzeugt einen CALL zu einer solchen Subrutine. Leider.

Mfg MICHI

Wer benutzt float in einem uC ohne FPU? Dann ist klar dass man absolut 
verloren hat.

Ich :D

na ja alle 5 s kann man ja mal eine machen... solangs ned ständig ist :)

> Wer benutzt float in einem uC ohne FPU? Dann ist klar dass man
> absolut verloren hat.

Soll das ein Trollbeitrag sein?

klingt so.
Normalerweise arbeite ich mehr mit Int, aber manchmal ist es einfach 
sinnvoller (oder sogar unumgänglich) float zu nehmen. Ernstzunehmende 
Performance-Einbrüche habe ich keine erlebt :-)
Und wenn das Teilchen durch float-Operationen in die Knie gezwungen, 
wurde einfach der falsche Prozessor gewählt. Üblicherweise wird doch ne 
ganze Menge Zeit gewartet.

Super Antworten, danke...

@Ralf
Die Punkte 2 und 3 sind interessant. Ich werde mich eimal darauf 
stürzen. Mal schauen. Im schlimmsten Fall muss ich halt wirklich mit INT 
rechnen und für */ Loopings verwenden.
Das Interrupthandling ist wirklich mühsam :-).

Klar, der PIC ist nicht besonders geeignet für meine Anwendung. Aber 
Preis und Umgebung sind super.

Die Leistung müsste ausreichen. Der Hund liegt im Detail.
Eine FPU währe wohl etwas übertrieben. :-) Ich will ja kein CAS bauen.

MfG MICHI

Yes!! War ich ein Vollidiot :-).

Habe folgenden Befehl im Interrupt verwenden um den Compare neu zu laden 
und die Flanke zu toggeln.

//OpenCompare2(compop^=1,comp+=i);

Habe leider übersehen dass der Assembler ein CALL zu einer GIGA-Funktion 
schreibt.

Händisch
comp+=i;
CCPR2L = comp;
CCPR2H = (comp >> 8);
CCP2CON = compop^=1;

Wieso nicht von Anfang an so?? Funktioniert super!

MfG MICHI

@Dieter Werner: Wieso soll das ein Trollbeitrag gewesen sein? Float auf 
ner 8 Bit uC ohne FPU ist nunmal absolute Resourcenverschwendung, das 
weiß jedes Kind. Klar, wenn man eh davon genug hat spielt das vielleicht 
keine Rolle, aber dann braucht man sich nicht wundern wenn man immer 
dickere Hardware braucht. In den meisten Fällen reicht nunmal 
Festkommaarithmetik.

Eine FPU vorzuschlagen wenn alle 5 Sekunden mal eine Rechenoperation 
durchgeführt werden soll ist doch noch viel größere 
Ressourcenverschwendung. Und es gibt halt Situationen wo es float sein 
muss und fixed-point nicht ausreicht.

z.B. wenn der Wertebereich 2^32 (long) nicht reicht? Gibts immer wieder 
mal, dass "grosse" oder "kleine" zahlen auftauchen...

@Dieter Werner und Mroin: Deswegen schlage ich ja fixed point vor, nicht 
eine uC mit FPU.