Hallo Jungs, wenn ihr bei einem Projekt X einen µC einsetzen wollt/müsst, wie schätzt ihr die benötigten Flash, Ram und EEPROM Speicher und Taktgeschwindigkeit im vorraus ein? Für mich ist diese Überlegung wie eine Katze im Sack zu kaufen, da das Projekt X ziemlich groß sein kann und dadurch der Code umfangreich wird, oder auch nicht. Umsonst Geld zu zahlen für oversized Speicher und Takt will ja auch niemand. Den EEPROM könnte man noch ungefähr Pi*Daumen errechnen, je nach, welche Daten gespeichert werden sollen. Ram zu kalkulieren könnte ebenfalls machbar sein, wenn man mit dem Ramspeicher behutsam und sparsam umgeht und regelmäßig den Speicher im Ram wieder freigeben kann. Jedoch bei regelmäßiger 32bit Berechnungen der Ram bei kleiner Kapazität sofort eng werden kann. Wie siehts aber mit dem Programmspeicher und Taktgeschwindigkeit aus? Habt ihr da Tipps, Tricks?
Fürs private Basteln in kleinen Stückzahlen? Den größten uC der Serie mit der du dich am besten auskennst. Für einen beruftstätigen Hobbybastler sind die 10€ die der größte uC mehr als der kleinste kostet keine x Stunden an Speicheroptimierungen wert, vom fehlenden Platz für nachträgliche Erweiterungswünsche ganz abgesehen. Für größere Stückzahlen? Einen sicher zu großen uC für den Prototyp, und wenn das Programm steht den kleinsten uC in den es noch reinpassst.
Teddy schrieb: > wie schätzt > ihr die benötigten Flash, Ram und EEPROM Speicher und > Taktgeschwindigkeit im vorraus ein? Ganz Einfach: Die Machbarkeisstudie oder der 0. Prototyp wird auf dem STK des µC Herstellers implementiert - dort ist normalerweise der dickste Prozessor der Serie drauf. Wenn man halbwegs die Funktion (eventuell mit häßlichem Kabelverhau) hinbekommen hat, dann hat man auch eine Idee vieviel RAM und Flash man ungefähr im fertigen Projekt braucht. Oftmals ähneln sich die Demoboards stark, so dass man relativ einfach die Serie wechseln kann wenn sich herausstellt das der µC ein, zwei Nummern zu klein war.
Andreas K. schrieb: > Fürs private Basteln in kleinen Stückzahlen? Den größten uC der > Serie > mit der du dich am besten auskennst. Für einen beruftstätigen > Hobbybastler sind die 10€ die der größte uC mehr als der kleinste kostet > keine x Stunden an Speicheroptimierungen wert, vom fehlenden Platz für > nachträgliche Erweiterungswünsche ganz abgesehen. > > Für größere Stückzahlen? Einen sicher zu großen uC für den Prototyp, und > wenn das Programm steht den kleinsten uC in den es noch reinpassst. Es geht um große Stückzahlen in der Industrie. Der Ansatz ist interessant.
Teddy schrieb: > Wie siehts aber mit dem Programmspeicher und Taktgeschwindigkeit aus? Das kann man eigentlich nur Aufgrund vorheriger eigener Projekte abschätzen, denn jeder Programmierer hat einen anderen Stil, an Aufgaben heranzugehen. So kann der eine Programmierer für die gleiche Aufgabe 100 mal mehr Speicher und CPU-Takt benötigen als der andere.
Peter D. schrieb: > Teddy schrieb: >> Wie siehts aber mit dem Programmspeicher und Taktgeschwindigkeit aus? > > Das kann man eigentlich nur Aufgrund vorheriger eigener Projekte > abschätzen, denn jeder Programmierer hat einen anderen Stil, an Aufgaben > heranzugehen. > So kann der eine Programmierer für die gleiche Aufgabe 100 mal mehr > Speicher und CPU-Takt benötigen als der andere. Naja, die Aussage halte ich doch für etwas gewagt. Erfahrung spielt natürlich eine Rolle, aber diese Grössenordnungen würden bei erfahrenen Profis doch eher bedeuten sowas wie eine Glaskugel bedeuten. Bei so hohen Stückzahlen wie angedeutet zählt jeder Cent, da wird man zusehen, den billigsten verfügbaren Controller mit dem billigsten Peripherieausbau zu kriegen, der den Zweck erfüllt. Das muss nicht der kleinste sein: Um 2000 war der 68332 wesentlich günstiger zu haben als so mancher 8Bitter - weil er in Automotive durch die ETPU Stand der Dinge war und deswegen in so hohen Stückzahlen produziert wurde, dass er sehr günstig zu kriegen war. Die Wahl der Soft- und Middleware spielt natürlich auch eine wichtige Rolle. Das ist reine Mathematik: Footprintdaten der Hersteller studieren, alles zusammen addieren und herausfinden, ob es reicht. RAM- und Flashbedarf - naja, wer unbedingt meint, ohne Linux nicht auszukommen, muss natürlich mindestens 2 MB RAM und mindestens 16MB Flash einplanen, selbst wenn die Aufgabe mit einem RTOS auch mit 2M Flash und 128k RAM zu bewältigen wäre. Aber für Profis ist ein Werkzeug eben genau das - ein Werkzeug, und wenn man mit dem Einen die Schraube nicht in die Wand kriegt, sucht man sich halt das Passende. Ausser natürlich wenn eine von-der-Stange-Hardware mit Android drauf durch eine hohe Marktpentetration so billig zu haben wäre, dass man sie billiger kriegt als eine Custom Minimalhardware.
Adapter schrieb: > Erfahrung spielt > natürlich eine Rolle, aber diese Grössenordnungen würden bei erfahrenen > Profis doch eher bedeuten sowas wie eine Glaskugel bedeuten. Die Glaskugel hat "bei erfahrenen Profis" eine sehr hohe Trefferrate! > Bei so hohen Stückzahlen wie angedeutet zählt jeder Cent, da wird man > zusehen, den billigsten verfügbaren Controller mit dem billigsten > Peripherieausbau zu kriegen, der den Zweck erfüllt. Wenn man einen bestimmten Typ bereits in Menge verbaut und am Lager hat, kann auch eine Regel "Vorzugsbauelemente" greifen, weil die Logistik- und Rüstkosten einen Mehrpreis kompensieren. Hat man mehrere Entwickler, die diesen Vorzugstyp kennen, sowieso. Also: Egal, wie Ihr es dreht, es gibt keine allgemeingültig starre Regel.
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.