Hallo, mein Attiny44 ist nach dem kompilieren zu 100% voll. Kann das Probleme geben oder ist das noch ok? Danke.
Angehängte Dateien:
-
prozessor.jpg
14 KB
Erst wenn noch 3 Bytes hinzukommen wird das zum Problem. Beispielsweise mit der nächsten Compilerversion.
Beim Flash ist das kein Problem. Nur der Ram darf nicht allzu voll werden. Das einzige Problem könnte sein, dass das Programm evtl. später bei einer neuen Compilerversion 3 Bytes mehr hat, und dann nicht mehr rein passt.
Optimiert ist auf die kleine Codegröße, aber danke für den Tipp. Bin sowieso am Überlegen, ob ich auf Mega8 umsteige. Der Preis ist ja ähnlich bis gleich, aber 4kb mehr Speicher. Nur halt etwas größer. Die Pins des Tiny44 würden mir reichen, aber mal sehen. Danke für die Auskunft.
Siegfried schrieb:
> Bin sowieso am Überlegen, ob ich auf Mega8 umsteige.
Warum ausgerechnet auf so einen Großvater?
Jörg Wunsch schrieb:
> Warum ausgerechnet auf so einen Großvater?
Weil er günstig ist, 8kb Speicher hat und sonst dem Attiny44 nicht
nachsteht oder? Bzw. warum meinst du, dass dieser "ungeeignet" ist?
Der Attiny84 wäre wiederrum teurer...
Siegfried schrieb:
> Bzw. warum meinst du, dass dieser "ungeeignet" ist?
Hängt davon ab, was du damit machen willst, aber Stromverbrauch,
einer statt mehrere (und dazu ungenauere) RC-Oszillatoren, debugWIRE,
bestimmt könnten einem noch weitere Dinge hier einfallen, warum
heutzutage ein ATmega8 nicht mehr meine erste Wahl wäre.
Mensch Leute, es geht hier um eine kleines HOBBYPROJEKT, nicht das Design 3000! Die leistung der meisten Projekte werden durch die Fähigkeiten der Hobbybastler begrenzt, nicht die ICs. Gilt auch für den Mega8. MFG Falk
Falk Brunner schrieb:
> Mensch Leute, es geht hier um eine kleines HOBBYPROJEKT,
Aus diesem Grunde habe ich auch den kompatiblen 84er empfohlen. Damit
muss man sich fast keine zusätzlichen Gedanken machen. Der 84er kann
komplett den 44er ersetzen. Eine bereits gebaute Schaltung muss nicht
verändert werden.
Ich sehe da kein Problem, einmalig einen Euro mehr auszugeben.
Siegfried schrieb:
> Optimiert ist auf die kleine Codegröße, aber danke für den Tipp.
Die Optimierung ist schlechter, als man denkt - die Codegroesse aendert
sich manchmal schon, wenn man if-else-Statements umkehrt oder
Code-Bloecke verschiebt. Nur, falls mal der Platz nicht mehr reicht und
kein groesserer Controller zur Hand ist - ein wenig Experimentieren
lohnt sich.
Peter Stegemann schrieb: > Die Optimierung ist schlechter, als man denkt - Nö, nur die default Einstellungen sind schlecht. Man sollte beim AVR-GCC folgende Schalter noch hinzufügen:
1 | -Os |
2 | -lm |
3 | -fno-inline-small-functions |
4 | -Wl,--relax |
5 | --combine -fwhole-program |
> die Codegroesse aendert > sich manchmal schon, wenn man if-else-Statements umkehrt oder > Code-Bloecke verschiebt. Das bringt in der Regel nur wenige Bytes. Der Compiler ist da recht eigensinnig. Peter
Da gibt es doch nur eine Loesung. Programm komplett neu strukturieren und aus eigenen Fehlern lernen. Das Prog. MUSS da rein ! Keine Ausrede ! Stramm stehen ! PotzBlitz !
Du kannst der .s Datei (gcc -S) anschauen und sehen welche funktionen lang sind und versuchen die kleiner zu machen. Manchmals es lohnt neue algoritmen zu finden usw. Wenn zu kompliziert ist, nimm einfach ein Tiny84...
hakuspakus schrieb:
> Da gibt es doch nur eine Loesung.
Falsch, Assembler wäre die 2. Lösung :-)
hakuspakus schrieb:
> Programm komplett neu strukturieren
Das bringt in der Tat oft sehr viel, würde mich nicht wundern, wenns
danach in nen ATtiny24 paßt.
Aber erstmal die Änderungen im Makefile probieren, das geht deutlich
schneller.
Peter
Peter Dannegger schrieb: > Peter Stegemann schrieb: >> Die Optimierung ist schlechter, als man denkt - > Nö, nur die default Einstellungen sind schlecht. > Man sollte beim AVR-GCC folgende Schalter noch hinzufügen: >
1 | > -Os |
2 | > -lm |
3 | > -fno-inline-small-functions |
4 | > -Wl,--relax |
5 | > --combine -fwhole-program |
6 | >
|
Nun, das macht man natuerlich zuerst. >> die Codegroesse aendert >> sich manchmal schon, wenn man if-else-Statements umkehrt oder >> Code-Bloecke verschiebt. > Das bringt in der Regel nur wenige Bytes. Der Compiler ist da recht > eigensinnig. Meine Praxiserfahrung ist gegenteilig. Aus 10 Byte hier und 10 da werden schnell 100-200, das ist schon was, wenn man den Code in einen ATTiny13 quetschen will.
Jörg Wunsch schrieb: > Hängt davon ab, was du damit machen willst, aber Stromverbrauch, > einer statt mehrere (und dazu ungenauere) RC-Oszillatoren, debugWIRE, > bestimmt könnten einem noch weitere Dinge hier einfallen, warum > heutzutage ein ATmega8 nicht mehr meine erste Wahl wäre. > > Das Programm soll in eine Kleinserie für KFZ Anwendung finden. In einem KFZ Forum sind ein paar Interessenten, die teilweise auch mitentwickelt haben, die das dann in ihr Auto bauen. Daher spielt der Preis in gewisser Maßen eine Rolle, Stückzahl ist 50 geplant. Verdient wird nichts, aber uns war es zu teuer, ein "fertiges" Produkt auf dem Markt zu kaufen. Welche Features brauche ich: - interner Oszillator 8Mhz (andere Taktfrequenz würde die ganzen Zeitroutinen im Programm ändern), externer Quarz nicht nötig (so genau muss es nicht sein) - 2 Timer, mind. einer 16-bit mit Input Capture, Compare Match, einer 8-bit mit Compare Match Funktion - ADC Wandler mit mind. 2 ADC-Eingängen - externes Interrupt (hat wohl jeder) - Beim Attiny44 habe ich alle 11 I/O Pins (Reset habe ich nicht angerührt und als I/O Pin gefust) gebraucht, also wäre das noch eine min. Anforderung "mehr" brauche ich nicht. Also eine recht simple Anforderung. DebugWIRE brauche ich nicht (habe ich mich auch noch nicht damit beschäftigt, ehrlich geseagt). Stromverbrauch ist nebensächlich, da über KFZ Boardspannung und die Schaltung nur 2 LED's treibt und den µC selbst, sonst keine Stromfresser (Rest extern über Optokoppler). Die Hardware steht momentan nur auf Lochraster, wäre also kein großes Problem, den µC zu tauschen (bis 2-3h arbeit das Programm anzupassen). Daher bin ich für Vorschläge bei der µC Wahl offen. Ich habe das Programm eigentlich Schritt für Schritt entwickelt. Ich habe immer zunächst sie einzelnen "Programmteile" entwickelt, dann verbessert und zum Schluss in das komplette Programm integriert. Ich mag nicht behaupten, dass es 100% optimal ist (sicherlich ist es das auch bei weitem nicht), aber ich habe mich stets bemüht, kurze und codesparende Algorithmen zu verwenden. Ein Profi kann das sicherlich noch viel optimieren, aber ich als Hobbyanwender stoße da recht schnell an MEINE Grenzen. Peter Dannegger schrieb: > -Os > -lm > -fno-inline-small-functions > -Wl,--relax > --combine -fwhole-program Das ist interessant. Wo kann man das Einstellen? Ich habe bis dato immer nur im Makefile Editor oben auf "Makefile" geklickt --> Optimization level --> "s" ausgewählt
Siegfried schrieb: > Das ist interessant. Wo kann man das Einstellen? AVR-Studio: -> Project -> Configuration Options -> Custom Options -> eintragen und dann "Add" drücken Peter
Peter Stegemann schrieb: >> -Os >> -lm >> -fno-inline-small-functions >> -Wl,--relax >> --combine -fwhole-program kannst du bitte auch mal kurz erklären was die Schalter genau machen/verursachen
Peter schrieb: > AVR-Studio: > -> Project > -> Configuration Options > -> Custom Options > -> eintragen und dann "Add" drücken > > > Peter Soweit gefunden und eingetragen. Der "Standard-Kram" der drin steht, muss der gelöscht werden oder bleibt der und es werden nur diese Optionen hinzugefügt?
Christian H. schrieb:
> Ansonsten auf Attiny84 wechseln.
Wo gibt's den als -20PU um geringe Versandkosten und ohne
Mindestbestellwert?
Siegfried schrieb: > Das Programm soll in eine Kleinserie für KFZ Anwendung finden. In einem > KFZ Forum sind ein paar Interessenten, die teilweise auch mitentwickelt > haben, die das dann in ihr Auto bauen. > Daher spielt der Preis in gewisser Maßen eine Rolle, Stückzahl ist 50 > geplant. Verdient wird nichts ... Also ein Freizeitprojekt. Was nicht heißt, dass eure (deine?) Zeit keinen Wert hat und beliebig verschwendet werden kann für Optimierungen im Centbereich. Sag deinen Kumpels, dass du einen Controller mit mehr Speicher brauchst, und fertig. Wer sich drüber aufregt, kann ja gern versuchen, das Programm kleinzubasteln. So seh ich das ...
Ich hab Peter D's Optimierungsoptionen im AVR-Studio mal ausprobiert. Hab ein Programm, welches 2046 Bytes brauchte (ATTiny24). Hier ist aufgelistet, wie sich die Programmgröße nach einfügen der einzelnen Compileroptionen ändert: -0s (war schon drin) -> 2046 -lm -> 2046 -fno-inline-small-functions -> 1956 -Wl,--relax -> 1956 --combine -fwhole-program -> 1832 Insgesamt also 2046-1832 = 214 Bytes gespart - etwa 10% !
Nun gut, ein paar Makefile-Optionen auszuprobieren ist ja kein Aufwand, und in diesem Fall hats was gebracht. Ich bezog mich auch eher auf die Vorschläge, Assemblerlistings zu analysieren und größere Teile Quellcode umzuschreiben. Damit kann man nämlich ein echtes Fass aufmachen, weil man nach der Verkleinerung (wenn sie denn gelingt!) noch verifizieren muss, dass das Programm immer noch dasselbe tut wie vorher, und zwar in allen Fällen. Gerade beim Handoptimieren vergisst man da gerne ein paar Kleinigkeiten ...
Klaus schrieb: > Das einzige Problem könnte sein, dass das Programm evtl. später bei > einer neuen Compilerversion 3 Bytes mehr hat, und dann nicht mehr rein > passt. Könnte mir bitte jemand erklären, warum das Programm dann 3 Bytes größer wäre ? Hab mich noch nicht so stark mit Compilern beschäftigt.
Artur H. schrieb: > Könnte mir bitte jemand erklären, warum das Programm dann 3 Bytes größer > wäre? Hab mich noch nicht so stark mit Compilern beschäftigt. Naja, 3 Byte geht bei AVRs tatsächlich schlecht. ;-) Dass verschiedene Compilerversionen verschiedene Objektcodes produzieren liegt in der Natur der Sache. Und auch, dass eine neuere Version insbesondere vom GCC auch mal etwas mehr Code produziert, weil 99% der Renovierungen bei den GCC-Versionen nicht spezifisch für den AVR durchgeführt und getestet werden. Viele Optimierungen sind nur für Highend-Architekturen relevant und können sich auf AVRs nachteilig auswirken.
Zumindest in früheren Versionen konnte auch -fno-split-wide-types -fno-tree-scev-cprop hilfreich sein.
tuppes schrieb: > Ich bezog mich auch eher auf die Vorschläge, Assemblerlistings zu > analysieren und größere Teile Quellcode umzuschreiben. Das ist die Hardcore-Variante. Mein erster Ansatz besteht darin, im Mapfile unter den Funktionen nach grösseren Brocken zu suchen, vor allem wenn sie grösser sind als man vom Quellcode her vermuten würde. Und dort nachzusehen, ob irgendwas aus dem Ruder läuft.
Was auch oft relativ viel bringt: Alle Variablen durchgehen und dabei pingelig sein. Muss es wirklich ein int sein oder reicht auch schon ein uint8_t? Unnötige 16-Bit Arithmetik wird nun mal mit mehr Code geahndet. float ist auch so ein Speicher und Rechenzeit-Killer. Zusammenfassen von unabhängigen Bit-Flags in eine einzige uint8_t (oder was auch immer) ist hingegen meistens keine so gute Idee. Das extrahieren von Bits wird mit zusätzlichem Code bezahlt.
Nun stehe ich trotzdem noch vor dem Prozessorproblem, welchen ich am besten nun nehmen sollte... :-)
Karl heinz Buchegger schrieb: > Zusammenfassen von unabhängigen Bit-Flags in eine einzige uint8_t (oder > was auch immer) ist hingegen meistens keine so gute Idee. Das > extrahieren von Bits wird mit zusätzlichem Code bezahlt. das ist schon eine gute Idee, wenn man als Speicherort ein freies Register im Bitadressierbaren Bereich benutzt. Entweder eines der GIORs oder von Funktionseinheiten, die man nicht braucht. Da bieten sich an: UART, SPI, TIMER, EEPROM. Man muss nur creativ sein und dran denken, wenn man die dann doch benutzen will.
dr.schmock schrieb: > -> 1956 > --combine -fwhole-program > -> 1832 Deutet in der Regel darauf hin, dass man Dinge global hat, für die ein "static" genügt hätte. (OK, die beiden Optionen können danach dann trotzdem noch ein wenig herausholen, falls das Projekt mehrere Dateien beinhaltet.)
Siegfried schrieb: > Welche Features brauche ich: > - interner Oszillator 8Mhz Haben nahezu alle. Der in den neueren AVRs ist allerdings etwas stabiler als der frühere. > - 2 Timer, mind. einer 16-bit mit Input Capture, Compare Match, einer > 8-bit mit Compare Match Funktion Haben auch praktisch alle AVRs. > - ADC Wandler mit mind. 2 ADC-Eingängen Haben die meisten. > - externes Interrupt (hat wohl jeder) Ja, hat jeder. > - Beim Attiny44 habe ich alle 11 I/O Pins (Reset habe ich nicht > angerührt und als I/O Pin gefust) gebraucht, also wäre das noch eine > min. Anforderung Dann wäre meine Empfehlung auch erstmal ein ATtiny84, du programmierst und debuggst mal alles zu Ende, und am Ende guckst du, ob man es auf einen '44 heruntergebrochen bekommt. > DebugWIRE > brauche ich nicht On-Chip Debugging ist schon ganz nett, kann einem gut die Entwicklungs- zeit verkürzen. Kann sowohl den ATtiny44 als auch der vorgeschlagene ATtiny84, auche ein ATmega88 kann es, der alte ATmega8 aber nicht.
Siegfried schrieb: > Nun stehe ich trotzdem noch vor dem Prozessorproblem, welchen ich am > besten nun nehmen sollte... :-) Zwei Tiny84 und einen davon schickst du mir... ;-)
1 | -mcall-prologues |
kann auch noch Einiges bringen, vor allem, wenn viele Funktionen vorhanden sind.
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.