Hallo Stefan,

ich habe mich jetzt versucht mal schlau zu machen. Habe aber noch nicht alles verstanden.

Zitat Zitat von sternst Beitrag anzeigen
Ne, ist nicht klar, und auch falsch. Der Teil in der Klammer wird in int gerechnet (und da passiert auch gleich der Überlauf). Das (bereits falsche) Zwischenergebnis wird dann nach long promotet, und der Rest in long weiter gerechnet (außer natürlich dein F_CPU ist ungewöhnlich klein).
Nach Deinen Hinweis ist die Sache zumindest einigermaßen klar, habe einen Fehler in den Berechnungen per Taschenrechner gemacht. (2 * 1024 * 5) wird vom Compiler als uint_16 berechnet, da die längste Zahl in diesem Ausdruck uint_16 ist. Das Ergebniss dieser Multiplikation sprengt aber uint_16. Anstelle des richtigen Ergebniss 102.400 wird mit 36.864 weitergerechnet. Die dann folgende Division F_CPU / 36.864 ist dann natürlich auch fehlerhaft. In meinem Fall ergibt sich dann 7372800 / 36.864, also 200. -1 dann, also 199. Stelle ich mir das so richtig vor? Bin mir nicht sicher, weil ich mit meiner nicht funktionieren Formel ca. 14hz gemessen habe, bei 199 müsste sich aber 18hz messen lassen. Kann aber auch an meinem Messgerät liegen. Im unteren Frequenzberich sind die Abweichungen manchmal größer.


Zitat Zitat von sternst Beitrag anzeigen
Und auch in deinem Fall hier würde ein UL (oder auch nur L) hinter einer der Zahlen in der Klammer weiterhelfen. Dadurch, dass du einen der Operanden in einen größeren Typ zwingst, erzwingst du, dass die Rechnung in der Klammer insgesamt in einem größeren Typ stattfindet.
Okay. L zwingt man einer Zahl einen Datentyp auf. Mit L eine uint_32, mit UL eine uint_64? Richtig so? Weil ich leider nicht viel darüber gefunden habe. Ist das so wie eine CAST-Operator zu verstehen? Welche anderen Typkennzeichen gibt es denn noch? Oder hättest Du einen Tip, wo ich mich da schlau machen könnte?

Code:
    #define        ocr_Wert        ((F_CPU / (1024 * 2 * 50L)) - 1)
Was aber am wichtigsten ist, der Code funktioniert jetzt!

Vielen Dank für Deine Tips.

mfg

Uwe