www.mikrocontroller.net

Forum: Compiler & IDEs Compilerfehler Programm springt aus der Initialisierung zum Start zurück


Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich arbeite an einer USB Kommunikation für einen AT90USB162 mit dem LUFA 
USB Stack. Nachdem ich den Datenempfang überarbeitet habe, ist das 
Programm nach der USB Initialisierung immer wieder zum Start zurück 
gesprungen, anstatt zur naechsten Zeile nach dem Initialisierungsaufruf. 
Woran kann das liegen?

mfg
Bernhart

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmfehler in deinem Code. Z.B. Returnadresse am Stack 
überschrieben, Watchdog ausgelöst, ...

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das die Returnadresse am Stack überschrieben wird habe ich mir auch 
schon gedacht, das seltsame ist ja nur, dass der veraenderte code nichts 
mit der initialisierung zu tun hat.

der watchdog in der main-Routine vor dem Aufruf der USB initialisierung 
deaktiviert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Typischer Weise durch Aufruf des BADISR_vect Handlers.


Peter

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe dafür eigentlich keine isr geschrieben, aber im lufa stack 
könnte da etwas enthalten sein. wie kann ich den tatsaechlichen fehler 
denn finden?

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem werden die Interrupts erst nach der Initialiserung der Hardware 
mit
sei();
 aktiviert.

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

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht deine Memory Statisctic aus?
Wieviele SRAM hast du laut Compiler bisher verbraucht?

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
82,3% des SRAM sind verbraucht.

Wie groß ist denn der Stack der die Rückkehradressen speichert? Ich 
liege doch richtig, dass das ein FILA Speicher ist? Also wie ein Stapel 
Teller. Ein Stack halt. Dabei würde die 9 Rückkehradresse bei 8 
Speicherplaetzen verworfen werden.

Seltsamerweise kehrt das Programm bis zur ersten Aufgerufenen Subroutine 
zurück. Dann faengt der µC von vorne an anstatt zur letzten 
Absprungadresse zu gehen.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist gerade die Idee gekommen im Hauptprogramm ein Label MAIN 
einzufügen und dann aus der Subroutine am Ende der Subroutine ein goto 
MAIN einzufügen, aber das wird vom Compiler wegopimiert.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 82,3% des SRAM sind verbraucht.

Mach RAM frei. Und wenns nur vorübergehend zur Fehlerbestätigung ist.

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in wie fern soll das den Fehler beheben?

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab keine ahnung warum, aber jetzt springt das programm richtig.

kanns sein, dass der compiler durch die optimierung durcheinanderkommt 
wo der die variablen ablegt?

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> in wie fern soll das den Fehler beheben?

Du hast (bzw. hattest) höchstwahrscheinlich (jetzt praktisch bestätigt) 
einen Pufferüberlauf, im Speziellen eine Begegnung der dritten Art von 
Heap und Stack. Dadurch wird (wurde) vermutlich der "letzte" Stackframe 
beschädigt mit dem Ergebnis dass das return ins Nirvana springt.

80% belegter RAM sind definitiv zu viel, da hieße es höllisch aufpassen, 
was vor sich geht - und jedes Byte einzeln zählen. Deswegen vermeidet 
man das einfach B-)

Ergo: Schaufel mehr RAM frei, sonst gibts bald wieder einen Zusammenstoß 
- und der ist dann möglicherweise nicht so einfach zu finden.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhart schrieb:

> kanns sein, dass der compiler durch die optimierung durcheinanderkommt
> wo der die variablen ablegt?

Sorry, aber 99% aller postulierten Compilerfehler sitzen vor dem 
Bildschirm. Ja, es gibt sie und hier im Forum wurden auch schon welche 
gefunden. Aber ohne konkrete Anhaltspunkte den Compiler beschuldigen 
weil man selber nicht durchblickt, das ist nicht angebracht.

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Sorry, aber 99% aller postulierten Compilerfehler sitzen vor dem
> Bildschirm. Ja, es gibt sie und hier im Forum wurden auch schon welche
> gefunden. Aber ohne konkrete Anhaltspunkte den Compiler beschuldigen
> weil man selber nicht durchblickt, das ist nicht angebracht.

Tut mir leid, aber als C Programmierer der neu auf AVR ist darf ich wohl 
einen Fehler im Compiler annehmen. Da ist einem nicht von Anfang an klar 
das bei 80 % RAM Auslastung Fehler auftreten können.

Jedenfalls würde ich gerne wissen, wie ich den verfügbaren RAM ganz 
nutzen kann, bzw. mehr davon?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhart schrieb:

> Tut mir leid, aber als C Programmierer der neu auf AVR ist darf ich wohl
> einen Fehler im Compiler annehmen.

Gerade dann ist es besonders unwahrscheinlich, daß der Fehler beim 
Compiler zu suchen ist.

> Da ist einem nicht von Anfang an klar das bei 80 % RAM Auslastung Fehler
> auftreten können.
>
> Jedenfalls würde ich gerne wissen, wie ich den verfügbaren RAM ganz
> nutzen kann, bzw. mehr davon?

Du hast offensichtlich das Problem noch gar nicht verstanden.
Dein Programm verhält sich so komisch, weil du bereits mehr nutzt, als 
eigentlich vorhanden ist.

Bernhart schrieb:
> 82,3% des SRAM sind verbraucht.
>
> Wie groß ist denn der Stack der die Rückkehradressen speichert?

So groß wie nötig. Der Stack fängt defaultmäßig am Ende des RAM an und 
wächst dann nach unten, zur Not auch in den schon durch Variablen 
belegten Teil des RAM. Der speichert übrigens nicht nur 
Rücksprungadressen.

> Ich liege doch richtig, dass das ein FILA Speicher ist? Also wie ein
> Stapel Teller. Ein Stack halt.

Ähm, ja, der Stack ist ein Stack ;-)
"FILA" kenne ich aber nur als Turnschuh-Marke. Den Stack kenne ich als 
"LIFO" ("Last In, First Out).

> Dabei würde die 9 Rückkehradresse bei 8 Speicherplaetzen verworfen
> werden.

Es wird nichts verworfen. Bei einem Funktionsaufruf wird die 
Rücksprungadresse gespeichert, PUNKT.
Genauer: Die Adresse der nächsten Instruktion wird der Stelle im RAM 
gespeichert, auf die der Stackpointer zeigt. Dann wird der Stackpointer 
dekrementiert.

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

Bewertung
0 lesenswert
nicht lesenswert
Bernhart schrieb:
> Tut mir leid, aber als C Programmierer der neu auf AVR ist darf ich wohl
> einen Fehler im Compiler annehmen.

Nein.  Du darfst einen Fehler im Compiler annehmen, wenn du anhand
des generierten Assemblercodes nachgewiesen hast, dass es einer ist.
Bis du dazu in der Lage bist, gilt für den Compiler aus deiner Sicht
erst einmal durchweg die Unschuldsvermutung.

> Da ist einem nicht von Anfang an klar
> das bei 80 % RAM Auslastung Fehler auftreten können.

Das mit den 80 % ist auch nur 'ne Hausnummer.  Bei einem Controller
mit wenig RAM kann die Zahl noch darunter liegen, wenn du einen
ATmega1284 oder ATmega128RFA1 mit 16 KiB SRAM hast, kannst du
vermutlich problemlos weit über 90 % bereits statisch belegen, ohne
dass der Platz für den Stack zu knapp wird.

> Jedenfalls würde ich gerne wissen, wie ich den verfügbaren RAM ganz
> nutzen kann, bzw. mehr davon?

Du hast bereits mehr benutzt, als du RAM hast.  Neben dem statisch
belegten RAM benötigst du noch welchen für den Stack.  Das Unangenehme
am Stack aber ist, dass der sich einfach den Platz nimmt, den er
braucht, der fragt nicht, ob an dieser Stelle schon eine Variable
liegt (weil er es einfach nicht weiß).  Eine derartige Kollision lässt
sich nur auf größeren Maschinen erkennen, die eine Speicherverwaltung
in ihrer Hardware haben, aber derart kleine Controller haben das nicht.

Du musst also einfach mal analysieren, was bei dir übermäßig viel RAM
beansprucht, sowohl statisch (also bei den 83 %, die da angezeigt
werden) als auch auf dem Stack.  Die erste Vermutung wäre mal, dass
du einen Haufen string literals benutzt, die aufgrund der Harvard-
Architektur (und der vom Standard geforderten Kompatibilität eines
solchen string literals mit dem Typ "char *" und den entsprechenden
Funktionen wir strcpy() etc.) im RAM landen.  In jedem besseren AVR-
Tutorial wird dir erklärt, was man tun muss, um diese aus dem RAM
zu verbannen, sodass sie nur noch Flash-ROM benötigen (den sie jetzt
natürlich auch noch brauchen).

Autor: Bernhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein, ich verwende keinen einzigen String. ca 30 % des RAMs belegt der 
LUFA USB Stack. Die 5 % sind für einen 8 Bit 16 Kanal LED Dimmer und die 
restlichen 48 % waeren für automatisches Faden der LEDs in beliebiger 
Geschwindigkeit unabhaengig von einander. Aber das bedarf sowiso noch 
einiger Optimierungsarbeit. Der Fehler ist aufgetreten, als ich die 
Funktion von 1 LED auf alle 16 umgeschrieben habe. Diese LED Show 
befindet sich noch im Entwicklungsstadium und ist erst zu 70% fertig.

Als Controller verwende ich den AT90USB162 mit 512 Byte RAM.

Wie groß ist denn in der Regel der Stack? in welchem Speicherbereich des 
RAMs befindet der sich für gewöhnlich?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhart schrieb:
> Wie groß ist denn in der Regel der Stack?

Bei AVR:
Der Rest, der nicht für statische Variablen
(globale + lokale static) genutzt wird - gemeinsam mit dem Heap.

Bei PCs: je nach OS.

Wieviel Stack dein Programm benötigt, hat damit erstmal
gar nichts zu tun.

Wenn es funktionieren soll, muß der benötigte Stack kleiner sein
als der vorhandene.

> in welchem Speicherbereich des
> RAMs befindet der sich für gewöhnlich?

Oben im freien Rest.

Autor: Philipp Kälin (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde dir empfehlen den folgenden Artikel hier durchzulesen: 
http://www.rn-wissen.de/index.php/Speicherverbrauc...
zur Not auch zweimal. Du kannst dein Problem nicht lösen, solange du 
nicht genau darüber bescheid weisst.
Ich habe bei einem Ähnlichen Problem mit einem Timer-Interrupt den 
verfügbaren Speicher periodisch abgefragt und auf RS232 ausgegeben, dann 
einfach mal rumgespielt, und geschaut wieviel Speicher noch frei ist.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhart schrieb:
> Wie groß ist denn in der Regel der Stack? in welchem Speicherbereich des
> RAMs befindet der sich für gewöhnlich?

Die Mühe, dir das zu erklären, habe ich mir nicht gemacht, damit du es 
nicht liest.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
haben Atmel 8 bitr µCs nicht eine Stack irgenwo auf der Hardware wie 
manche PICs?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja klar.
Im RAM.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die AVRs, die kein RAM haben, also der ATtiny11.
Alle anderen AVRs haben den Stack im RAM.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie groß ist denn Dein data-Bereich?  Dort befindet sich das größte 
Einsparpotenzial, üblicherweise in Form initialisierter Variablen, die 
nie geändert werden, sondern konstant sind.

Bernhart schrieb:
> Tut mir leid, aber als C Programmierer der neu auf AVR ist darf ich wohl
> einen Fehler im Compiler annehmen.

Annehmen darfst Du alles; ausgeschlossen ist es ja nicht. 
Veröffentlichen wird es nur ein C-Programmierer, der eher nicht nur bei 
AVRs Anfänger ist.  Das Netz ist voll von Compilerfehlern, bei denen die 
Fehlerursache zwischen Tastatur und Rückenlehne zu finden war (zu ca. 
99,9%).  Nach einiger Zeit lokalisiert man die Fehlerquelle von selbst 
dort und sieht das als normalen Teil des Debugging.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hc Zimmerer schrieb:
> Annehmen darfst Du alles; ausgeschlossen ist es ja nicht.
> Veröffentlichen wird es nur ein C-Programmierer, der eher nicht nur bei
> AVRs Anfänger ist.  Das Netz ist voll von Compilerfehlern, bei denen die
> Fehlerursache zwischen Tastatur und Rückenlehne zu finden war (zu ca.
> 99,9%).  Nach einiger Zeit lokalisiert man die Fehlerquelle von selbst
> dort und sieht das als normalen Teil des Debugging.

Am Anfang habe ich auch einen Fehlervon mir vermutet, aber als ich den 
Assamblercode gesehen habe, habe ich gewusst, dass der Fehler nicht 
direkt dem Codestück kommt, bei dem er Auftritt. Bei der Programmierung 
auf Betriebssystem Basis muss man sich über so etwas ja eher wenig 
gedanken machen.

Aber dass 20 % des RAMs für den Stack und den HEAP drauf gehen finde ich 
schon eher viel. Das Meiste wird vermutlich eh der Heap verbrauchen.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber dass 20 % des RAMs für den Stack und den HEAP drauf gehen finde ich
> schon eher viel.

Das sind ca. 100 Bytes.

> Das Meiste wird vermutlich eh der Heap verbrauchen.

Kannst du auf dynamischen Speicher nicht verzichten?

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Rolf Magnus:
Danke für die Info, das 20% von 512 ca. 100 ist haette ich mir nicht 
denken können.

Ich brauche für meinen Code gar keinen dynamischen Speicher. Ich 
vermute, dass der LUFA USB Stack aber etwas brauchen könnte.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
juchu, was täten wir nur ohne die ganzen Anfänger, die die vielen Bugs 
in den Compilern finden!?! Nicht auszudenken, wenn die alle unentdeckt 
blieben, weil nur Profis den Compiler benutzten...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
delicious_cake schrieb:
> Danke für die Info, das 20% von 512 ca. 100 ist haette ich mir nicht
> denken können.

Wenn man aus der PC-Ecke kommt, wo der Speicher typischerweise mehrere 
Millionen Mal so groß ist, denkt man evtl. in anderen Dimensionen. Ich 
wollte nur sicher sein, daß dir bewußt ist, wie viel diese 20% 
eigentlich sind.

> Ich brauche für meinen Code gar keinen dynamischen Speicher. Ich
> vermute, dass der LUFA USB Stack aber etwas brauchen könnte.

Das sollte sich ja einfach rausfinden lassen. Für den Stack alleine 
wären 20% schon sehr viel, außer wenn du sehr tiefe Aufrufhierarchien 
oder viele lokale Variablen hast. Ungünstig implementierte ISRs können 
auch viel Stack brauchen.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hc Zimmerer schrieb:
> Wie groß ist denn Dein data-Bereich?

der Databereich hat 43% Auslastung. Es sollen aber noch einige 
funktionen dazu kommen. Kanns durch eine hohe Auslastung des Data 
Bereichs auch zu Problemen kommen?

Autor: Tom M. (tomm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Das sollte sich ja einfach rausfinden lassen. Für den Stack alleine
> wären 20% schon sehr viel, außer wenn du sehr tiefe Aufrufhierarchien
> oder viele lokale Variablen hast. Ungünstig implementierte ISRs können
> auch viel Stack brauchen.

Wenn ich mich richtig erinnere, sichert avr-gcc bei einem ISR Aufruf 
sämtliche Register auf dem Stack, dazu noch das Statusregister. 
Ausserdem liegt die Rücksprungadresse noch drauf, ich komme auf 35 
Bytes.

Vlt. verwendest du auch nested interrupts, z.B. weil das Abholen eines 
empfangenen Byte sehr zeitkritisch ist? Würde zwar nicht vermuten, dass 
das beim Initialisieren der LUFA Bibliothek zuschlägt... Oder doch?

Verwendest du das avr-gcc/avr-libc Gespann?

> der Databereich hat 43% Auslastung. Es sollen aber noch einige
> funktionen dazu kommen. Kanns durch eine hohe Auslastung des Data
> Bereichs auch zu Problemen kommen?

Nö. Program Memory und RAM sind komplett getrennte Adressräume.

Wie andere schon erwähnt haben: Kannst du mehr RAM freischaufeln, indem 
du strings in das flash memory verschiebst? Das avr-libc Manual enthält 
ein Kapitel eigens über dieses Thema, RTFM. :)

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

Bewertung
0 lesenswert
nicht lesenswert
Tom M. schrieb:
> Wenn ich mich richtig erinnere, sichert avr-gcc bei einem ISR Aufruf
> sämtliche Register auf dem Stack, dazu noch das Statusregister.

Nein, er sichert erst einmal nur die, die von der ISR zerstört
werden.  Wenn allerdings in der ISR noch externe Funktionen gerufen
werden, sichert der Compiler alle die Register, die laut ABI von
den gerufenen Funktionen zerstört werden dürfen (und wenn diese
Funktionen noch weitere Register brauchen, die sie laut ABI nicht
zerstören dürfen, dann sichern sie diese Register selbst nochmal).

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom M. schrieb:
>> der Databereich hat 43% Auslastung. Es sollen aber noch einige
>> funktionen dazu kommen. Kanns durch eine hohe Auslastung des Data
>> Bereichs auch zu Problemen kommen?
>
> Nö. Program Memory und RAM sind komplett getrennte Adressräume.

Doch.  Es geht um Data.  Dieser Bereich wird beim Programmstart vom 
Flash ins SRam kopiert, ist also ein Adressraum, der von keinem von 
beidem getrennt ist.

An den TE:  Hast Du denn initialisierte Variable, die sich nie ändern 
(Beispiel wäre ein Array aus konstanten Werten)?  43% Data ist nicht 
wenig, frisst viel SRam und legt den Verdacht nahe, dass es sich um 
solche Konstanten handelt.

Falls ja, freunde Dich mal mit <avr/pgmspace.h> an.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hc Zimmerer schrieb:
> An den TE:  Hast Du denn initialisierte Variable, die sich nie ändern
> (Beispiel wäre ein Array aus konstanten Werten)?  43% Data ist nicht
> wenig, frisst viel SRam und legt den Verdacht nahe, dass es sich um
> solche Konstanten handelt.
>
> Falls ja, freunde Dich mal mit <avr/pgmspace.h> an.


alle Konstanten sind bei mir von Anfang an als defines implementiert. 
Und der PWM Table zum LED Faden efindet sich ebenfalls von Anfang an im 
Flash memory.

Wie ich die Größe des Data-Bereichs verringern kann, habe ich mir noch 
nicht überlegt. Aber mir ist eingefallen, dass für jede einzelne Bool 
Variable ein ganzes Byte verbraucht wird. Wenn ich die Bool Variablen zu 
wirklichen Bools umschreibe die nur mehr true und false sein können, 
spare ich bestimmt an die 100 Byte Sram ein.

Wie ich das umsetzen kann weiß ich bereits. Dann habe ich aber immer nur 
8 Variablen pro Byte. Hat jemand vielleicht schon einen Vorschlag wie 
ich das Umsetzen kann, dass eine beliebige Anzahl an Bools in einer 
Variable steht die wie ein Array ansprechbar ist. Ich arbeite mit sehr 
vielen solcher Arrays und die beliebige Definition der Größe waere sehr 
angenehm. Ich habe an eine unitxx_t Variable gedacht, bei der man die 
Größe selbst festlegen kann. Halt leider nur bis 64. Ich haette es aber 
gerne bis 256.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: diese Bool implementierung sollte natürlich auch möglichst schnell 
arbeiten.

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

Bewertung
0 lesenswert
nicht lesenswert
delicious_cake schrieb:

> Wie ich das umsetzen kann weiß ich bereits. Dann habe ich aber immer nur
> 8 Variablen pro Byte.

Mehr wirst du auch nicht hinkriegen.
Dein ein Byte hat nun mal nicht mehr als 8 Bit.

> Hat jemand vielleicht schon einen Vorschlag wie
> ich das Umsetzen kann, dass eine beliebige Anzahl an Bools in einer
> Variable steht die wie ein Array ansprechbar ist.

Musst du dir selber schreiben.
So schwer ist das nicht.

Du hast 185 Mieter, die in einer Strasse wohnen und jeder Mieter hat 
eine Nummer.
Jeweils 8 Mieter wohnen in einem Haus. Die Häuser sind durchnummeriert 
und die Mieter in einem Haus sind ebenfalls durchnummerert.

Wenn du etwas vom Mieter 89 willst:
* In welchem Haus wohnt er?
* Wie ist die Nummer des Mieters innerhalb des Hauses?


Division (/) und Rest einer Division (%) sind deine Freunde.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl heinz Buchegger:

Danke. Das Beispiel ist nicht schlecht gewaehlt.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
delicious_cake schrieb:
> Aber mir ist eingefallen, dass für jede einzelne Bool
> Variable ein ganzes Byte verbraucht wird. Wenn ich die Bool Variablen zu
> wirklichen Bools umschreibe die nur mehr true und false sein können,
> spare ich bestimmt an die 100 Byte Sram ein.

Hast du wirklich über 100 bool-Variablen in deinem Programm, die 
gleichzeitig im Ram existieren müssen?

delicious_cake schrieb:
> alle Konstanten sind bei mir von Anfang an als defines implementiert.
> Und der PWM Table zum LED Faden efindet sich ebenfalls von Anfang an im
> Flash memory.

Kannst du mal zeigen, wie deine defines sicherstellen, daß da keine 
Konstanten im Ram liegen, und den Codeteil mit der PWM-Tabelle im Flash?

Oliver

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Hast du wirklich über 100 bool-Variablen in deinem Programm, die
> gleichzeitig im Ram existieren müssen?

wo sollen die bools denn sonst liegen? eine aendert den zustand z.B. mit 
31,25 Hz. wenn ich die im eeprom ablege oder im flash dann bin ich 
ziehmlich schnell bei 100.000 (eeprom) bzw. 10.000 (flash) schreibzyklen 
angekommen. und dann geht nix mehr auf der adresse. die anderen andern 
sich höchsten jede sekunde einmal.

Oliver schrieb:
> Kannst du mal zeigen, wie deine defines sicherstellen, daß da keine
> Konstanten im Ram liegen, und den Codeteil mit der PWM-Tabelle im Flash?
//selbsterstellter PWM Tabelle
uint8_t pwm_time[256]   PROGMEM =

{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,
3,3,4,4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,
5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,8,
8,8,8,8,8,9,9,9,9,9,10,10,10,10,10,11,
11,11,11,12,12,12,12,13,13,13,14,14,14,
14,15,15,15,16,16,17,17,17,18,18,18,19,
19,20,20,21,21,21,22,22,23,23,24,24,25,
26,26,27,27,28,28,29,30,30,31,32,32,33,
34,35,35,36,37,38,39,39,40,41,42,43,44,
45,46,47,48,49,50,51,52,53,55,56,57,58,
60,61,62,64,65,66,68,69,71,72,74,76,77,
79,81,83,84,86,88,90,92,94,96,98,100,103,
105,107,109,112,114,117,119,122,125,127,
130,133,136,139,142,145,148,152,155,158,
162,165,169,173,177,180,184,189,193,197,
201,206,210,215,219,224,229,234,239,245,250,255};

#define EE_LED_VALUE_ADDR      100 // eeprom byte address where the brightness-settings will be saved
#define EE_FADE_TIME           100+PWM_CHANNELS // eeprom byte address where the settings will be saved

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

Bewertung
0 lesenswert
nicht lesenswert
OK.
Um LUFA USB-Stack wirst du jetzt nichts ändern können.
Der wird auch ein paar Bytes für Zwischenpuffer benötigen, etc.

Wenn du nur den USB-Stack mit an Bord hast, wieviel SRAM hast du dann 
nocht frei.

Ich kann mir nämlich ehrlich gesagt auch nicht vorstellen, wo man bei 
der Aufgabenstellung "16 LED unabhängig voneinander faden" so dermassen 
viele boolsche Variablen braucht. Was  um Himmels willen treibst du da?

42% von 512 Bytes sind immerhin 220 Bytes. Und das für 16 popelige LED?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
delicious_cake schrieb:
> Oliver schrieb:
>> Hast du wirklich über 100 bool-Variablen in deinem Programm, die
>> gleichzeitig im Ram existieren müssen?
>
> wo sollen die bools denn sonst liegen?

Lol.. die Antwort klingt etwa wie:

"Hast du wirklich einen Elefanten in deiner Garage?"
"Ja natürlich. Wo soll ich den denn sonst lassen?"

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> 42% von 512 Bytes sind immerhin 220 Bytes. Und das für 16 popelige LED?

ich weiß nicht wie oft ich schon gesagt habe, dass noch nicht fertig 
bin. erst kommen alle funktionen rein, dann wird optimiert. und wenn 
zwischen drin ein Fehler auftauch wird der gleich behoben. Nur mit dem 
RAM Problem habe ich nicht so schnell gerechnet. Jetzt muss ich halt 
schon vorher etwas aufraeumen.

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

Bewertung
0 lesenswert
nicht lesenswert
delicious_cake schrieb:
> Jetzt muss ich halt
> schon vorher etwas aufraeumen.

Oder zum Entwickeln einen größeren Controller nehmen.  Wenn du den
ältlichen ATmega8 durch den moderneren ATmega88 ablöst, kannst du
nach oben mittlerweile bis zu einem ATmega328 gehen, der dann auch
2 KiB SRAM hat.

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

Bewertung
0 lesenswert
nicht lesenswert
delicious_cake schrieb:
> Karl heinz Buchegger schrieb:
>> 42% von 512 Bytes sind immerhin 220 Bytes. Und das für 16 popelige LED?
>
> ich weiß nicht wie oft ich schon gesagt habe, dass noch nicht fertig
> bin.

Dann ist es doch noch schlimmer!

Verstehst du das nicht?
Du musst dir schon auch jetzt ein wenig Gedanken darüber machen, wieviel 
Speicher du wofür benötigen darfst und wenn du über dem Limit bist, 
musst du frühzeitig reagieren.

> erst kommen alle funktionen rein, dann wird optimiert.

In deinem Fall gehts noch gar nicht um Optimieren im klassischen Sinne. 
Es geht schlicht und ergreifend darum, dass du (anscheinend) durch dein 
sorgloses Vorgehen schon jetzt deine vorhandenen Resourcen 
überschreitest. Und da muss die Frage gestattet sein, wofür für jede LED 
ca 13 Bytes an FadingInfo benötigt werden.

Wer umzieht muss sich im Vorfeld schon ein wenig Gedanken darüber 
machen, wie er sein Hab und Gut transportieren will. Macht er das erst 
am Tag des Umzugs, wenn seine Kumpel schon bereit stehen, dann muss er 
sich gefallen lassen, sich nicht ausreichend vorbereitet zu haben.

Sich hinzustellen und zu sagen: Ich hab zwar Schwierigkeiten mit meiner 
Couch, aber macht ja nichts, bin ja noch nicht fertig, kommt ja eh noch 
die Küche dazu, das ist der falsche Weg. Die Probleme werden nicht 
kleiner, wenn man noch mehr Funktionalität draufpackt.

Wenn ich mich aber so dunkel an einen anderen Thread von dir erinnere, 
denn vermute ich mal, dass von den 13 Bytes ein nicht unerheblicher Teil 
für 2 oder 3 float Variablen drauf geht.

Autor: delicious_cake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl heinz Buchegger:

das ist mir alles klar. deshalb bringe ich jetzt ja alles in ordnung 
bevor ich mich an weiter sachen wage. Dass mir der Speicher ausgehen 
könnte, wenn die fading funktion so wie sie ist/war fertig ist, dessen 
war ich mir bewusst. Aber von 80% RAM "Grenze" konnte ich doch nichts 
ahnen, wenn man mit so etwas noch nie zu tun hatte. immoment ist das 
faden so aufgebaut, dass sie für bis zu 64 LEDs verwendet werden kann. 
mein µC hat halt nur nicht so viele IOs und ich verwende sie für 16. So 
sehe ich einerseits was ich verbessern muss und andererseits lerne ich 
probleme zu beheben.

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.