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.
Angehängte Dateien:
In Zeile 42 des Files "streng_geheim.c" hast du ein Komma vergessen.
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?
Angehängte Dateien:
-
Clipboard01.jpg
41 KB
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.
Hier steht welche Sections in welchem Speicherbereich liegen. Da muss man die Größen entsprechend aufaddieren: https://rn-wissen.de/wiki/index.php/Avr-gcc/Interna#Sections Der Stack ist da natürlich noch nicht bei.
Matthias S. schrieb: > Habe ich früher auch mal benutzt, ist aber mittlerweile veraltet. Hat aber mit dem Problem jetzt nichts zu tun. Oliver
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.
Der WINAVR sollte Dir eigentlich sowas ausgeben:
1 | Program: 200 bytes (19.5% Full) |
2 | (.text + .data + .bootloader) |
3 | |
4 | Data: 14 bytes (21.9% Full) |
5 | (.data + .bss + .noinit) |
82 + 57 = 139, da ist also noch reichlich Luft bis zu den 256 Byte.
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.
Hallo zusammen,
zunächst Danke für die zahlreichen Antworten. Einfach Top
Ich bin max auf dem "Anfänger Level" und muss mir erstmal die Antworten
weiter aufarbeiten. Deshalb bitte ich etwas um Nachsicht.
Wenn ich was grundsätzliches falsch gemacht habe... raus damit
So habe ich die Datentabellen eingebunden und ausgelesen
// ****** Zuweisung der Datentabelle
********************************************************
//Schieberkennlinie: 0 71523 31 39 47 55 63 71 79
87 95 103 111 119 127 135 143 151 159 167 175 183
191 199 207 215 223 231 239 247 255
uint8_t Schieberkennlinie[33] =
{0,0,0,0,0,0,0,3,11,20,30,41,53,66,80,94,108,122,135,148,159,170,179,187
,193,198,202,205,207,208,208,208,208};
//Drehzahlkennlinie: 0 7 15 23 31 39 47 55 63 71 79
87 95 103 111 119 127 135 143 151 159 167 175 183
191 199 207 215 223 231 239 247 255
uint8_t Drehzahlkennlinie[33] =
{0,8,16,24,32,40,47,54,61,68,74,79,83,86,89,92,95,98,101,104,107,110,100
,100,100,100,100,100,100,100,100,100,100};
So lese ich sie aus:
Byd1 = (Freq / Punkte);
Byd2 = (Byd1 + 1);
//Werte aus der Taballe auslesen
D1 = Drehzahlkennlinie[Byd1];
D2 = Drehzahlkennlinie[Byd2];
Ydreh = (D1 + ((D2 - D1) / Punkte));
Bys1 = ((theTenBitResults / 4) / Punkte);
Bys2 = (Bys1 + 1);
//Werte aus der Taballe auslesen
Y1 = Schieberkennlinie[Bys1];
Y2 = Schieberkennlinie[Bys2];
Yschieb = (Y1 + ((Y2 - Y1) / Punkte));
Schorsch schrieb: > Deshalb bitte ich etwas um Nachsicht. Trotzdem solltest du dir mal genauer vor Augen halten was Schorsch schrieb: > Lockup Tabellen bedeuten sollen .....
Schorsch schrieb: > Wenn ich was grundsätzliches falsch gemacht habe... raus damit Du nutzt kein pgm_read_byte(). https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_PROGMEM_und_pgm_read > uint8_t Schieberkennlinie[33] = > {0,0,0,0,0,0,0,3,11,20,30,41,53,66,80,94,108,122,135,148,159,170,179,187 > ,193,198,202,205,207,208,208,208,208}; Eher so
1 | #include <avr/pgmspace.h> |
2 | |
3 | uint8_t Schieberkennlinie[33] PROGMEM = |
4 | {0,0,0,0,0,0,0,3,11,20,30,41,53,66,80,94,108,122,135,148,159,170,179,187 |
5 | ,193,198,202,205,207,208,208,208,208}; |
6 | |
7 | Y1 = pgm_read_byte(&Schieberkennlinie[Bys1]); |
8 | Y2 = pgm_read_byte(&Schieberkennlinie[Bys2]); |
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
const PROGMEM mit pgm_read oder const __flash ohne pgm_read. __flash geht afaik ab GCC 4.6?!?
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.
Hi
Was heissen die '512 RAM' in
>Beim Raspberry mit 512 RAM ist das Stack kein Problem.
?
MfG Spess
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.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Aber darum geht es hier überhaupt nicht. Solange man den Code nicht kennt kann man nur spekulieren.
Frank M. schrieb: > Fatal wäre natürlich ein verschwenderischer Umgang mit lokalen Arrays Was man aufgrund von Libraryfunktion nicht. printf und Co.
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 !!!!!
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.