www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik BOOL , Speicherbedarf und Laufzeittempo


Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mal einige grundsätzliche Fragen

ich hab viele globale Flags, normal BOOL, im Standard C als int 
deklariert, ist aber nicht wirklich resourcenschonend, es würde auch 
unsigned char reichen, aber auch das sind pro Flag 7 verschwendete Bits, 
bloß ob ich die zu einem Array zusammenfasse und per Bitschieberei 
testen sollte ?

zum einen steht der geringe Platzgewinn, zum anderen die Rechenzeit und 
der Code Wachstum, wie löst ihr das ?

gruss
jar

Autor: Nullpointer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, wie du sagtest, wenn's schnell sein muss als byte, wenn's sparen 
muss als bit in einem byte

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joachim B.:
Auf welcher Plattform arbeitest Du denn? Bei Embedded-Systemen, die 
bitadressierbare Speicherbereiche haben (z.B. 8051er) stellen die 
Compiler ja auch Bit-Typen zur Verfügung, die von der Zugriffszeit 
genauso schnell sind wie normale Variablen-Zugriffe.

Wenn Du keinen bitadressierbaren Speicher zur Verfügung hast: Manche 
Leute behelfen sich anstelle der Schiebereien mit Bitfeldern. Die 
erzeugen zwar im Prinzip den selben Code wie die Schiebereien, es gibt 
aber Leute, die mit der Schreibweise
flags.flag1 = 1;
besser klarkommen als mit
flags |= 1 << FLAG1;

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:
> @Joachim B.:
> Auf welcher Plattform arbeitest Du denn?

AVR gcc , nur atmels

mache das gerade 8 Wochen, habe aber einiges an Prüftechnik in C 
geproggt, aber unter DOS (PC) und Atati ST, da war Speicher ja kein 
Thema, nu bin ich schon immer am Limit vom mega32 mit -Os bei 70%, der 
mega8 wurde mir viel zu schnell zu klein

also was sagt der Fachman, bitfriemeln unter AVR und gcc oder lieber 
byte Var als BOOL ?

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>nu bin ich schon immer am Limit vom mega32 mit -Os bei 70%, der
>mega8 wurde mir viel zu schnell zu klein

Meiner Erfahrung nach kann man die Binary-Größe drastisch reduzieren, 
wenn man sooft wie möglich (aber in sinnvollem Rahmen) Prozeduren und 
Hilfsfunktionen benutzt.
Wenn man von "größeren" Architekturen kommt, ist man gerade im Bereich 
"Zerstückelung" ungeübt/unbedarft, was dann auf dem uC zu unnötig großen 
Programmen führt.

Einen Geschwindigkeitsverlust muß man dabei nicht befürchtet, denn wenn 
diese gefragt ist, werden die Funktionen per inlining eh wieder 
"zusammengefügt".

Ansonsten findet google diverse Tutorials, um aus gcc kleinere binaries 
herauszukitzeln.

Ach ja... ab und zu mal in die generierte .map-File zu blicken lüftet 
ebenfalls manchen Schleier :-)

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.