Programmspeicher reicht nicht aus

[Killer]

Hallo,
ich hab ein großes Problem, im warsten Sinne des Wortes!!
Mein Quellcode ist zu groß für einen ATMega8, also größer als 8kB.
Der Quellcode lässt sich leider nicht schrumpfen. Meine Frage: kann ich den Programmspeicher durch ein EPROM/EEPROM (weiss ich nicht welches) beliebig erweitern?

MfG Killer

[ogni42]

Nein, das geht nicht. Der AVR hat eine Harvard Architektur. Da sind Programm und Datenspeicher getrennt - und der Programmspeicher beim AVR ist im Flash.

Alternative bei fester Flash-Größe wäre, dass Du in den Flash einen Interpreter packst, der die Programme, die in einem externen Flash stehen, interpretiert. Ist dann natürlich entsprechend langsam.

Aber: Ein Mega 168 ist Pinkompatibel und im Endeffekt billiger (läuft außerdem auch bis 20MHz)

[Christopher1]

Eventuell wäre es sinnvoll der ATMega8 durch einen ATMega168 zu ersetzen, der ist glaub ich Pinkompatibel und hat 16kB.

[Killer]

Naja ich bin jetzt schon bei ca 4kB hab allerdings noch nichtmal die Hälfte des Quellcode... und der wird noch lang!!


Ja man kann den auch erweitern,
was meinst du damit? lässt er sich jetzt doch erweitern? Dein Vorposter meint da aber das Gegenteil, was stimmt denn jetzt? #-o


MfG Killer

[vklaffehn]

öhm, die Größe des 'Quell'-codes ist relativ egal, wichtig ist, wie viele Bytes das fertige Programm nach dem Compilieren belegt. 4 KB Quellcode geht schnell, 4KB Programm dauert da schon etwas länger..... Und wenn's tatsächlich zu groß wird, dann wie oben gesagt auf den Mega168 oder gleich auf 'nen Mega32/64/128 umsteigen.... oder Programm optimieren ;-)
erweitern läßt sich der Programmspeicher wie oben schon gesagt, auf Grund der Harvard-Architektur (ein Speicher für's Programm, ein anderer für Daten) nicht.
MfG
Volker

[Killer]

@vklaffehn
Mit Größe des Quellcodes meinte ich die Größe in kB nach dem kompilieren. Tja wie gesagt, Code lässt sich nicht verkleinern.
Aber danke für eure Hilfe, dann werd ich doch nicht den "alten" Mega 8 aus der "großen Kiste" nehmen können...

MfG Killer

[Christopher1]

Naja ich bin jetzt schon bei ca 4kB hab allerdings noch nichtmal die Hälfte des Quellcode... und der wird noch lang!!


Ja man kann den auch erweitern,
was meinst du damit? lässt er sich jetzt doch erweitern? Dein Vorposter meint da aber das Gegenteil, was stimmt denn jetzt? #-o


MfG Killer
Nee geht nicht war ein Missverständnis, habs ja auch innerhalb 1 Minute geändert O:)

[shaun]

Das sagt alles nichts bis gar nichts aus, wenn Du alles, was Speicher frisst eingebunden hast (math? string?) kannst Du hundert mal drauf zugreifen, ohne dass der Code linear mitwächst. Nutzt Du eine Optimierung?

[kalledom]

Mit Größe des Quellcodes meinte ich die Größe in kB nach dem kompilieren. Was ist denn nach dem kompilieren mehrere kB groß, die ASM-Datei oder das HEX-File ?
Beide haben mit den 4 kB Flash des µC nichts zu tun.

[Noss]

hay ich hab dann mal ne frage wie merkt man das der speicher dann voll ist wenn die HEX oder die ASM file nicht raufgespielt werden was wir dann direkt draufgespielt? ich mein im flash tool ist es die hex wird die dann noch konvertiert und was macht dann das aus? also wie kann man das bemerken dieses Problem hatte ich nämlich noch nie... kommt dann ein error im flash tool?

[s.o.]

Bestimmst du die Größe über den Explorer oder über AVR-size. Die hex-explorer-datei-größe (klingt jetzt blöd) sagt wenig aus.

[Vitis]

Einen Code, den man nich schrumpfen/verkleinern kann gibts nicht

[Killer]

Wenn ich das Programm auf den Mega überspielen will, öffne ich ja den "Programmer". Dort angekommen steht dann im linken unterem Fensterrand "3988 bytes read". Ich war jetzt mal davon ausgegangen, dass dieser Wert die Größe des Programmes ist. Und da der Mega8 ja 8kB Programmspeicher hat hatte ich (meiner Ansicht nach) logisch geschlossfolgert, dass das Programm auf diesem AVR schon knapp die Hälfte des Programmspeichers einnimmt. Das stimmt doch soweit oder etwa nicht?

MfG Killer

[CsT]

Ja, soweit ich weiß, stimmt das. Was hast du denn für tollen Quellcode, dass er sich nicht verkleinern lässt? Welche Optimierungsstufe hast du eingestellt? Magst du uns ein paar Quellcodeteile zeigen?

Viele Grüße
CsT

[Killer]

Was meinst du mit Optimierungsstufe? Also ich habe da bis jetzt 10 if-Abfragen und halt ein paar Variablen welche definiert werden und die Ausgabe von Zeichen per serielle Schnittstelle. In je einer if-abfrage werden per "and" addiert, 9 Variablen abgefragt (!!!!) wodurch die Größe sehr zunimmt!!! Da fällt mir ein, dass es beispielsweise bei C++ neben den if-Abfragen noch weitere, einfachere switch-abfragen gibt. Gibt es deratige einfachere auch in BASCOM?
Eine von 10 Abfragen sieht bei mir momentan wie folgt aus:

If Bit1 = 0 And Bit2 = 0 And Bit3 = 0 And Bit4 = 0 And Bit5 = 0 And Bit6 = 0 And Bit7 = 0 And Bit8 = 0 And Bit9 = 0 And Bit10 = 1 Then
Getzahl = 0
Return
End If

Meine Grundidee ist bei diesem Projekt, den Zustand von 10 Datenleitungen in Variablen anzugeben und anschließend abzufragen und einer Variable (hier "Getzahl") zuzuordnen. Zur Info: Die Datenleitungen kommen von einem weiteren Prozessor. Ich weiss, diese ganze Übertragungsart geht sicherlich wesentlich einfacher über diverse vorgegebene Schnittstellen, aber ich möchte die Übertragung in meinem ersten größeren Projekt eben so haben!!

So, genug gepostet, jetzt dürft ihr antworten ob es einfachere Abfragen gibt \:D/

MfG Killer

[Noss]

sollen die immer das gleiche ERgenbis haben also bit1-10 immer das gleiche sein dann probier mal eine funktion :) mit einem parameter der das zeichen/zahl ist und die Bits überprüft, bzw kann man net schreiben
(c++ code :D)
if((Bit1&&Bit2&&Bit3&&Bit4&&...Bit10)==0)
?

[Killer]

Nö, wie man sieht (oder auch nicht) ist in dem von mir oben geposteten Code Bit10=1 oder soll es zumindestend sein. Also fals folgendes erhalten wird:

0000000001
das geht weiter bis.
0000001010
dies ist das Synonym für die Ziffer 9.
Tja, in C++ hätte ich das genauso gemacht wie Du, Noss aber leider mache ich dies in BASCOM ;-)

MfG Killer

[Noss]

hmm das BIT ist ein int. du könntest nochmal das ganze runtersetzen indem du es zu nem BOOL (gibts das in BASCOM) speichern. und ich würds zur übersichtlichketi vllt. noch in ein array schreiben... aber du kannst ne funktion schreiben die 10 paramater hat und dann gibts sie dir false oder true zurück wenn diese passen das sollte es jedenfalls verkleinenern oder? wenn true zurück gegeben wird setzt du dann einfach fetzahl auf 0.

jo die 1 hat ich übersehen ;)

[fluchtpunkt]

Tja, in C++ hätte ich das genauso gemacht wie Du, Noss aber leider mache ich dies in BASCOM ;-)
Ist ja toll das du das dann ganz anders schreiben wuerdest, aber ich wuerde mit dir wetten das sich der generierte Code nicht wirklich unterscheidet.
Wer ne Sprache fuer Beginner waehlt muss halt bisschen mehr schreiben...

[glaskugel_auspack]

0000000001
das geht weiter bis.
0000001010
dies ist das Synonym für die Ziffer 9.
Kleiner Tipp, wenn 1 bei dir eine 0 ist und 10 eine 9, und du dann wahrscheinlich diese Zahlen eh ausgibst. Dann bastel dir deine Bits passend in eine Variable und subtrahiere 1.


Oder nimm gleich C++



du könntest nochmal das ganze runtersetzen indem du es zu nem BOOL [...]
aber du kannst ne funktion schreiben die 10 paramater hat
Also wenn ihr alle so codet ist es klar das der Speicher nicht reicht.

Effizienz Leute! :-s

[Noss]

BOOL check(BOOL bit1, BOOL bit2, BOOL bit3, BOOL bit4, BOOL bit5, BOOL bit6, BOOL bit7, BOOL bit8, BOOL bit9, BOOL bit10)
{
if(global_bit1==bit1&&global_bit2==bit2&&...global_bit10==bit10)
return 0; //Vergleich positiv
else
return 1; // Vergleich negativ
}

so war das gemeint aber am schönsten wäre es mit strukturen....
und das verbraucht viel wenigser speicher als 10 mal das ganze
btw so rufst dus dann auf


if(check(0,0,0,0,0,0,0,0,0,1)==0)
{
tu was verdammt
}

und das ist schon effizenter oder und warum BOOL
weil BOOL nur ein bit belegt int jedoch viel mehr und wenn es nur zustand 1 und 0 sein muss... sag mir was daran uneffizient ist

[Phantomix]

Noss du bist n experte... BOOL belegt ein bit das ist richtig. das bit steht dann aber im RAM (der byteweise ansteuerbar ist) also ein byte weg, oder in nem Register (selbes Prinzip). Während des Funktionsaufrufes steht das ganze im Stack (der im Ram liegt, siehe oben)

ich schlage vor, wenn du viele Vergleiche hast, schreib dir die 10 Bit in eine variable die du dann vergleichen kannst à la



//variable ist 16 bit integer
if (variable == 0b0000000001)


dann hast du einen Vergleich, statt zehn