mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Prozessor 100% voll, Problem?


Autor: Siegfried (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mein Attiny44 ist nach dem kompilieren zu 100% voll.
Kann das Probleme geben oder ist das noch ok?

Danke.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst wenn noch 3 Bytes hinzukommen wird das zum Problem. Beispielsweise 
mit der nächsten Compilerversion.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon mit den Optimierungseinstellungen experimentiert?

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansonsten auf Attiny84 wechseln.

Autor: Siegfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siegfried schrieb:
> Bin sowieso am Überlegen, ob ich auf Mega8 umsteige.

Warum ausgerechnet auf so einen Großvater?

Autor: Siegfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ATmega88 liegt preislich etwas gleich wie der ATmega8.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
-Os
-lm
-fno-inline-small-functions
-Wl,--relax
--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

Autor: hakuspakus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hakuspakus schrieb:
> Da gibt es doch nur eine Loesung.

Falsch, Assembler wäre die 2. Lösung :-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
>
> -Os
> -lm
> -fno-inline-small-functions
> -Wl,--relax
> --combine -fwhole-program
> 

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.

Autor: Siegfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siegfried schrieb:
> Das ist interessant. Wo kann man das Einstellen?

AVR-Studio:
-> Project
-> Configuration Options
-> Custom Options
-> eintragen und dann "Add" drücken


Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Siegfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:
> Ansonsten auf Attiny84 wechseln.

Wo gibt's den als -20PU um geringe Versandkosten und ohne 
Mindestbestellwert?

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: dr.schmock (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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% !

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Artur H. (hohoho)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumindest in früheren Versionen konnte auch
 -fno-split-wide-types
 -fno-tree-scev-cprop
hilfreich sein.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Siegfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun stehe ich trotzdem noch vor dem Prozessorproblem, welchen ich am 
besten nun nehmen sollte... :-)

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael K. (kichi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-mcall-prologues 
kann auch noch Einiges bringen, vor allem, wenn viele Funktionen 
vorhanden sind.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.