Hallo,
ich hoffe jemand kann mir so kurz vor Weihnachten noch bei einem Problem
helfen:)
Und zwar ist mein Ziel über ein Grafikdisplay die Slave-Adresse für I2C
einstellen. Ich benutze den MSP430F5310. Diese muss als Hex-Wert ins
passende Register eingetragen werden. Dabei handelt es sich eigentlich
um 7 Bit.
Allerdings habe ich hier schon probleme. Wenn das Array zu groß ist,
also 128 Einträge hat, dann hab ich ein ganz seltsames Phänomen beim
builden. Ich benutze Code Composer Studio und wenn ich auf debuggen
gehe, compiliert er, aber ich bekomme den Resume-Butten nicht
freigegeben. Nur der Pausen und Stopp Button sind da. Es entstehen
keinerlei Fehlermeldungen.
In einer Methode will ich nun I2C mit der Slave Adresse initialisieren.
Dazu habe ich ein zweites Array mit den passenden Hex-Werten.
Kommentiere ich die zweite Zeile in meinem Code aus, kompiliert er ganz
normal. Sonst bekomme ich den resume-Button nicht.
Hab ich auch schon dran gedacht. Insgesamt habe ich ja 34 KB. Er zeigt
mir beim kompilieren knapp 30 KB an. Mit einem etwas kleineren Array
geht es, wenn ich es ein bisschen größer mache nicht mehr. Sollte er
dann keine Fehlermeldung geben?
Was verbraucht so ein Array mit int-Werten?
128*16Bit= 2048 Bit = 256 Byte. Sollte doch eigentlich bei noch
verbleibenden 4 KB ausreichen, oder übersehe ich was?
florian2840 schrieb:> 128*16Bit= 2048 Bit = 256 Byte. Sollte doch eigentlich bei noch> verbleibenden 4 KB ausreichen, oder übersehe ich was?
hast du RAM oder Flash betrachtet? Beim Ram braucht man ja auch noch
Platz für den Stack, diesen kann man nicht ablesen.
Hi,
warum brauchst Du dafür überhaupt ein Array?
So wie ich das sehe, sind die im Array hinterlegen Indices fortlaufend,
also würde es reichen
1
slaveAdrer=array_index_receive+8;
zu benutzen.
Ich vermute mal, dass das eigentliche Programm etwas anders aussieht,
als das, was Du hier verrätst...
Weiters ist mir aufgefallen, dass Du slaveAdr_array1[128] mit nur 92
Werten initialisierst, warum?
--jmp
Ja, das eigentliche Programm sieht anders aus nur viel zu lang, um
dieses hier zu posten. Naja ich übergebe der Initialisierungsroutine den
Wert aus dem Array, der vorher auf dem Display eingestellt wurde. Also
ist da nichts fortlaufend.
Ja habe 92 Werte, weil es damit grad gepasst hat. Aber ich probiere das
jetzt wirklich mal aus, ob der Programmspeicher einfach voll ist, indem
ich einfach mal paar c dateien auskommentiere.
char *slaveAdr_ausgabe[92]
das ist für mich ein array von Zeigern. Es liegt im RAM und benötigt
92*2 Byte.
unsigned int slaveAdr_array1[128]
Das liegt auch im RAM, wird aber aus dem Flash initialisiert. Und genau
da kann es haken. RAM zu klein? Initialisierung zu langsam, Watchdog
schlägt zu?
Wie schon beschrieben, kannst du das erste Feld streichen. Die Werte
sind fortlaufend.
Das zweite Feld kann mit sonst ins Flash geschickt werden. Oder
beschreibst du es zur Laufzeit?
Die beiden Arrays sind doch völlig überflüssig.
Das mit den Strings verbraucht 5 Byte pro Eintrag (zwei Zeichen +
Stringendezeichen + zwei für den Zeiger). Das könnte man schon mal recht
einfach auf drei Byte reduzieren, indem man als Typ nimmt:
1
charslaveAdr_ausgabe[3][92];
Wobei der Compiler die Anzahl der Einträge auch selber zählen kann:
1
charslaveAdr_ausgabe[3][];
Zahlen als Strings zu speichern ist aber ohnehin unnnötig, da Du diese
Strings jederzeit (z.B. mit utoa() oder sprintf()) berechnen kannst:
1
charslaveAdr_str[3];
2
sprintf(slaveAdr_str,"%02X",slaveAdr[x]);
Schon mal ein Array gespart. Aber auch das zweite ist überflüssig, da es
ja nur eine Reihe aufsteigender Zahlen beinhaltet. Die kann der
Mikrocontroller sogar noch besser berechnen:
Ich würde ja gerne das erste Array streichen. Nur das Problem ist, dass
meine Ausgabemethode am Display Char-Werte oder Strings erwartet. Der
kann ich keine Hexwerte übergeben. Daher die beiden Arrays.
Nochmal zusammengefasst:
Meine Displayausgabemethode erwartet char oder String
Die Initialisierung des I2C Intwerte in Hexformat.
Meine Überlegung waren da die beiden Arrays. SIe verbrauchen nur
unglaublich viel Speicherplatz. Gibt es da vll ne andere Möglichkeit?
Ne ich initialisiere schon beim Compilieren, nicht zur Laufzeit.
Ah perfekt Fabian O. Sowas hab ich gesucht und ist viel elleganter. Ja
das stimmt, die Arrays verbrauchen viel zu viel Speicher. Werde ich
nachher gleich mal umsetzen. Melde mich dann nochmal:) Erstmal ganz
großen Dank!!
ho ho ho schrieb:> Uuuups, ich würde die ersten Kapitel des Lehrbuchs noch einmal> aufschalgen. :-(
Zu dem Kram:
meine Ausgabemethode am Display Char-Werte oder Strings erwartet. Der
kann ich keine Hexwerte übergeben.
Weils mir gerade noch auffällt: Für 8-Bit-Werte ist der Datentyp
unsigned char angemessener als unsigned int, denn letzterer braucht
(mindestens) 16 Bit. Das würde bei dem Array die Hälfte an Speicher
sparen. Wenn sich die Daten zur Laufzeit nicht ändern, gehört außerdem
noch ein "const" dazu.
Falls im richtigen Programm in dem Array also doch keine fortlaufenden
Werte stehen sollten, besser statt
ho ho ho schrieb:> meine Ausgabemethode am Display Char-Werte oder Strings erwartet. Der> kann ich keine Hexwerte übergeben.
Andere Leute schreiben sich in dieser Situation eine kleine Funktion,
die aus einem "Hexwert" einen String erzeugt.
Oder sie schauen in die Dokumentation ihres Compilers, ob es nicht
möglicherweise in der C-Runtime-Library eine Funktion gibt, die genau
das erledigt.
Rufus Τ. Firefly schrieb:> ho ho ho schrieb:>> meine Ausgabemethode am Display Char-Werte oder Strings erwartet. Der>> kann ich keine Hexwerte übergeben.>> Andere Leute schreiben sich in dieser Situation eine kleine Funktion,> die aus einem "Hexwert" einen String erzeugt.
Man, man, man, du musst schon dem Faden folgen: Der Spruch war *nicht
von mir, sondern vom TE*. Ich gab ihm den Tipp, in seinem Buch zu lesen.
Also mehr Ruhe zu den Feiertagen! ;-)
