Hallo Leute, wie kann ich vor dem Kauf eines Controllers, den Speicherbedarf für mein Programm abschätzen.Gibt es vielleicht eine Formel zur groben Bedarfsschätzung. Es macht schon einen Preisunterschied, ob ich einen Controller 8k oder 16k kaufe. Vielen Dank im voraus Heiko
Abschätzen: kommt auf Deine Erfahrung an. Du musst halt mal äußern, was der uC alles machen muss. Und ob Du in C oder Asm programmieren willst. Und ob Du Floating-Point brauchst. Und ob Du Text, Bildchen, Tables ... speichern willst. Und ob man solche auch in einen externen Speicher auslagern kann. Und und und.
Je nach Programmiererfahrung und Programmierstil und vor allem je nach Programmplanung kann der Speicherbedarf für die gleiche Aufgabe um bis zu 1:1000 differieren. Manche bekommen etwas nur mit Mühe in einen Mega128, während andere dafür im Tiny15 noch freie Bytes übrig haben. Mit anderen Worten, das muß jeder für sich selber abschätzen. Peter
Also, ich habe ein LCD (110 Segmente)2x HD44780, ich brauche 2 a/d Wandler, ein d/a Wandler,es läuft wohl auf C hinaus (integer), 4 Tasten. Aufs Kb soll es nicht ankommen, eher eine Richtgrösse.
Das ist ja nur die Hardware, dafür brauchst Du überhaupt keinen Speicherplatz, sondern nur einen Lötkolben. Speicherplatz brauchst Du für die Aufgabe, die Du im Chip lösen willst. Peter
Meine persönliche Erfahrung ist, dass wenn man die Wahl zwischen zwei unterschiendlich großen Controllern hat, man besser den größeren verwenden sollte. Auf jedenfall sollte man sich die Möglichkeit offen lassen bei Bedarf einen pinkompatiblen Cotroller mit mehr Speicher in die Schaltung stecken zu können! Für die Routine zum Ansteuern eines HD44780 habe ich ungefähr 500 Byte gebraucht, die Texte die das LCD anzeigen sollte nicht mitgerechnet. Es kann also sein, dass du mit 2KB hin kommst oder du mit nem 16KB Controller Platzprobleme bekommt, je nach Programmierziel und Stiel/Erfahrung.
>Für die Routine zum Ansteuern eines HD44780 habe ich ungefähr 500 Byte >gebraucht, die Texte die das LCD anzeigen sollte nicht mitgerechnet. 500Bytes für LCD Routine ? Mein kompletter Frequenzzähler mit Bereichsumschaltung hat gerade mal 900Bytes, und das obwohl er auf Geschwindigkeit optimiert ist. Wenn ich die Binär->Dezimal Routine als Schleife machen würde (im Moment wird jede Dezimalstelle einzeln berechnet), dann würde ich nochmal einigen sparen. Dann wäre die LCD Routine kaum größer als etwa 200Bytes. Wenn man sowas wie printf verwendet, dann wunder micht das nicht... Danach hatte mein Programm 2kByte und mit Fließkomma waren es 5kByte.
Vielen Dank Leute, das sind doch mal ein paar klare Aussagen mit denen was anfangen kann. MfG. Heiko
"500Bytes für LCD Routine" Ein sehr schönes Beispiel, wie unterschiedlich der Bedarf sein kann. Ich habe 43 Worte (86 Byte) benötigt. Ist allerdings in Assembler (siehe Codesammlung) und LCD über 3 Drähte angeschlossen (mit 74HC164). Peter
hi, ...ob ich einen Controller 8k oder 16k kaufe. es geht also um den flash-speicher, der das programm aufnehmen muss. die grösse muss man nicht abschätzen, programm schreiben, compilieren, vom hex-file die grösse angucken, das muss in's flash. bei bascom guckst du in den report, steht drin 'will fit into rom' - oder halt eben nicht. gruss, harry
Die Differenz von handmade Assembler zu C Compilern kann gewaltig sein. Meine GLCD Library zur Ansteuerung des Nokia Farbdisplays benötigte in C ca. 5.2Kb aber in handmade Assembler, schneller und mit mehr Features nur 1.5Kb. Diese Routinen enthalten dann Ellipsen, Rechtecke, Linien, Clipping, komprimierte Mehrfarben Fonts usw. Gruß Hagen
Also nachdem die Angaben für den benötigten Speicher für die Ansteuerung eines HD44780 doch ziemlich verschieden sind, wollte ich es nochmal genau wissen, und hab mir das Assembler Listing meines Programms angesehen: 222 Byte für das Senden eines Bytes ans LCD +48 Byte für eine nötige Delay Routine +198 Byte für die Initialisierung Die Ansteuerung erfolgt im 4 Bit Modus, leider darf die Routine erstmal eine ganze Reihe von Bits vertauschen, da die Pinbelegung AVR->LCD ausschließlich auf Hinsicht des benötigten Platinen Platzes gewählt wurde. Die Initialisierung lädt zusätzlich noch das Sonderzeichen "ß" als sebstdefiniertes Zeichen ins LCD und zeigt am Ende "Hello" auf dem LCD an. Eine Routine Binär->Dezimal hat mein Prog nicht, inzwischen (6 Monate mehr Erfahrung) wüsste ich aber die eine oder andere Stelle, an der ich optimieren könnte.
222 Byte für das Senden eines Bytes ans LCD ? Ich frag micht echt wie ineffektiv der Code sein kann, bei mir sieht das so aus. Um daraus 222Bytes zu machen, Respekt ! clr RW mov c, Daten RS=c mov P1, a setb En clr En For r0 = #0 nop nop next ret
Salut, @Heiko: Egal, was die Werbung Dir einreden will... Geiz ist nicht geil. ;) Ich hab das jetzt nicht genau rauslesen können. Aber so wie ich das verstehe, fängst Du mit µCs an und fragst deshalb. Ich seh das wie Malte. Lieber einen größeren (u.U. auch physisch - wegen der I/O-Pins) nehmen. Ich selbst mag den Mega16 bzw. seinen pinkompatiblen Bruder Mega32 sehr gern. Der M32 kostet bei http://kessler-elektronik.de gerade mal 5,98 Euro. Wenn Du nicht gerade größere Stückzahlen davon verbauen willst, dann hol Dir so einen oder den Mega16 (den kannst Du bei mehr Bedarf dann problemlos durch einen Mega32 ersetzen). In meinen Augen macht es überhaupt keinen Sinn, im Hobbybereich (evtl. bei Dir ja auch der Fall) bei einstelligen Stückzahlen/Monat auf jeden Cent zu achten und sich ewig Gedanken zu machen, worauf man wegen zu wenig I/O-Pins verzichten muß. Man sollte nicht anfangen, den Code deswegen weniger effizient zu schreiben. Aber es gibt eine gewisse Sicherheit zu wissen, daß man noch viele Features nachrüsten könnte, ohne die Hardware komplett umstellen zu müssen. Das finde ich motivierender als den ständigen Gedanken, daß mich jedes neue Feature näher an die Grenzen des Controllers führt. Und schließlich schont es auch die Nerven wenn man es sich leisten kann, in C statt ASM zu programmieren. :) Vorausgesetzt natürlich die Anwendung ist nicht zu zeitkritisch. Alles in allem, denke ich, ist die DIL40-Klasse für Deine Zwecke schon gerechtfertigt. Ist auch alles nur meine persönliche Meinung. Ich kann die Minimalisten verstehen - ich nehm auch nicht gern mehr als nötig. Ich kann aber auch die verstehen, die wegen der wirklich günstigen Preise gleich eine Klasse höher zugreifen - so ein Controller macht seinen Job ja vielleicht auch nur ein paar Wochen in einem Prototypen - dann kann er für das nächste (vielleicht viel größere) Projekt auch noch herhalten. :) Viele Grüße und viel Spaß, Mark
Hallo Also ich bin der gleichen Meinung wie Mark. Beschäftige mich zwar hauptsächlich mit PICs aber da is es das Selbe. Ich verwende eigentlich nur die 18F Serie, warum sollte ich auch die 16F verwenden. Für 3 weniger tu ich mir das herumschlagen mit paging, wenigen Befehlen und vielem mehr einfach nicht an. In der Entwurfsphase verwende ich eigentlich fast immer DIL40 Chips. Da bleibt dann meist ein Port übrig wo man ein paar Leds anschließen kann die man dann prima zum debuggen verwenden kann wenn man im Code (schreibe nur ASM) ein paar "Markers" einbaut. So kann man feststellen wo der Mikrocontroller hängen bleibt... Dann beim Aufbau verwend ich schon mal 28 oder 18 Pin Gehäuse auch in SMD, einfach weil es deutlich kleiner ist und wenn das Programm schon final ist muss man die Teile eh nicht mehr umprogrammieren ;-) Ach ja 300 Bytes für LCD und ein paar Funktionen ist ok! Ram braucht man max. 10Bytes. MfG Martin
@ mark, Danke erstmal, ich denke das sollte an grober Theorie reichen, jetzt gehts mal zur Umsetzung. Falls es in C nicht klappt, werde ich wohl zu Assembler greifen (ist verdammt lange her). MfG Heiko
@Hagen: Du schreibst, dass du Routinen hast, die Ellipsen usw. auf einen GLCD darstellen. Ich möchte das gleiche mit einem monochromen Display machen. Woher hast du deine Routinen bzw. Informationen darüber? Gruß Ralf
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.