MSP430 C-Programmierung, Programmgröße reduzieren

Gast #2174242
Hallo Leute,
die Sonne scheint und der TI Compiler meckert, dass kein Platz mehr ist 
(MSP430G2231, 2kB).
Dabei ist noch lange nicht alles programmiert und die ganzen 
Hardwarefeatures sind auch noch nicht genutzt :-(

Ich bemühe mich gerade, alle Funktionen/Prozeduren, die nur aus 
organisatorischen Gründen bestehen, als inline zu deklarieren, um 
Funktionsaufrufe einzusparen (z.B. Initialisierungs-Prozeduren).
Macht das bei void ... (void) Funktionen überhaupt Sinn?

Variablen nur den nötigen Scope zu geben.
Konstanten nur, wo erforderlich. Es sammelt sich ganz schön was an.

Wie ist es auf einem 16-bit'er mit der Variablengröße? Nutzt oder 
schadet es mehr, wenn man weniger als xint16_t benutzt?

Ist es günstiger, viele 8 Variablen als Flag zu nutzen und = 1 bzw. 0 zu 
setzen, oder 1 Variable zu nutzen und die Bits einzeln zu bearbeiten?

Ich würde mich freuen wenn ihr ein paar Tricks auf Lager habt.
#2174249
Hallo!

Also, inline deklarierte Funktionen benötigen unter Umständen mehr Platz 
im uC als sonst. "inline" ist eine Geschwindigkeitsoptimierung, die zu 
ungunsten des Platzes gemacht wird. d.h. an jede Stelle, wo die inline 
Funktion aufgerufen wird, wird der komplette Funktionsrumpf kopiert.

RAM lässt sich sparen indem man "jedes Bit" nutzt. Also beispielsweise 
eine 16-Bit variable für 16 Flags verwendet, anstatt 16 bytes die alle 
nur 1bit Information speichern.

Sinnvoll kann sein, anstatt eine Table (f. Table lookups) zu verwenden 
die Daten zu berechnen, wenn die Berechnung weniger Platz benötigt als 
die Tabelle. Wird das Programm zwar langsamer, aber es "passt" mehr in 
den uC - alternativ dazu lässt sich auch ein größerer uC einlöten...

Viel Spaß beim "Bitklauben"!

Grüße,

Bernhard
#2174633
Bei einfachen Variablen ist ein short günstiger als ein char, weil bei 
letzerem irgendwo immer noch ein and r,255 generiert wird, entweder bei 
der Erzeugung des Rückgabewertes oder beim Aufrufer. Lass Dir mal 
Assembler-Quellcode generieren, dann siehst Du den Unterschied.

Außerdem: Bibliotheksfunktionen im MAP-File prüfen. Auch so etwas, was 
man nicht gleich sieht: Division, Modulo, Multiplikation (wenn der 
Prozessor keinen Multiplizierer hat),... Im MAP-File siehst Du die 
Speicherfresser.

fchk
Gast #2174709
Ohne den Code zu kennen ist es schwer hier zu helfen. Inlinen hilft nur 
begrenzt aber das kannst du ja einfach ausprobieren.

#pragma inline

und dann die Funktion hinterher schreiben.
Gast #2174949
Frank K. schrieb:
> Bei einfachen Variablen ist ein short günstiger als ein char, weil bei
> letzerem irgendwo immer noch ein and r,255 generiert wird, entweder bei
> der Erzeugung des Rückgabewertes oder beim Aufrufer

Kannst Du das evtl. mal näher erläutern?
Gast #2440821
hi,

jetzt hatts mich auch erwischt :( der 2k controller ist scheinbar zu 
klein für mein programm.

ich habe an 2 stellen floatingpoint operationen die die codesize extrem 
aufblähen :(

kann ich die irgendwie umgehen?
1
return (int)((100.0/16384) *raw); //Berechnung des der Luftfeuchte [%] und Rückgabe
1
return (char)(((ADC10MEM - 673) * 423) / 1024); //Temperatur in °C ausrechnen und zurückgeben


allein diese beiden operationen benötigen gut 500b an instructionen?!

Ich programmiere auf dem Launchpadcontroller MSP430G2231 :(

VG
Gast #2441120
Temperatur und Luftfeuchte ? und floating point ? Dein Konzept ist 
falsch, fixed point ist bei so einem kleinen Controller angesagt und 
sicherlich auch machbar.
Gast #2443431
was heist hier mein konzept ist falsch?

ich muss schnellst mölglich zu einem Ziel kommen und bin leider kein 
profi. deshalb werde ich wohl einige subotimalitäten in kauf nehmen 
müssen...
hast du mir nen literatur-tipp für berechnungen mit fixed point ?

leider stehen jetzt klausuren an so dass es vorerst keine beachtung mehr 
finden wird.Das projekt muss bis anfang januar abgeschlossen sein...
#2443544
Peter schrieb:
> was heist hier mein konzept ist falsch?
>
> ich muss schnellst mölglich zu einem Ziel kommen und bin leider kein
> profi. deshalb werde ich wohl einige subotimalitäten in kauf nehmen
> müssen...

M. A. nach sind die 2k msp430 Controller nur für Profis geeignet. Die 
sind meiner Erfahrung nach noch schwieriger zu programmieren als z. B. 
der attiny2313 mit vergleichbaren Kenndaten. Ich stoße auf den msp430 - 
mit der gleichen Applikation - noch früher an die RAM-Grenze.

Generell - und als Einsteiger m. A. sowieso - würde ich mit einem 
"großen" µC beginnen, also mindestens 16k Flash und 1k RAM. Downgrade 
geht immer, Bitklauben macht gar keinen Spass.

Die Frage ist also: Ist der MSP430G2231 vorgegeben? Wäre evtl. der 
msp430g2553 eine Alternative? Geht's auch ganz anders? In der gleichen 
preislichen Region gibt es genug Alternativen, wo Du definitiv bis 
Januar nicht an irgendwelche Grenzen der HW stößt.

> hast du mir nen literatur-tipp für berechnungen mit fixed point ?

http://drdobbs.com/cpp/207000448

Würde mich allerdings wundern, wenn Du das alles unter Berücksichtigung 
Deiner restlichen Informationen in 2k realisieren kannst. Vor allem bis 
Jan. Bleib bei "integer".

> leider stehen jetzt klausuren an so dass es vorerst keine beachtung mehr
> finden wird.Das projekt muss bis anfang januar abgeschlossen sein...

Das ist dann der dritte Fehler im Konzept, da der Weihnachtsmann das 
auch nicht mehr hinbekommt :-)
Gast #2443672
400 : 3.14 = 127.38

Anstatt mit Flotaing Point zu rechnen könntest du auch...

40000 : 314 rechnen oder ?

Wir sind es gewohnt Zahlen im dezimal System zu erweitern aber das kann 
man auch zur Basis 2 und dann sind es nur noch Schiebeoperationen.

Im Anhang mal ein Beispielcode für den Controller deiner Wahl in der 
sämtliche Korrekturrechnungen per fixed point gemacht werden, vielleicht 
hilft das.

Ansonsten:
http://www.hackersdelight.org/divcMore.pdf

Oder zeig deinen Code her statt herumzumeckern wie wenig zeit du noch 
hast. Ich denke das ist mit wenigen Korrekturen schnell zu machen.
Angehängte Dateien:
Gast #2443684
Dann verwenden wir mal den internen Temperatursensor und beachten dabei 
was wir gelernt haben.

Im Anhang der Code inklusive Ausgabe auf dem USB Appl. COM Port. Gerade 
mal 672 Byte Code.

Wenn es bei dir nur um 2 Sensoren geht dann sollte dein gesamter 
Codeverbrauch nicht über 1.4k gehen also noch reichlich Platz für den 
Rest deiner Anwendung.

Bei dem Codebeispiel solltest du die beiden Stützpunkte kalibrieren 
(Eiswasser + Körpertemperatur) so habe ich es gemacht. Kannst auch 
Wasserdampf verwenden und deinen MSP kochen :-)
Angehängte Dateien:
Gast #2443881
Eiswürfel in Plastikbeutel :-) ist doch ganz einfach. Und dann ein 2tes 
Thermometer und ein bischen experimentieren. So genau muß es ja nicht 
sein oder ?

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 15 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.