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
Programmfehler in deinem Code. Z.B. Returnadresse am Stack überschrieben, Watchdog ausgelöst, ...
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.
Typischer Weise durch Aufruf des BADISR_vect Handlers. Peter
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?
Außerdem werden die Interrupts erst nach der Initialiserung der Hardware mit
1 | sei(); |
aktiviert.
Wie sieht deine Memory Statisctic aus? Wieviele SRAM hast du laut Compiler bisher verbraucht?
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.
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.
> 82,3% des SRAM sind verbraucht.
Mach RAM frei. Und wenns nur vorübergehend zur Fehlerbestätigung ist.
in wie fern soll das den Fehler beheben?
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?
> 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.
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.
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?
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.
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).
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?
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.
Ich würde dir empfehlen den folgenden Artikel hier durchzulesen: http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc 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.
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.
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.
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.
> 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?
@ 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.
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...
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.
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?
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. :)
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).
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.
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.
PS: diese Bool implementierung sollte natürlich auch möglichst schnell arbeiten.
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.
@ Karl heinz Buchegger: Danke. Das Beispiel ist nicht schlecht gewaehlt.
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
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?
1 | //selbsterstellter PWM Tabelle
|
2 | uint8_t pwm_time[256] PROGMEM = |
3 | |
4 | {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, |
5 | 1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2, |
6 | 2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3, |
7 | 3,3,4,4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5, |
8 | 5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,8, |
9 | 8,8,8,8,8,9,9,9,9,9,10,10,10,10,10,11, |
10 | 11,11,11,12,12,12,12,13,13,13,14,14,14, |
11 | 14,15,15,15,16,16,17,17,17,18,18,18,19, |
12 | 19,20,20,21,21,21,22,22,23,23,24,24,25, |
13 | 26,26,27,27,28,28,29,30,30,31,32,32,33, |
14 | 34,35,35,36,37,38,39,39,40,41,42,43,44, |
15 | 45,46,47,48,49,50,51,52,53,55,56,57,58, |
16 | 60,61,62,64,65,66,68,69,71,72,74,76,77, |
17 | 79,81,83,84,86,88,90,92,94,96,98,100,103, |
18 | 105,107,109,112,114,117,119,122,125,127, |
19 | 130,133,136,139,142,145,148,152,155,158, |
20 | 162,165,169,173,177,180,184,189,193,197, |
21 | 201,206,210,215,219,224,229,234,239,245,250,255}; |
22 | |
23 | #define EE_LED_VALUE_ADDR 100 // eeprom byte address where the brightness-settings will be saved
|
24 | #define EE_FADE_TIME 100+PWM_CHANNELS // eeprom byte address where the settings will be saved
|
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?
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?"
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.
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.
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.
@ 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.