Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo Andrè, > > eine beliebte Variante ist der Verweis auf das Handbuch der CC2. > In meinem jedenfalls (C-Control II Unit) gibt es eine Seite 42 mit dem Abschnitt "4.4.6 Stapelprozessor" . > > Ich zitiere: > "Der Stapel dient auch als Zwischenspeicher für lokale Variablen von Threads und Unterfunktionen...". > Das dabei dieser Stapel (Stack) im SRAM liegt dürfte eher Nebensache, bzw. bedeutungslos sein. > Was eher von Bedeutung ist, ist die Tatsache, dass die Beendigung einer Funktion auch zur Freigabe > des Variablenspeichers auf dem Stack führt und eine neu aufgerufene Funktion zum Überschreiben des > freigegebenen alten Stacks führt. > So jedenfalls funktioniert es prinzipiell bei anderen Compiler-Programmiersprachen. > > Wenn die Informationen des Handbuchs an dieser Stelle falsch sind, lasse ich mich natürlich gern von > dir belehren. > > So würde ich nicht unbedingt darauf vertrauen, dass ein CRLF anschließend gesendet, wie von dir > vorgeschlagen, dazu führt, dass die lokale Variable länger lebt, als bis zum Ende der Funktion. > > Allerdings widerspricht deine Methode auch in diesem Fall wieder der Information des Handbuchs. > Auf Seite 102, Abschnitt "7.2.10 Senden von Datenrahmen" wird für die Übertragung von Bytepuffervariablen > die Vorgabe gegeben Zitat "Daher muß die Bytepuffervariable statisch sein..." und das ist jedenfalls > nicht bei lokalen Variablen der Fall. > > Also zusammengefasst: > Um nicht vorhersehbare Nebeneffekte zu vermeiden, würde ich in diesem Fall auf die Verwendung von > lokalen Feldvariablen verzichten, auch wenn es unter diesen und jenen Umständen vielleicht möglich ist. > Vor allem Anfänger werden froh sein in diesem Bereich keine Fehler suchen zu müssen, weil sie vielleicht > eine Randbedingung nicht beachtet haben. > > > Mit freundlichen Grüssen > > Michael G. > > > > Hallo Michael, > > > > > auf den ersten Blick würde ich sagen liegt dein Problem in dem lokal deklarierten Datenfeld "Test". > > > Dies muss global deklariert werden. > > > Nach Beendigung der Funktion TestAblauf() ist die Variable Test nicht mehr gültig, > > > aber eventuell noch nicht übertragen. > > > > Das Stimmt so nicht ganz. > > Bei hwcom.send() kann man auch lokale Arrays übertragen. Man muß nur dafür sorgen, > > daß die Funktion erst beendet wird, sobald alle Daten fertig gesendet werden. > > Dies erreicht man entweder durch ein <code>wait hwcom.ready()</code> oder, indem > > man noch etwas über hwcom.ausgibt, was nicht auf ein Array angewiesen ist. > > Also z.B. Einzelwerte, oder hier ein CRLF mit <code>hwcom.ret()</code>. > > > > > Die Variable Test liegt nämlich auf dem Stack, der bei neuen Funktionsaufrufen anderweitig verwendet wird. > > > > <u>Das Stimmt auch nicht.</u> Variablen liegen nie auf dem Stack ! > > Auch lokale Variablen belegen ganz normal Speicherplatz im SRAM. > > Nur wird dieser nach Beenden der Funktion wieder freigegeben. > > Aber das hat, wie gesagt, nichts mit dem Stack zu tun. > > > > MfG André H. > >