Hallo zusammen! Ich wollte hier grad eine kleine Uhr für einen Tiny2313 programmieren. Das Programm hat ca. 30 einfache Zeilen Code. Beim kompilieren musste ich dann leider feststellen, das das Ding damit schon zu 200% gefüllt ist. Das hat mich dann schon etwas verwundert... Sind die 2k Speicher tatsächlich so wenig, dass da nur 2-Zeiler Programme draufpassen? PS: Als Optimierung habe ich Os gewählt, das sollte ja eigentlich kleinen Code produzieren, oder?
Boris B. schrieb: > PS: Als Optimierung habe ich Os gewählt, das sollte ja eigentlich > kleinen Code produzieren, oder? "0" ist gänzlich ohne Optimierung "s" sollte gute Ergebnisse liefern Gruß, Magnetus
Nabend, Dann zeig deinen 30 Zeiler mal her. MfG
Lass mir raten: Du hast die Gleitkommabibliotheken dazugelinkt.
Boris B. schrieb: > Ja, das habe ich ja eingestellt ;-) Boris B. schrieb: > PS: Als Optimierung habe ich Os gewählt, das sollte ja eigentlich ^^ Wat denn nun?
Zeig doch mal den Code, ich könnte mir vorstellen, dass du z.B. printf oder sprintf benutzt, die verbrauchen ziemlich viel Speicher. Floats könnten das ganze auch größer machen. Grundsätzlich liegts wahrscheinlich an irgendwelchen Libraries, die direkt oder indirekt eingebunden werden. Ich hab auf jeden Fall auf den verschiedenen tinys schon ein paar nützliche Programme hingekriegt, meistens mach ich mir mehr Sorgen ums RAM als ums Flash.
Genau: Hört sich an wie die Verwunderung desjenigen, der zwischen den Sätzen: "Eine Currywurstbude aufbauen und führen" und "Eine Hotelkette aufbauen und führen" intuitiv keinen Unterschied sieht und dem die Wort- und Satzzählung sagt, das beides im Grunde das selbe ist.
@Magnus Müller das ist ein O keine 0 -Os benutzt er, also Optimierung s, nicht -0s bzw. -O0s
schau mal, was da an Uhr alles drauf passt.... Beitrag "NIXIE Uhr mit vielen Funktionen in C mit ATTiny2313"
Wenn man in ASM Programiert, sind die 2 KBytes schon relativ viel. Auch in C kreigt man da auch schon einiges rein. Nur mit Fließkomma und Befehlen wie Printf wird es knapp. So ungewöhnlich ist es aber auch nicht, dass 2 kBytes nicht mehr reichen. Der Tiny2313 ist wegen der Position der Vcc7GND Pins ohnehin keine so gute Wahl. Von vielen anderen Typen gibt es Versionen mit verschieden viel Speicher, z.B. 2 4 8 kBytes. Wenn einem die 2 kB zu viel sind, gibt es auch noch den Tiny4 mit nur 512 Bytes Flash. Auch da kann einem noch die Hälfte frei bleiben.
Hi >Von vielen anderen Typen gibt es Versionen mit verschieden viel Speicher, >z.B. 2 4 8 kBytes. Wie wäre es mit dem ATTiny4313? MfG Spess
Hallo! Danke für das viele Feedback. Ein printf oder Fließkommazahlen habe ich eigentlich nicht verwendet... Der Code ist im Anhang.
Möööööp!!! Großer Fehler.
1 | // Wait micro (10^-6) seconds
|
2 | void Timing_wait_us( uint us ) |
3 | {
|
4 | _delay_us(us); |
5 | }
|
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 "Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt und die Wartezeiten stimmen nicht mehr mit dem Parameter überein. " MFG Falk
Yepp wenn das delay nicht fest vorgegeben wird, wird Fließkomma benötigt und das führt zu einem ziemlich erhöhten Speicherverbrauch. Englische beschreibung der verschiedenen avr header: http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html "In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application."
Nabend, Timing.c
1 | #include <avr/io.h> |
2 | #include <util/delay.h> |
3 | #include "Types.h" |
4 | #include "Timing.h" |
5 | |
6 | |
7 | // Wait micro (10^-6) seconds
|
8 | void Timing_wait_us( uint us ) |
9 | {
|
10 | _delay_us(us); |
11 | }
|
hier wird die Gleitkommabibliothek dazugelinkt. MfG
Ein möglicher, sehr ekliger Hack währe zum Beispiel:
1 | // Wait micro (10^-6) seconds
|
2 | void Timing_wait_us( uint us ) |
3 | {
|
4 | for(;us > 0; us--) { |
5 | _delay_us(1); |
6 | }
|
7 | }
|
allerdings wird das gerade bei hohen Wartezeiten länger dauern als geplant, da die For Schleife auch noch Zeit braucht.
Hier mal der Verbrauch meiner DCF77-Uhr:
1 | 4.3.3 |
2 | AVR Memory Usage |
3 | ---------------- |
4 | Device: attiny26 |
5 | |
6 | Program: 1056 bytes (51.6% Full) |
7 | (.text + .data + .bootloader) |
8 | |
9 | Data: 31 bytes (24.2% Full) |
10 | (.data + .bss + .noinit) |
Und der Code: Beitrag "DCF77 Uhr in C mit ATtiny26" Peter
@ Spess53
> Wie wäre es mit dem ATTiny4313?
sehr gerne - wo gibt's den zu kaufen?
AVRnewbie schrieb: > sehr gerne - wo gibt's den zu kaufen? http://de.mouser.com/ProductDetail/Atmel/ATTINY4313-SU/?qs=sGAEpiMZZMvu0Nwh4cA1wYucVmuEraaSDAW1Zl%2fco5M%3d
Hi http://www.brokerforum.com/components-parts/popular-electronic-parts-ATTINY4313-c-en.jsa MfG Spess
@ avr Spaßvogel... :-) Lagerbestand = 0 Die hatten noch nie ein Exemplar am Lager.
@ Spess53 Interessant und irgendwie doch wieder uninteressant. Ich habe es zur Kenntnis genommen. Es gibt sie also doch! :-) Hätte ich um 1999 gut gebrauchen können.
Wenn man nicht alle 18 IOs braucht, kann man die ATtiny261/461/861-er nehmen. Sind aber leider nicht pinkompatibel. Peter
Ich hab mir eben mal das Assembly File angeschaut. Geschätzte 70 % Code sind alleine Funktionen aus der Gleitkommabibliothek, die in einer Uhr wohl problemlos zu vermeiden ist. Weiter ist mir an der Vektortabelle aufgefallen, dass es keinen einzigen Interrupt gibt. Daraufhin hab ich mir den Quellcode angesehen, denn das hab ich für eine Uhr schon merkwürdig gefunden. Im Quellcode hab ich dann die ganzen Delayfunktionen gefunden... So wird das mit einer genauen Uhr nichts. Man muss Hardwaretimer verwenden statt den Delayfunktionen. Dann wird auch die Gleitkommabibliothek nicht mehr gebraucht und der Code passt mühelos in den Speicher. Grüße, Peter
Wieder was dazu gelernt :-) Jetzt ist der Code tatsächlich DEUTLICH geschrumpft. Danke!
Mhh, also ein Wecker mit DCF, Encoder, Entprellung, RC5 Sender und HD4..- LCD sowie einer nicht einstellbaren Weckzeit im EEPROM ist in C bei 1950 bytes. Ich kann Anfängern nur empfehlen mit nicht zu "kleiner" Hardware anzufangen..
off schrieb: > Ich kann Anfängern nur empfehlen mit nicht zu "kleiner" Hardware > anzufangen.. Warum nicht? Mit überdimensionierter Hardware lernen sie es doch nie, ressourcenschonend zu programmieren bzw. effizient arbeitende MC-Programme zu schreiben. MfG
@ Kluchscheißender Consulter (kluchscheisser) >Warum nicht? Weil man zum lernen und testen Freiräume braucht. > Mit überdimensionierter Hardware lernen sie es doch nie, >ressourcenschonend zu programmieren bzw. effizient arbeitende >MC-Programme zu schreiben. Bla. Frühzeitige Optimierung ist die Wurzel vielen Übels. MFG Falk
Falk Brunner schrieb: > Bla. Frühzeitige Optimierung ist die Wurzel vielen Übels. Spaghetticode schreiben ist aber noch viel schlimmer. Man optimiert ja nicht einzelne Instruktionen. Man programmiert modular, d.h. man überlegt sich erstmal, was das Programm machen soll und welche Funktionen man dazu braucht. Dadurch sieht man, welche Funktionen sich ähneln und durch eine Funktion ersetzt werden können, die man dann mehrfach aufruft. Dann fällt das Optimieren, d.h. kleinen Source/Code zu schreiben ganz von alleine mit ab. Die oben genannte DCF-77 Uhr ist ja auch nicht aufs letzte Quentchen optimiert (Dezimalwandlung verschwenderisch mit /10, %10). Optimiert ist dagegen die Auswertung der 59 DCF-Code Bits. Es gibt nicht 59 Funktionen, sondern nur eine einzige. Und die holt sich einfach aus ner Tabelle, wo das Bit zu speichern ist und welche Wertigkeit es hat. Optimiert ist auch die Unterteilung in einzelne Aufgaben. Eine Funktion mißt nur die Pulszeiten, eine andere prüft die Zeitfenster und die nächste macht dann die Bitauswertung. Dadurch bleibt der Code übersichtlich, d.h. wartbar und änderbar. Peter
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.