ATTINY 2313 - Passt da überhaupt ein Programm drauf?

OP #1859331
Lesenswert?

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?
Gast #1859347
Lesenswert?

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.
Gast #1859348
Lesenswert?

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.
Gast #1859377
Lesenswert?

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.
#1859429
Lesenswert?

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
Gast #1859431
Lesenswert?

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."
Gast #1859435
Lesenswert?

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
Gast #1859438
Lesenswert?

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.
Persönliche Seite #1859625
Lesenswert?

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
Gast #1859783
Lesenswert?

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..
#1860105
Lesenswert?

@  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
#1860140
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren