Hallo zusammen,
meine Programmierplattform ATMEL STudio 4, Version 4.19 Build 7.16 mit
WinAVR-20100110, MC ATtiny44.
Gerade versuche ich ein Bascom Programm welches genau auf diesem MC
schon läuft auf "C" umzustellen.
Im Bascom Programm nutze ich z.B. zwei Lockup Tabellen welche ich im
neuen Programm in zwei Stück Byte Array (je 33 Byte) eingebunden habe.
Im Programmverlauf greife ich je zweimal für eine Berechnung auf die
Arrays zu.
Durch den Compiler läuft alles ohne Fehlermeldung durch. Beim Test im
Zielsystem läuft es nicht. Kommentiere ich ein Array aus, läuft es
abermals fehlerfrei durch den Compiler, läuft aber im Zielsystem.
Da der ATTiny44 nicht den größten SRAM hat und ich keinen Attiny84 zum
Testen habe, möchte ich gerne wissen wie ich den benutzten SRAM
ermitteln kann. Sollte es im Compiler angezeigt werden so kann mir
vielleicht einer zeigen wo.
Ich habe zwei Compileranzeigen zusammen gestellt wobei der linke das
laufende Programm und der rechte das nicht laufende zeigt.
Die Flashgröße scheint erst mit Bootloader ein Problem zu werden.....
dazu eventuell später.
Schorsch schrieb:> Hallo zusammen,> meine Programmierplattform ATMEL STudio 4, Version 4.19 Build 7.16 mit> WinAVR-20100110, MC ATtiny44.
Und warum schaust du dir nicht die einfache Ausgabe der SPeichernutzung
an? Was soll dieser akademische Aufriß und Hackermist?
> Im Bascom Programm nutze ich z.B. zwei Lockup Tabellen welche ich im> neuen Programm in zwei Stück Byte Array (je 33 Byte) eingebunden habe.>> Im Programmverlauf greife ich je zweimal für eine Berechnung auf die> Arrays zu.
Wie? Nutzt du dafür pgm_read_byte? Wenn nicht, verschwendet deine
Tabelle wertvollen SRAM.
> Durch den Compiler läuft alles ohne Fehlermeldung durch. Beim Test im> Zielsystem läuft es nicht. Kommentiere ich ein Array aus, läuft es> abermals fehlerfrei durch den Compiler, läuft aber im Zielsystem.
Na dann zeig doch einfach deinen Quelltext!
> Ich habe zwei Compileranzeigen zusammen gestellt wobei der linke das> laufende Programm und der rechte das nicht laufende zeigt.
Warum einfach, wenn es auch umständlich geht.
Normalerweise wird doch ein map-file erstellt?
Wo liegen deine arrays? Look-up-abellen lässt man normalerweise nur im
flash, spart RAM und die Kopierroutine.
Wenn RAM - global oder lokal?
Zeig doch mal dein Programm. Was sind das für Lookup Tabellen und wie
hast du sie deklariert?
Schorsch schrieb:> mit> WinAVR-20100110
Habe ich früher auch mal benutzt, ist aber mittlerweile veraltet. Gehe
mal in ' Project Configuration' auf 'Custom Options' und verwende die
AVR Toolchain.
Schorsch schrieb:> Da der ATTiny44 nicht den größten SRAM
256 Byte SRAM sind für einen MC, der nicht auf eine Hochsprache opmtiert
ist, sehr wenig.
Es wird SRAM für Parameterübergabe und Unterprogrammaufrufe benötigt.
Vielleicht wird auch noch der HEAP benutzt, dann bleibt nicht wer viel
für Variable übrig.
Die Speicherbelegung sollte man im MAP File sehen.
Gute Entwicklungswerkzeuge Compiler und Linker beziehen den Bedarf an
Stack in die Kalkulationen ein und verwenden nicht brutal den Rest des
Speichers. Dann entdeckt man das Problem nicht erst zur Laufzeit.
GEKU schrieb:> Gute Entwicklungswerkzeuge Compiler und Linker beziehen den Bedarf an> Stack in die Kalkulationen ein
Werde da mal etwas konkreter.
Sowas kenne ich nämlich für AVR auch noch nicht, und bei komplexeren
MCUs (z.B. Cortex-M) wird das wegen der vielen möglichen Interrupt
Prioritäten richtig interessant. Stack Berechnng ist grade wegen der
Interrupts alles andere als trivial.
Zu erkennen wieviel tatsächlich benötigt wird ist nicht trivial. Aber
das worst-case-szenario ist einfach -> Warnung. Kann man sich dann damit
auseinandersetzen, ob der schlimmste Fall eintreten kann. Wenn ja, wird
es auch irgendwann passieren. Mitunter erst nach langem störungsfreiem
Betrieb, und keiner denkt erstmal an eine fehlerhafte Software.
Schorsch schrieb:> Deshalb bitte ich etwas um Nachsicht.
Trotzdem solltest du dir mal genauer vor Augen halten was
Schorsch schrieb:> Lockup Tabellen
bedeuten sollen .....
Das Stichwort "PROGMEM" ist ja auch schon gefallen. Zum Thema Daten im
Flash lies dich mal hier im Forum durch die Tutorials, zu finden oben
links.
Oliver
Jim M. schrieb:> Werde da mal etwas konkreter.
Gerade bei einer Prozessorfamilie, die mit dem SRAM knauserig umgeht ist
es wichtig die Größe das Stacks genau zu kalkulieren. Beim Raspberry mit
512 RAM ist das Stack kein Problem.
Der Stackbedarf kann auf Grund der Verschachtelungstiefe an
Unterprogrammaufrufen und gleichzeitigen Interrupts sowie gleichzeitig
auftretenden Anzahl lokaler Variablen ermittelt werden.,
Beim MSP430 wächst der reservierte Stackbereich mit diesen Parametern.
Der Stack liegt am oberen Ende des SRAMs
Peter D. schrieb:> 82 + 57 = 139, da ist also noch reichlich Luft bis zu den 256 Byte.
Wo bleibt der Bedarf an Stack?
Gerade wenn man, was bei einer Hochsprache üblich ist, mit viel
Prameterübergaben und lokalen Variablen arbeitet, ist das Stack nicht zu
vernachlässigen.
GEKU schrieb:> Peter D. schrieb:>> 82 + 57 = 139, da ist also noch reichlich Luft bis zu den 256 Byte.>> Wo bleibt der Bedarf an Stack?
Rechne doch mal aus, wieviele Unterfunktionen Du ineinander
verschachtelt aufrufen bzw. wieviele Argumente Du runtergeben kannst bei
ca. 100 Byte an vorgesehenem Stack. Für einen ATTiny reicht das allemal.
Fatal wäre natürlich ein verschwenderischer Umgang mit lokalen Arrays.
Aber darum geht es hier überhaupt nicht.
GEKU schrieb:> Frank M. schrieb:>> Aber darum geht es hier überhaupt nicht.>> Solange man den Code nicht kennt kann man nur spekulieren.
Ist das nicht deine Kernkompetenz, mein weitschweifiger Freund?
Schorsch schrieb:> So habe ich die Datentabellen eingebunden und ausgelesen
Laß diese Schnipseltaktik sein. Damit kann niemand was anfangen.
Häng den kompletten Code an. Dazu ist der Anhang ja da.
@ Falk
@ Oliver S.
danke sagt der Anfänger für die direkte Hilfe.
Nach dem Einfügen von pgm_read_byte ...... kam noch die Warnung
main.c:279: warning: '__progmem__' attribute ignored
main.c:284: warning: '__progmem__' attribute ignored
aus dem Compiler.
Nach dem Hinweis habe ich noch in die AVR-GCC-Tutorial, 14.2 Flash mit
PROGMEM und pgm_read geschaut.
Mit der Ergänzung
static const uint8_t Drehzahlkennlinie[33] PROGMEM = ..........
jetzt läuft es
DANKE !!!!!
