STM32 - CodeBench Lite - 64-bit Division

>  Was passiert da? Schließlich ist die Baudrate unabhängig vom erzeugten
> Code und lediglich ein Wert in einem CPU-Register.

Die meisten Cortex_M3 Libs die ich kenne erzeugen den Wert für die 
Baudrate dynamisch aus der aktuellen CPU Frequenz. Und weil da relevante 
Nachkommastellen auftreten könnnen wird mit 64 Bits gerechnet.

Abhilfe: Bei bekanntem CPU Takt die entsprechenden Werte von Hand - oder 
vom Compiler - ausrechnen (lassen) und in die Register eintragen.

Es könnte sein dass die Funtion nicht reentrant ist - dann darf man 
diese Berechnung der Baudrate nicht im Interrupt ausführen.

Ja, 64bit-Division ist augenscheinlich in strtoll. Quellcodeteil der 
newlib sieht aber wenig dramatisch aus: 
http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/strtoll_r.c?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=src 
. Unter bestimmten Bedingungen wird jedoch ein Fehlercode gesetzt, dabei 
wird in einen Struktur vorm Type __reent geschrieben. Beim Aufruf der 
"normalen" Funktion (nicht der _r-Variante) wird dann in 
impure_data.errno geschrieben. _impure_ptr zeigt auf diese globale 
Stuktur impure_data. Man kann also evtl. hier per Debugger nachverfolgen 
- erscheint aber wenig erfolgversprechend.

Problem könnte auch im Zusammenhang mit der Fehlerüberprüfung einer 
Divisiononsroutine in der libgcc liegen. Gibt es im Linkerscript 
Einträge für ARM.extab und ARM.exidx? Einige Versionen der libgcc haben 
Abhängigkeiten zur C++-Ausnahmeverarbeitung mitgezogen, selbst wenn man 
"reines" C nutzt. Im Zweifel und falls nicht schon drin, die die beiden 
Sections in das Linkerscript eintragen (siehe Beispiele in CS 
Installationsverzeichnis) und anhand des Map-Files prüfen, ob dort etwas 
von libgcc (und/oder libc) abgelegt wird (siehe vor allem nach 
libgcc/_udivdi3 und libgcc/_divdi3 jeweils einträge in extab und exidx, 
in exidx zusätzlich noch für libgcc/bpabi).

Jim Meba schrieb:
> Die meisten Cortex_M3 Libs die ich kenne erzeugen den Wert für die
> Baudrate dynamisch aus der aktuellen CPU Frequenz. Und weil da relevante
> Nachkommastellen auftreten könnnen wird mit 64 Bits gerechnet.

Sieht bei mir eher schlicht aus, STM32F1xx:
    unsigned apbclk = (info->dev == USART1) ? F_APB2 : F_APB1;
    info->dev->BRR = apbclk / baud;
Die 4 Nachkommstellen stehen im Baudratenregister. Ok, man könnte hier 
noch ein halbes Bit runden, aber ob das so wichtig ist? Weshalb man da 
64 Bits braucht erschliesst sich mir nicht.