Programm zu groß für 1k Flash

[Dominik R. (vision)]

Hiho zusammen,

mein erstes etwas größeres uC-Projekt und irgendwie hakt es dauernd...
Mein aktuelles Problem ist, das das Programm zu groß geworden ist, 
nachdem ich alle Einzelteile zusammen gebaut habe.
Ich habe 1k Flash zur Verfügung, das Programm ist aber ca. 3k groß.
Liegt es an meiner umständlichen/ineffizienten Programmierung oder ist 
der Flash einfach nur zu klein für den Funktionsumfang?
Ich habe die '.c' mal angehängt. Vielleicht hat ja jemand kurz Zeit, 
sich das Gewurstel mal anzusehen...

Danke schonmal...

[Bernd N (Gast)]

Welchen MSP verwendest du hier ? Optimizer angeschmissen ? Welcher C 
Compiler ?

[Dominik R. (vision)]

Sorry, falscher Stand der '.c'!!!
Hier noch einmal der aktuelle Stand.

[Max D. (max_d)]

Wenns ein einzelstück sein soll: nimm nen größeren µC (wird vmtl. dann 
4kb werden)
Wenns Massenware sein soll: versuchs auf 2kb zu kriegen und nimm ne 2kb 
µC

Wenn du nicht grade mit debug-Optimierung und nur floating point 
berechnung gearbeitet hast, dann wirst du nie aus 3kb eines machen, da 
sind 2 schon sportlich.

[Dominik R. (vision)]

Bernd N schrieb:
> Welchen MSP verwendest du hier ? Optimizer angeschmissen ? Welcher C
> Compiler ?

MSP ist der G2131, Optimierer auf kleinste Größe und Compiler ist der 
vom CCS.

[Daniel V. (danvet)]

Ich kann mir nicht vorstellen, dass diese paar Zeilen 3k erzeugen.
Schau mal dein MAP-File an, was da noch alles drin ist.
Irgendwelche Libs dazugelinkt, die nicht gebraucht werden?

Ausserdem fehlt das While(1){} in der main.

[Udo S. (urschmitt)]

Daniel V. schrieb:
> Ich kann mir nicht vorstellen, dass diese paar Zeilen 3k erzeugen.

So gings mir auch, ich habe auch mal kurz quer überflogen und habe weder 
floating point gefunden noch printf oder andere Dinge, die viel Platz 
brauchen.
Ich kenne die MSPs nicht, aber das bischen C Code gibt doch keine 3K?
Also MAP File, im Zweifel mal posten.

[Dominik R. (vision)]

Ich habe zuletzt die "Dauermessung" mit dem WDT als Status-LED-Timer 
eingebaut.

Vorher hatte ich knapp 1k, jetzt bekomme ich 'ne Fehlermeldung, dass das 
Programm nicht in den Speicher passt und wenn ich die angegebene 
HEX-Zahl umrechne, bin ich bei gut 3kByte.
Andere LIBs hab ich nicht eingebunden...

Und die Endlosschleife habe ich weg gelassen, weil die bei den 
TI-Beispielen auch nicht da war, aber daran liegt es glaube ich auch 
nicht...

[Karl H. (kbuchegg)]

Schreib das hier um

uint16_t wert10 = (uint16_t)(tarawert*0.1);
    uint16_t wert90 = (uint16_t)(tarawert*0.9);

so dass keine Floating Point Berechnung mehr auftaucht und dein 
Speicherverbrauch wird wieder sinken.

Du musst ja nicht mit 0.1 multiplizieren! Mal 10 durch 100 tuts auch. 
Mal 1 durch 10, bzw. mal 9 durch 10 ist noch besser, weil es die Gefahr 
eines Overflows während der Berechnung kleiner macht.
Aber diese beiden Multiplikationen ziehen einen ganzen Rattenschwanz mit 
ins Programm hinein.

[Dominik R. (vision)]

Hier ist noch das MAP.

[Dominik R. (vision)]

Karl Heinz Buchegger schrieb:
> Schreib das hier um
>

> uint16_t wert10 = (uint16_t)(tarawert*0.1);
>     uint16_t wert90 = (uint16_t)(tarawert*0.9);
>

> so dass keine Floating Point Berechnung mehr auftaucht und dein
> Speicherverbrauch wird wieder sinken.
>
> Du musst ja nicht mit 0.1 multiplizieren! Mal 10 durch 100 tuts auch.
> Mal 1 durch 10, bzw. mal 9 durch 10 ist noch besser, weil es die Gefahr
> eines Overflows während der Berechnung kleiner macht.
> Aber diese beiden Multiplikationen ziehen einen ganzen Rattenschwanz mit
> ins Programm hinein.

Das werde ich nachher ausprobieren. Hätte nicht gedacht, das *0.9 was 
anderes macht als /10 *9...

[Ralf G. (ralg)]

Dominik R. schrieb:
> Das werde ich nachher ausprobieren. Hätte nicht gedacht, das *0.9 was
> anderes macht als /10 *9...

sogar *9/10 ist noch was anderes!

[Rolf Magnus (Gast)]

Dominik R. schrieb:
> Das werde ich nachher ausprobieren. Hätte nicht gedacht, das *0.9 was
> anderes macht als /10 *9...

0.9 ist eine Gleitkommazahl, also muß die Bibliothek für 
Gleitkomma-Berechneungen bemüht werden. 10 und 9 sind dagegen nur 
Integers, brauchen das also nicht.

[Karl H. (kbuchegg)]

Dominik R. schrieb:

> Das werde ich nachher ausprobieren. Hätte nicht gedacht, das *0.9 was
> anderes macht als /10 *9...

23 / 10   ->  2
              2 * 9  -> 18


23 * 9    -> 207
             207 / 10  -> 20

23 * 0.9  ->  20.7


18 != 20 != 20.7
3 verschiedene Ergebnisse, je nachdem wie man rechnet

Die Grundlagen der Datentypen und ihre Verwendung bzw. wie sie 
Berechnungen beeinflussen solltest du aber schon kennen, wenn du was 
programmierst.

[Daniel V. (danvet)]

Dominik R. schrieb:
> Hier ist noch das MAP.

.text ist nur 0x3d4 gross, also 980 Byte.

Wie kommst du auf 3k? Eventuell ist dein Hexfile 3k gross. Lade doch das 
Programm einfachmal auf deinen uC....

[Daniel V. (danvet)]

Dominik R. schrieb:
> Ich habe zuletzt die "Dauermessung" mit dem WDT als Status-LED-Timer
> eingebaut.
>
> Vorher hatte ich knapp 1k, jetzt bekomme ich 'ne Fehlermeldung, dass das
> Programm nicht in den Speicher passt und wenn ich die angegebene
> HEX-Zahl umrechne, bin ich bei gut 3kByte.
> Andere LIBs hab ich nicht eingebunden...
>
> Und die Endlosschleife habe ich weg gelassen, weil die bei den
> TI-Beispielen auch nicht da war, aber daran liegt es glaube ich auch
> nicht...

Hab ich jetzt erst gesehen.

Ich tippe:
Map-File und C-File passen nicht zusammen.

[Dominik R. (vision)]

Kann sein, dass das map-file noch eins von dem stand ist, wo ich die 
"dauermessung" noch nicht drin hatte. Ich überprüfe das nachher noch 
einmal und lade die aktuelle map noch mal hoch. Sorry.

Das ein integer etwas anderes ist als ein float ist mir bewusst. Ich war 
nur davon ausgegangen, dass eine implizierte konvertierung durchgeführt 
wird, wenn man zwei integer dividiert, bei denen ein Rest übrig bleibt.

Ich werde nachher die ...*0.9 durch (.../9)*10 und die ...*0.1 durch 
.../10 ersetzen. Damit müsste ich ja Platz schaffen können. Vielleicht 
passt es dann ja schon wieder.

[Ralf G. (ralg)]

Dominik R. schrieb:
> (.../9)*10

*9/10

Außer, du willst da jetzt was ganz anderes ausrechnen...

[Amateur (Gast)]

Bei manchen C-Compilern muss man die Bibliotheken, die plötzlich nicht 
mehr benötigt werden explizit aus den Listen entfernen. Sonst werden sie 
weiterhin unnötig hinzu gelinkt, zumindest der Rumpf.

[Dominik R. (vision)]

Ralf G. schrieb:
> Dominik R. schrieb:
>> (.../9)*10
>
> *9/10
>
> Außer, du willst da jetzt was ganz anderes ausrechnen...

Ja, klar. *9/10 meinte ich.

Ich habe das jetzt auch geändert und bin somit auf 1258 Byte. Leider 
immer noch knapp 270 Byte zuviel... mal davon abgesehen, dass ich bisher 
immer dachte, 1 kByte wären 1024 Byte. Platz ist aber nur 992 Byte.

Noch irgend jemand 'ne Idee, wo man noch etwas optimieren kann?

Ach ja, hier noch das aktuelle Map-File.

[holger (Gast)]

>  timerCount = (timerCount + 1) % 120;            //ca. 1 Min.

Mach da mal

 timerCount = (timerCount + 1) % 128;            //ca. 1 Min.

draus. Wird wohl egal sein obs etwas mehr als 1 Minute ist.

  volatile uint8_t m;
  for(m = 0; m < 60; m++){

Was soll das volatile da? Mach das weg.

[Karl H. (kbuchegg)]

Wenn du deine Werte für ledstatus ein wenig intelligenter vergeben 
würdest, anstatt einfach von 0 beginnend durchzuzählen, dann würdest du 
dir hier

    switch(ledStatus){
      case 1:
        P1OUT ^= LED_GREEN;
        P1OUT |= LED_YELLOW + LED_RED;
        break;
      case 2:
        P1OUT &= ~LED_GREEN;
        P1OUT |= LED_YELLOW + LED_RED;
        break;
      case 3:
        P1OUT &= ~LED_YELLOW;
        P1OUT |= LED_GREEN + LED_RED;
        break;
      case 4:
        P1OUT &= ~LED_RED;
        P1OUT |= LED_GREEN + LED_YELLOW;
        break;
      case 5:
        P1OUT ^= LED_RED;
        P1OUT |= LED_GREEN + LED_YELLOW;
        break;

zb schon eine ganze Menge sparen.
Denn deine LED sind am Port sowieso an benachbarten Pins angeordnet, so 
dass du im Grunde nichts anderes tun musst, als ledStatus genau den 
binären 3-Bit Wert zu geben, den du ganz einfach am Port ausgeben 
kannst.

[Johann L. (gjlayde)]

Irgendwie verteilst du volatile mit dem Gießkannanprinzip. Z.B. ist / 
messwert/ volatile und dann sowas. Das muß zu ineffizientem Code 
führen!

     if(messwert < 0){
          ledStatus = 1;
        }
        else if((messwert > 0) && (messwert < wert10)){
          ledStatus = 2;
        }
        else if((messwert > wert10) && (messwert < wert90)){
          ledStatus = 3;
        }
        else if((messwert > wert90) && (messwert < tarawert)){
          ledStatus = 4;
        }
        else if(messwert < tarawert){
          ledStatus = 5;
        }

[holger (Gast)]

>Irgendwie verteilst du volatile mit dem Gießkannanprinzip.

Genau. Einfach einmal messwert in eine lokale Variable
holen und den ganzen Klimbim dann damit ausführen.
Sonst muss messwert ja jedesmal neu aus dem Speicher gelesen werden.

[Karl H. (kbuchegg)]

So ganz hab ich noch nicht durchschaut, wozu du den Watchdog Timer 
benötigst.

Wenn ich das richtig sehe, dann ist der Watschdog doch sowieso nur an 
einer einzigen Programmsequenz aktiv - nämlich der Schleife in der die 
Messungen gemacht werden. An deren Ende steht aber ein delay. Da frage 
ich mich: Hä? Wozu der ganze Klimbim mit dem Watchdog - mach doch den 
Update der LEDs gleich in dieser Schleife und spar dir den ganzen 
Hackmack mit Watchdog aktivieren, konfigurieren und eigener ISR.
Oder übersehe ich da jetzt was?

[Dominik R. (vision)]

Johann L. schrieb:
> Irgendwie verteilst du volatile mit dem Gießkannanprinzip. Z.B. ist /
> messwert/ volatile und dann sowas. Das muß zu ineffizientem Code
> führen!

Ja, stimmt schon.Ich bin mir halt unsicher, wann der Compiler vielleicht 
wichtige Dinge "wegoptimiert"...

Karl Heinz Buchegger schrieb:
> Denn deine LED sind am Port sowieso an benachbarten Pins angeordnet, so
> dass du im Grunde nichts anderes tun musst, als ledStatus genau den
> binären 3-Bit Wert zu geben, den du ganz einfach am Port ausgeben
> kannst.

da stehe ich jetzt etwas auf dem Schlauch. ledStatus 2 wäre dann z.B. 
0xC0 (also P1.7 HI, P1.6 HI, alles andere auf LO) oder wie muss ich mir 
das vorstellen?

[Dominik R. (vision)]

Karl Heinz Buchegger schrieb:
> So ganz hab ich noch nicht durchschaut, wozu du den Watchdog Timer
> benötigst.
>
> Wenn ich das richtig sehe, dann ist der Watschdog doch sowieso nur an
> einer einzigen Programmsequenz aktiv - nämlich der Schleife in der die
> Messungen gemacht werden. An deren Ende steht aber ein delay. Da frage
> ich mich: Hä? Wozu der ganze Klimbim mit dem Watchdog - mach doch den
> Update der LEDs gleich in dieser Schleife und spar dir den ganzen
> Hackmack mit Watchdog aktivieren, konfigurieren und eigener ISR.
> Oder übersehe ich da jetzt was?

Ja, stimmt... vorher hatte ich den WDT auch noch für was anderes. Das 
ist aber irgendwann geändert worden und ich habe nicht daran gedacht, 
dass ich die LED-Anzeige dann ja auch ohne WDT machen kann...

[holger (Gast)]

>Ja, stimmt schon.Ich bin mir halt unsicher, wann der Compiler vielleicht
>wichtige Dinge "wegoptimiert"...

Wer eine globale Variable "i" anlegt sollte sich um ganz andere
Dinge sorgen machen. Und diese ganzen Delays in den Interrupts.
Ganz klares NoGo.

[Dominik R. (vision)]

Das mit dem globalen i war nur ein Versuch, aus zwei Variablen, die ja 
auch etwas Speicher brauchen, eine zu machen, da ich an zwei Stellen 
eine Zähler-Variable brauchte, aber beide Stellen nie gleichzeitig 
zählen. Dass es das nicht gebracht hat, ist mir inzischen auch schon 
klar ;-)

Wo sollen die Delays denn sonst hin?

Anbei noch einmal die '.c' ohne WDT. Leider fehlen mir immer noch 148 
Bytes...

[ich kann lesen (Gast)]

Man lese diesen Beitrag:
Beitrag "Re: MSP430G211 analoge Eingänge"
Der Code ist für ein Kundenprojekt. lol

Dem ganzen Projekt fehlt es an Struktur. Erst wurde die HW verbastelt, 
jetzt ist die SW dran.

Das bisschen Gefrickele passt doch locker in den 1k. Ein Blick in die 
Projektkonfiguration kann helfen.

[Dominik R. (vision)]

ich kann lesen schrieb:
> Dem ganzen Projekt fehlt es an Struktur. Erst wurde die HW verbastelt,
> jetzt ist die SW dran.

Für die Hardware kann ich nunmal nichts, die habe ich so vorgegeben 
bekommen.
Und ja, jetzt ist die Software dran. Aber da ich wie gesagt noch ein 
ziemlicher Anfänger im Bereich uC bin und das eher als Hobby sehe, mit 
dem ich mir ein paar Euros dazu verdienen kann, weiss ich nicht, wo dein 
Problem ist.

Aber wenn du mir jetzt noch sagst, was ich in der Projektkonfiguration 
einstellen muss, damit das bisschen gefrickel auch in die 1k passt, wäre 
ich echt ein ganzes Stück weiter.

[ich kann lesen (Gast)]

Daniel V. schrieb:
> Ausserdem fehlt das While(1){} in der main.

gute Frage,

Dominik R. schrieb:
> Und die Endlosschleife habe ich weg gelassen, weil die bei den
> TI-Beispielen auch nicht da war, aber daran liegt es glaube ich auch
> nicht...

falsche Antwort. Besser wäre: Aus dem LPM kommt der MSP nur per 
Interrupt. Nach Abarbeitung der ISR wird das Statuswort restauriert und 
damit wieder in den LPM geschaltet.

Karl Heinz Buchegger schrieb:
> spar dir den ganzen
> Hackmack mit Watchdog aktivieren, konfigurieren und eigener ISR.
> Oder übersehe ich da jetzt was?

Der Watchdog kann beim MSP als einfacher Timer genutzt werden.

[holger (Gast)]

>Aber wenn du mir jetzt noch sagst, was ich in der Projektkonfiguration
>einstellen muss, damit das bisschen gefrickel auch in die 1k passt

Du kannst in den Projektoptionen nichts einstellen
was deinen vergurkten Code verbessert.

Die meisten deiner volatiles sind überhaupt nicht notwendig.
DA holst du dir dein Flash zurück.

[Dominik R. (vision)]

holger schrieb:
>>Aber wenn du mir jetzt noch sagst, was ich in der Projektkonfiguration
>>einstellen muss, damit das bisschen gefrickel auch in die 1k passt
>
> Du kannst in den Projektoptionen nichts einstellen
> was deinen vergurkten Code verbessert.
>
> Die meisten deiner volatiles sind überhaupt nicht notwendig.
> DA holst du dir dein Flash zurück.

Die volatiles sind in der aktuellen Version gar nicht mehr drin.

ich kann lesen schrieb:
> Der Watchdog kann beim MSP als einfacher Timer genutzt werden.

Ich hatte den WDT als einfachen Timer genutzt, war aber - wie kbuchegg 
schrieb - gar nicht mehrnötig, also auch entfernt.

[hans (Gast)]

Sind noch irgendwelche unnötigen Bib's drin?
Welche Variablen können vom Datentyp kleiner werden?
Auf gleiche Konstanten bei den Wartezeiten gehen!?
Delay über Timer?
Inlinefunktionen?
Anderer Algorithmus überlegen?
...

[ich kann lesen (Gast)]

holger schrieb:
> Du kannst in den Projektoptionen nichts einstellen
> was deinen vergurkten Code verbessert.

:-D Das stimmt zu 100%!

Aber man kann einmal nachsehen, was noch so alles zum Kraut und Rüben 
Programm dazu kommt. ;-)

[holger (Gast)]

>> Die meisten deiner volatiles sind überhaupt nicht notwendig.
>> DA holst du dir dein Flash zurück.
>
>Die volatiles sind in der aktuellen Version gar nicht mehr drin.

Ich habe nicht gesagt ALLE sollten kein volatile sein.
Wo ist denn der derzeitige Flash Bedarf?

[holger (Gast)]

>Wo ist denn der derzeitige Flash Bedarf?

>Leider fehlen mir immer noch 148
>Bytes...

Ok Frage selber beantwortet;)

[Dominik R. (vision)]

Ich verstehe nicht wirklich, wann der Compiler ggf. eine Variable 
wegoptimiert und diese somit als volatile gekennzeichnet werden muss...

[ich kann lesen (Gast)]

Jetzt habe ich zum Spaß das Programm unverändert mit den 
Standardeinstellungen MAKEn lassen und

 984 bytes of CODE  memory
  62 bytes of DATA  memory (+ 20 absolute )
   3 bytes of CONST memory

Errors: none
Warnings: none

Geht doch!

[Daniel V. (danvet)]

Dominik R. schrieb:
> Ich verstehe nicht wirklich, wann der Compiler ggf. eine Variable
> wegoptimiert und diese somit als volatile gekennzeichnet werden muss...

Der Compiler wird nur Variablen "wegoptimieren", die nicht verwendet 
werden.

Hier aber wird er optimieren (nicht "wegoptimieren"):

Johann L. schrieb:
> if(messwert < 0){
>           ledStatus = 1;
>         }
>         else if((messwert > 0) && (messwert < wert10)){
>           ledStatus = 2;
>         }
>         else if((messwert > wert10) && (messwert < wert90)){
>           ledStatus = 3;
>         }
>         else if((messwert > wert90) && (messwert < tarawert)){
>           ledStatus = 4;
>         }
>         else if(messwert < tarawert){
>           ledStatus = 5;
>         }

"messwert" wird EINMAL in ein Register eingelesen und dann wird mit dem 
Register gerechnet.
Falls du "messwert" als volatile definiert hast, wird der Compiler 
"messwert" bei jedem Vergleich neu in ein Register lesen. Das macht die 
Kiste langsamer und den Code grösser.

Falls sich "messwert" während diesem Vergleich ändern kann (z.B. wenn 
die Variable in einem Interrupt verändert wird) UND du möchtest, dass 
immer mit dem aktuellen Wert gerechnet wird, dann ist "volatile" 
angesagt.
Ansosnten kannst du dir "volatile" sparen.

[Purzel H. (hacky)]

>Ja, stimmt schon.Ich bin mir halt unsicher, wann der Compiler vielleicht
wichtige Dinge "wegoptimiert"...

Sowas gibt es gar nicht, resp darf es nicht geben. Das ist das 
Wichtigste. Man muss sich drauf verlassen koennen, dass das geschieht, 
was man will. Deswegen ist Debuggen auch Teil des Entwicklungsprozesses, 
und nicht etwas Unerwuenschtes, das man leider nachher noch anfuegen 
muss.

[Dominik R. (vision)]

Hallo nochmal,

ich habe es leider immer noch nicht geschafft, das Programm so weit zu 
verkleinern, dass es in den uC-Speicher passt.

Auch diese Aussage hilft nicht wirklich weiter:

ich kann lesen schrieb:
> Jetzt habe ich zum Spaß das Programm unverändert mit den
> Standardeinstellungen MAKEn lassen und 984 bytes of CODE  memory
>   62 bytes of DATA  memory (+ 20 absolute )
>    3 bytes of CONST memory
>
> Errors: none
> Warnings: none
>
> Geht doch!

984+62+3 = 1049 Bytes => zu groß für den 992 Byte großen Speicher (oder 
wird DATA und CONST nicht im Flash abgelegt?)

Vielleicht kannst du mir auch noch sagen, was du für ein Compiler 
benutzt hast, denn wenn ich den Code mit CCS 5.5 und den 
Standardeinstellungen kompiliere, ist das Programm doch noch etwas 
größer.

Ich habe den Code noch weiter bearbeitet, so dass ich mit meinen 
Einstellungen auf 1060 Byte komme. So sind es aber leider immer noch 68 
Byte zuviel. Ich habe den aktuellen Stant noch einmal angehängt. Gibt es 
noch weiteres Einsparungspotential?

Da ich noch nicht so lange in C und mit Mikrocontrollern arbeite, würde 
ich auch gerne wissen, was strukturell vielleicht noch verbessert werden 
könnte. Ja, ich weiss, dass man von Interrupt-Routinen aus keine 
Methoden aufrufen sollte, schon gar nicht mit Delays, aber wenn ein 
Interrupt verschluckt wird, ist das hier nicht sooo tragisch. Außerdem 
weiss ich nicht, wie ich es besser machen sollte. Ist es ok, erst das 
Flag zu clearen und dann eine Methode aus der ISR heraus aufzurufen?

Was mir an meinem Code gar nicht gefällt ist diese if ... 3x else if ... 
else Katastrophe, aber ich habe auch keine Idee, wie ich das eleganter 
lösen sollte...

Danke schonmal.

[Hans Klein (Gast)]

Dominik R. schrieb:
> Was mir an meinem Code gar nicht gefällt ist diese if ... 3x else if ...
> else Katastrophe, aber ich habe auch keine Idee, wie ich das eleganter
> lösen sollte...

Das ist nun wirklich das allerkleinste Problem an dem Code ...

Ganz ernst gemeinter Rat: Lösch den Murks und schreib es nochmal. Nimm 
es auch nicht als Vorlage für ein neues Programm. Fang nochmal mit einer 
leeren Datei an und schreib es ohne Interrupts und volatile, einfach 
geradeaus mit Polling. Danach ist das Programm nur noch halb so groß, 
verständlich und funktioniert auch sauber.

[Amateur (Gast)]

Der Gedanke das obige Programm ins Flash zu bekommen, wo scheinbar nur 
noch so wenig "abzuschneiden" ist, ist aus sportlicher Sicht bestimmt 
reizvoll.
Bedenke aber bitte folgendes:
- Durch trickreiche Konstrukte kann man einiges an Speicher sparen,
  aber die Wartbarkeit auf null drücken.
- Bist Du Dir 100% sicher, das, kaum dass es passt, nicht noch
  irgendwas nachgerüstet werden muss? Dann landest Du nämlich auf
  direktem Weg in der Abteilung: "Typischer Fall von Denkste". Die
  liegt übrigens gleich neben der Abteilung: "Außer Spesen nix
  gewesen".

[Dominik R. (vision)]

Ganz ohne Interrupts wird es nicht gehen, da sich der uC im LPM befinden 
soll, wenn gerade nich gemessen wird. Ich hab da keinen Schimmer, wie 
ich das umsetzen sollte.

Und nur, damit ich es das nächste Mal besser machen kann - was ist denn 
besonderer Murks (mal abgesehen von den Delays, die aus den ISR 
aufgerufen werden)? - vielleicht habe ich die rosarote Brille auf oder 
noch zu wenig Plan von C, aber ist es echt soo schlimm?

[ich kann lesen (Gast)]

Dominik R. schrieb:
> wird DATA und CONST nicht im Flash abgelegt?

Richtig, DATA ist RAM.

Das Ganze wurde mit dem IAR erstellt. Aber auch das hilft dir nicht. Das 
Programm ist bestimmt noch nicht fertig, du brauchst mehr Speicher.

Dominik R. schrieb:
> Gibt es
> noch weiteres Einsparungspotential?

Sind die ganzen delays nötig? In einer ISR wird 5s gewartet!
Da würde ich dringend den Ablauf und die Struktur überdenken.

[Dominik R. (vision)]

ich kann lesen schrieb:
> In einer ISR wird 5s gewartet!

Die LED soll 5s leuchten, bevor der Wert gespeichert wird. Und da in der 
Zeit weder auf Taster noch auf Timer reagiert werden soll, dachte ich, 
das das Delay in der ISR ok ist.

Aber wenn das Programm auf biegen und brechen nicht in den uC passt, 
hilft das alles nichts...

[holger (Gast)]

>Gibt es noch weiteres Einsparungspotential?

Ja, gibt es. Mach keine Berechnungen oder Vergleiche
mit volatile Variablen. Vermeide überflüssige Berechnungen.

  uint16_t tmptara = tarawert;
  uint16_t tmpnullwert = nullwert;

  uint16_t wert10 = (tmptara-tmpnullwert)/10;      // wert10 = Schwelle 1 (10% Tara)
   uint16_t wert90 = ((tmptara-tmpnullwert)*9)/10;    // wert90 = Schwelle 2 (90% Tara)

  for(m=60; m > 0; m--)
  {                  // 15 Sek. messen (alle 1/4 Sek.)
    int16_t messwert = messung(2)-tmptara;
    P1OUT |= LED_GREEN + LED_YELLOW + LED_RED;      // alle LEDs aus
    if(messwert < 0)
    {
      if(++b == 2)
      {                  // bei jedem 2. Durchlauf LED an (blinken)
        P1OUT &= ~LED_GREEN;
        b = 0;
      }
    }
    else if(messwert < wert10)
    {
      P1OUT &= ~LED_GREEN;
    }
    else if(messwert < wert90)
    {
      P1OUT &= ~LED_YELLOW;
    }
    else if(messwert < tmptara)
    {
      P1OUT &= ~LED_RED;
    }
    else if(messwert > tmptara)
    {
      if(++b == 2)
      {
        P1OUT &= ~LED_RED;              // bei jedem 2. Durchlauf LED an (blinken)
        b = 0;
      }
    }
    else
    {
      P1OUT |= LED_GREEN + LED_YELLOW + LED_RED;
    }
    delay_ms(250);
  }

[Dominik R. (vision)]

Danke für den Hinweis. Natürlich muss wert10 und wert90 nicht 60 mal 
berechnet werden. Hätte ich auch früher mal sehen können.

Hat 8 Byte gebracht. Bleiben leider immer noch 60 über. Ich denke, das 
wird nichts mehr.

Ist volatile bei den beiden Variablen überhaupt notwendig? Ich bin mir 
da nicht so ganz sicher. Normalerweise muss man ja volatile deklarieren, 
wenn sich der Wert einer Variablen während der Verarbeitung durch eine 
andere ISR ändern könnte, oder? Aber eigentlich kann / soll sich der 
Wert der beiden Variablen an der Stelle der Berechnung gar nicht ändern. 
Also ist Volatile hier notwendig?

[Hans Klein (Gast)]

Dominik R. schrieb:
> Ganz ohne Interrupts wird es nicht gehen, da sich der uC im LPM
> befinden
> soll, wenn gerade nich gemessen wird. Ich hab da keinen Schimmer, wie
> ich das umsetzen sollte.

Ich kenne den Controller nicht, aber es sollte doch ausreichen, wenn er 
per Interrupt geweckt wird und dadurch wieder in die Hauptschleife 
springt? Der Interrupt selber muss dann gar nichts machen.

> Und nur, damit ich es das nächste Mal besser machen kann - was ist denn
> besonderer Murks (mal abgesehen von den Delays, die aus den ISR
> aufgerufen werden)? - vielleicht habe ich die rosarote Brille auf oder
> noch zu wenig Plan von C, aber ist es echt soo schlimm?

Äußerlich:
- Unsaubere Codeformatierung (fehlende Leerzeichen vor Klammern und 
teilweise in Ausdrücken)
- Unheitliche Bezeichner (timerCount, daycount), Deutsch und Englisch 
gemischt
- Unklare Bezeichner (interval15, praktisch alle Funktionsnamen)

Technisch:
- Kein static vor den Hilfsfunktionen (hier: alle außer main) und den 
Modulvariablen (hier: alle globalen Variablen). Alleine das könnte schon 
zur Größenreduktion reichen.
- Globale Variablen statt lokale (statische) Variablen. Z.B. wird 
timerCount nur in der ISR Timer_A benutzt, würde also als 
static-Variable in diese Funktion gehören.
- Unsinnige volatiles. Wie gesagt, ohne Interrupts bräuchte man 
überhaupt keine. Falls man eine volatile-Variable in einer Funktion mehr 
als einmal benutzt, lohnt es sich, sie in eine lokale Variable 
umzukopieren und nur mit der lokalen Variable zu arbeiten. Das kann der 
Compiler dann optimieren.
- Unklarer Programmfluss durch willkürliche Funktionen mit unklaren 
Namen. Normalerweise sollte alleine durch den Prototyp einer Funktion 
(Name, Rückgabewert, Parameter) klar sein, was sie tut und möglichst 
keine globalen Variablen verändern. Bei der Funktion "void 
dauerMessung(void)" ist exakt das Gegenteil der Fall ...

Ich weiß, gerade letzteres ist als Anfänger nicht so einfach zu 
erreichen, dazu braucht man Erfahrung. Bevor man aber willkürlich 
irgendwelche Funktionen definiert, halte ich es dann immer noch für 
besser, zunächst mal den kompletten Kontrollfluss in eine Funktion zu 
packen und die einzelnen Abschnitte sinnvoll zu kommentieren.

Wenn man darin dann einen Teil erkennt, der eine in sich geschlossene 
Funktionalität darstellt, am besten mit wenigen Eingabeparametern, ohne 
Nebenwirkungen und mit einem Ergebnis, das man zurückgeben kann, dann 
macht man daraus eine Funktion. Deren Name sollte mit einem Verb 
beginnen und genau das beschreiben was sie tut. Und sie darf dann auch 
nur genau das machen und nichts anderes. Nur so erhält man sinnvolle 
Funktionen, die beim Verständnis des Codes helfen.

Zuletzt dann noch die Delays ... Die will man eigentlich auch nicht 
haben, schon gar nicht im Interrupt. In einem einfachen Programm, das 
sonst nichts machen muss, als eine lineare Befehlsfolge abarbeiten, sind 
sie aber OK. Nur dann wie gesagt bitte keine Interrupts, das passt 
schlichtweg nicht zusammen.

[Dominik R. (vision)]

Danke für die Hinweise. Ich werde die Ratschläge beherzigen und noch 
einmal versuchen, eine Poll-Version zu machen, die dann evtl. auch etwas 
kleiner ausfällt.

Ich wünsche noch eine gute Nacht.

[Martin H. (disjunction)]

Probier mal statt
X &= ~BUTTON_T;

X &= ~(unsigned char) BUTTON_T

Das ergibt bei manchen Prozessorn aus einer "Oder" Operation eine 
Bitoperation

[Optimist (Gast)]

Martin H. schrieb:
> Probier mal statt
...

Das sollte ein guter Compiler von selbst erkennen und optimieren.

[Martin H. (disjunction)]

Dann frage ich mich, warum moderne Kompiller wie Keil für ihre 
Konstanten stets Typen für ihre Konstanten angeben.

// Flash Control Register definitions
#define FLASH_PG                ((unsigned int)0x00000001)
#define FLASH_SER               ((unsigned int)0x00000002)

Mein Tip war also vieleicht nicht hifreich, aber sicherlich nicht 
unnötig.

[Optimist (Gast)]

Martin H. schrieb:
> für ihre
> Konstanten stets Typen für ihre Konstanten angeben

???

Martin H. schrieb:
> sicherlich nicht
> unnötig

Wo besteht der Zusammanhang mit Konstanten?
Oder meinst du, dass daraus durch den Cast eine Variable wird? ;-)))