| Re: Vorwärtsreferenzen / Bytearray-Pointer / Threading Kategorie: Programmierung (von André H. - 4.08.2007 10:14) | ||
| Als Antwort auf Re: Vorwärtsreferenzen / Bytearray-Pointer / Threading von Michael Zapf - 22.07.2007 13:56 | ||
| ||
|
Hallo Michael, > Eben, das tut so richtig weh. Aber das war für mich im Augenblick die einzige gangbare Lösung. Es ist halt so, dass ich > ein Hauptprogramm exec.c2 und unter anderem eine Benutzerschnittstelle userint.c2 haben wollte. Das UI steuert > das rblcd und das keypad an. Wenn ich nun mit der Tastatur den exec stoppen möchte (durch Eingabe eines Befehls), > dann muss ich letztlich Zugriff auf exec haben -> userint muss also später kommen als exec. Andererseits kann dann > exec nicht mehr auf userint zugreifen (z.B. um den Status anzuzeigen). > > Es gibt noch Möglichkeiten, dies hinzubekommen: Man müsste userint.c2 aufteilen in einen Steuer- und einen > Anzeigeteil, also control.c2 und display.c2 und dann eine Reihenfolge display < exec < control konstruieren. Oder man > teilt exec auf in mehrere Teile und bettet dann userint ein: exec1 < userint < exec2. Prinzipiell kann man ein Programm immer so gestalten, da� man mit einem Single-Pass-Compiler keine Probleme bekommt. Dabei sollten "ganz oben" z.B. alle globalen Definitionen stehen (Variablen und Konstanten) Nach unten hin kommen dann die jeweils "übergeordneten" Routinen. Wenn es nur darum geht, einen Thread anzuhalten, kann man dies über den Umweg einer globalen Variabel, welche im zu steuernden Thread überwacht wird. Das sinnvollste wäre, Dein Programm generell so aufzuteilen: - globale Variablen (nennen wir es mal var.c2) - exec.c2 - userint.c2 (- evtl. main.c2) exec.c2 schreibt in global definierte Variablen in var.c2 alle nötigen Werte und Zustände. Das Modul userint.c2 hat Zugriff auf exec.c2 und var.c2. Es kann also auf exec.c2 Einflu� nehmen. userint.c2 hätte zugleich die Aufgabe, sämtliche Displayausgaben zu übernehmen, was schlie�lich nur allzu logisch wäre, da das Display eher dem Userinterface zuzuordnen wäre. ;-) > Hintergrund ist: Ich habe mir einen Konverter geschrieben, der Java in C2 umsetzt. Das funktioniert leider nicht > allgemein, sondern mit ein etwas Vorbereitung auf Java-Seite (kein new, kein ++/--, kein switch-case usw.). Naja, "--" und "++" lä�t sich äu�erst einfach konvertieren. ;-) Auch switch lä�t sich sehr einfach umschreiben, so da� ein Konverter ein "switch" in Java (oder C) sehr einfach in ein identisch funktionierendes Konstrukt in C2 umwandlen kann. Als kleines Beispiel: switch (xyz) { case 0: tuedies(); break; case 54": tuedas(); break; case 99: tuejenes(); break; } Das kann man ganz leicht zu folgendem konvertieren: if xyz==0 { tuedies(); } else if xyz==54 { tuedas(); } else if xyz==99 { tuejenes(); } Was anderes macht ein C- oder Java-Compiler daraus auch nicht. > Damit habe ich das ganze Gerät (CC2, Reglerboard, Tastatur, Anzeige, Rel8PCF) emuliert, und nun habe ich den > Code eben vollständig auf C2 konvertiert. Die Programmierung in Java geht mir leichter von der Hand, und ich kann > da effizienteres Debugging machen. Ich würde persönlich diesen Umweg eher nicht gehen. ;-) Denn, was in der einen Programmiersprache optimal ist, kann in der anderen im schlimmsten Fall zum Gegenteil ausarten. Daher wäre es evtl. besser, in Java bereits den C2-Singel-Pass-Compiler zu beachten, und die Resourcen dort gleich entsprechend anzuordnen. > > Prinzipiell kann man direkt Speicherbereiche senden. > > Dazu ist natürlich ersteinmal etwas Wissen über die (interne) Funktionsweise und > > "Speicherverwaltung" der CC2 notwendig. > > Dasselbe gilt übrigens auch für rblcd.printlength. Da hätte ich gerne auch die Möglichkeit, aus der Mitte eines byte[] > zu drucken. Kein Problem. Alle Funktionen, die irgendetwas Senden (egal wohin) und ein Bytearray, sowie eine Längenangabe als Parameter benötigen, können prinzipiell auf dieselbe Art und Weise behandelt werden, wie mein Beispiel für hwcom.send(). function printmem(byte s[], int Offset, int len) { inline vmcodes.VM_LOAD_LOCAL_INT; inline -10; // Startadresse von buf[] inline vmcodes.VM_LOAD_LOCAL_INT; inline -8; // offset inline vmcodes.VM_ADD; //diese beiden Werte addieren inline vmcodes.VM_LOAD_LOCAL_INT; inline -6; // length inline vmcodes.VM_INLINE_SYSCALL+rblcd.Segment; inline rblcd._SEND; } Ich habe diese Konstrukt auch mittlerweile getestet. Es funktioniert einwandfrei. ;-) > > Ob Du die CCPro verwenden willst, ist Deine Entscheidung. > > Ich kenne aber einige, die sich an der CCPro versucht haben, aber realativ schnell > > wieder zur CC2 "zurück" sind. > > Vielen Dank für diesen Hinweis. Vielleicht bleibe ich dann lieber mal auf der CC2 - die sieht jetzt etwas anders aus, aber > vertrieben wird sie noch, oder? Hast Du noch die vergossene Unit? Diese wurde durch die unvergossene Unit abgelöst. Die CC2 gibt es weiterhin, und wird es weiterhin geben. Sie wird derzeit nur leider nicht aktiv beworben, um die Stückzahlen der sog. neuen C-Control-Generationen zu fördern. In Sachen CC2 kann sich aber (im positiven Sinne) evtl. einiges ändern. ;-) Fakt ist aber, da� die CC2 immernoch die C-Control ist, mit der man umfangreichste Projekte realisieren kann. Die CC-Pro ist hier kein Ersatz. Mit der CC2 hat man im ganzen mehr Möglichkeiten. Und wenn es einmal nicht reicht, dann hat man immernoch die Möglichkeit für einzelne Routinen auf ASM auszuweichen. > Ich habe ein bisschen die Befürchtung, dass man von Seiten Conrads auf die CC-Pro > gedrängt wird (wenn man in den Katalog sieht). Jein. ;-) Eine Entwicklung, wie die CC-Pro, kostet einiges an Geld. Dies bekommt man nur durch entsprechenden Absatz wieder rein. Und dies erreicht man, marketingtechnisch gesehen, nur durch massivste Werbung. Im Gegensatz dazu braucht die CC2 derzeit keine so massive Werbung. ;-) Was ich so höre, verkauft sie sich auch ohne extra Werbung sehr gut. ;-) Ich allein werde dieses Jahr mehrere hundert Stck. "verarbeiten". (Bei Conrad (im Online-Shop) wird die CC2 als Topseller geführt, die CC-Pro (noch?) nicht.) Zu mehr äu�ere ich micht nicht. ;-) MfG André H. Antworten bitte nur ins Forum! Fragen per EMail auf Forum-Postings werden nicht beantwortet! Das macht meine Heizung gerade | ||
Antwort schreiben Antworten: | ||