Hallo, schon ein bisschen gelesen, aber ganz schlau bin noch nicht daraus geworden. Ich frage mich, wie sich die spätere Codegröße (die beim AVR z.B. in den Flash geschrieben wird) im vorhinein abschätzen (oder evtl. sogar "berechnen") lassen lässt. Dafür bräuchte man (wenn man in C programmiert) ja z.B. Kenntnisse über den Compiler, Optimierung, ... Gibt es da bestimmte Techniken, Verfahren? Grüße Joe
Das Assemblieren bzw. Kompilieren des in assembler oder in C geschriebenen Programms liefert in dem entstehenden .hex-file gleich die Information über den benutzten Speicherbereich. Nix abschätzen, fertige hex-Zahlen sind da. Bei asm. ist die Sache recht einfach. Da je Befehl ein oder zwei Speicherplätze beansprucht werden, ist ein Abschätzen schon im .asm-file möglich. Bei Hochsprachen, bei denen jede Menge an Funktionen aus Bibliotheken mit eingebunden werden, kann ein Vielfaches an Speicherbereich besetzt werden im Vergleich zu Assembler. Da muss man halt compilieren und das .hex-file ansehen. Ich selbst habe mal ein einfaches Assemblerprogramm mit ca.50 Befehlen für einen Arduino (also in C) umgeschrieben. Dessen Programm hat gleich 2,8kByte belegt.
:
Bearbeitet durch User
Ja, das man die Codegröße mit der .hex Datei dann konkret weiß, ist mir klar. Mir geht es eher darum, man weiß, das und das muss der Controller machen (auch weiß man schon wie es in etwa umgesetzt werden soll) und wieviele Anschlüsse Timer ... man benötigt. Daraus ungefähr die Codegröße abschätzen. Ist das nur Erfahrung? Weil wenn man zwar hardwaremäßig alles hat bei dem ausgesuchten Controller, am Ende aber das Programm nicht drauf passt, wäre ja schon sehr doof. Ich kann mir nicht vorstellen, dass das Programm geschrieben wird, und dann geschaut wird, ob es auf den gewählten µC passt. Das kommt mir so ein bisschen Huhn und Ei mäßig vor.
Hi >Ich frage mich, wie sich die spätere Codegröße (die beim AVR z.B. in den >Flash geschrieben wird) im vorhinein abschätzen (oder evtl. sogar >"berechnen") lassen lässt. >Ich kann mir nicht vorstellen, dass das Programm geschrieben wird, und >dann geschaut wird, ob es auf den gewählten µC passt. >Das kommt mir so ein bisschen Huhn und Ei mäßig vor. Bei AVRs gibt es bei allen neueren Typen Reihen die bei gleicher IO-Austattung unterschiedliche Flash-Größen haben. Einfach die Entwicklung auf dem Größten machen und für das 'Endprodukt' den nehmen, in den das Programm passt. Aber nur wenn der kleinere preislich wirklich günstiger ist. MfG Spess
Hallo Nein, bevor man den Code geschrieben hat kann man nicht genau sagen wie groß der wird. Das ist meist aber auch nicht nötig. Man kann: * Anhand der sonstigen Anforderungen an die Performance, Hardware und der eigenen Präferenzen die Chipfamilie eingrenzen (ARM, PIC, AVR, 8051, whatever). * Anhand der Problemstellung i.d.r. die Elemente ermitteln die am meisten Flash/RAM fressen werden. z.B. Strings, Lookup Tables, Grafiken, Puffer, etc. Externe libs haben oft Angaben über den benötigten Speicher mit dabei, sonst den Autor fragen. * Bei Prototypen/Einzelstücken einfach großzügig auf die Schätzung Reserve drauf planen. Der Prieisunterschied ist meist gering. * Im Hobby Bereicht kauft man sinvollerweise mehere Chips eines Typs als "All-in-One" Lösung um nicht für jedes zukünftige Projekte was neues bestellen zu müssen. * Funktioniert der Prototyp kann man immer noch einen kleineren/billigeren Chip in der Produktion verwenden. Etwas Reserve ist aber auch hier gut. Für spätere Updates. * Anfangen mit was man gerade da hat Breadboard/Dev-Kits/PC und gucken was man wirklich braucht/was fehlt. da1l6
Im Endeffekt ist die Abschätzung zu Projektbeginn nur auf Erfahrung basierend. Klar hat man schon Code aus dem vorherigen Projekt den man zumindest teilweise wiederverwenden kann lassen sich daraus schon mal Zahlen ableiten. Ansonsten ist zu dem Zeitpunkt noch nichts belastbares vorhanden. Als grobe Richtschnur für eine solche Abschätzung. 1. identifizieren ob Tabellen drin sind, , die lassen sich recht gut abschätzen. 2. Float nötig ? Wenn ja plus ~ 3 - 6 kByte ( je nach µC) für die Float librarys 3. Programcode, tja reine Erfahrungssache wenn nichts wiederverwertbares aus vorherigen Projekten vorhanden ist. 4. Aus 1 - 3 Zahlen abschätzen- 5. Diese Abschätzung ist immer zu niedrig. also erhöhen. a. Viel aus vorherigen Projekten übertragbar : + 20 % b. Wenig aus vorherigen Projekten übertragbar : + 50 % c. Nichts aus vorherigen Projekten übertragbar : +100 % d. Gar keine Erfahrungsbasis : Kauf den größten µC aus der ausgesuchten µC Familie und hoffe das der reicht.
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.