uint64_t verwendet und gleich wird 5kb mehr Ram gebraucht

Wenn du konstanten im Code eingibst, solltest du auf jeden Fall immer
die richtigen Postfixe verwenden, sprich z.b. "a = 40000ULL", wenn
die Zahl als unsigned long long gerechet werden soll.

Je nach Rechenoperation kann eine 64bit Rechnung extrem viel mehr Platz
brauchen als eine 32bit Rechnung. Du arbeitest ja schließlich immerhin
mit einem 8bit Kern.

Poste mal deinen Code, manchmal lässt sich bei den Rechnungen was von
Hand optimieren, so dass es schneller zu rechnen geht.

oh sch***** im Titel sollte es natürlich heissen 5kb mehr Flash, nicht
Ram.

Das mit den Postfixen werd ich gleich mal versuchen, ich hab nämlich
eine Konstante, wenn das noch nicht hin haut poste ich mal den Code :)

So ich hab die funktion + Aufruf mal angehängt.

Es könnte auch an meiner Art liegen, wie ich die Zahl berechne(oberster
abschnitt in fread)

Ich müsste irgendwie das abgerundete Ergebniss von start/512 kriegen,
wenn möglich mit einem shift oder so was in der Art? Irgendwie muss es
doch effektiver gehen und ohne dass endlose Zahlen entstehen.

Du solltest dieses "start/512" nur einmal am Anfang der Funktion
berechnen. Außerdem spart "start >> 9" im vergleich zu "start/512"
Speicherplatz, habs grad mal getestet.

Das mit dem long long ist mir auch schonmal aufgefallen.
5kByte für eine einfache long long Division ist schon extrem.
In Assembler ist da kein unterschied: Man muss nur den Schleifenzähler
anpassen, so dass er 64 statt 32bits verarbeitet.
Da es bei mir nicht auf absolute Genauigkeit ankam, habe ich float
verwendet.

Eigentlich sollte zwischen start>>9 und start/512 kein Unterschied
sein, wenn es unsigned ist: Der Compiler macht aus beiden shifts.
Wenn es signed ist, dann gilt start>>9 != start/512 !
Aus diesem Grund ist es eigentlich immer sichere, wenn man teilt.

Welche Werte hat denn sectors_per_cluster so? Wenn es sich nämlich um
2er Potenzen handelt (4, 8, 16...) würde ich es nämlich auch so
speichern.

Zum einen kommt man dann evtl. mit einer kleineren Variablen aus, zum
anderen kann man die teuren Divisionen durch billige Shifts ersetzen.

wie Du schon oben bemerkt hast kann mit mit 32 Bit sehr viel mehr als
32768 speichern/rechnen.
Ich denke der Fehler liegt woanders, ich würde in so einem Fall
versuchen den Code zu debuggen und dabei die Berechnungen
kontrollieren.

Grüße
Walter