Hi, tschuldigung, ich muss euch schon wider mit einer warscheinlich einfachen Frage nerven. Also ich fasse mich kurz. Ich hab hier eine hübsche Funktion geschrieben um mit Fat32 von einer Sd Karte zu lesen. Dabei hab ich mir das so zurecht gelegt, dass ich von jedem beliebigen Byte in der Datei anfangen zu lesen kann. Nun desshalb kann die Variable 'start', natürlich sehr gross werden. (Start gibt das byte an von welchenm gelesen werden soll). Nun habe ich bis anhin uint32_t verwendet; das klappt bis 32768 auch ganz gut. Nur wenn ich daraus nun einen uint64_t mache, dann steigt die Codegrösse von ~4000 bytes auf über 9000 bytes an. Und dies 'bloss', 4 folgenden Rechnungen. Als optimierungslevel beim compilieren verwende ich 's'. Was ich auch nicht ganz begreife - ein uint32_t ist in inttypes ja als unsigned long long definiert. sollte also 32bits lang sein. Wenn der unsigned ist sollte das ja bedeuten 2^32 = 4294957296 Bei mir gibts allerdings schon ab 32768 Rechnungsfehler. (multiplikationen verwende ich allerdings nirgends). Nik
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.