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 Michael, > > > Ich habe drei Fragen: > > > > 1. Was in Java problemlos ist, funktioniert in C2 nicht: Vorwärtsreferenzen. Das heißt, ich muss alle Symbole erst definieren > > (z.B. Funktionen), bevor ich sie nutzen kann. Resultat ist, dass ich jetzt alles, was ich in Java in einzelnen Klassen gruppiert > > hatte, nun komplett in eine Datei reingedrückt habe und eifrig am Sortieren bin (knapp 4000 Zeilen). Gibt es da mittlerweile > > schon einen Compiler, der Vorwärtsreferenzen oder wenigstens Deklaratoren anbietet (wie in C)? > > Nein, der Compiler ist weiterhin ein Single-Pass-Compiler. > Ressourcen, die angesprochen werden sollen, müssen immer "oberhalb" > der ansprechenden Stelle liegen bzw. definiert sein. > Alles in eine Datei zu quetschen ist evtl. nicht so empfehlenswert. > > > > 2. Ich habe ein byte[], in dem eine Liste von Namen steht. Wenn ich einen Namen von dort über die hwcom schicken möchte, > > bräuchte ich so etwas wie ein hwcom.sendfrom(byte[], start, length). Das gibt es leider nicht. Da dachte ich, man kann > > Pointerarithmetik betreiben, also hwcom.send(byte[]+pos, length), aber das geht auch nicht. Das einzige, was mir > > noch einfällt, ist, die Bytes einzeln mit hwcom.put zu schicken oder den fraglichen Namen aus dem byte[] mit mem.copy > > rauszukopieren und das Zielfeld mit hwcom.send zu schicken. Das ist eigentlich verschwendeter Speicherplatz. > > Oder geht es anders? > > Prinzipiell kann man direkt Speicherbereiche senden. > Dazu ist natürlich ersteinmal etwas Wissen über die (interne) Funktionsweise und > "Speicherverwaltung" der CC2 notwendig. > Arrays werden an Funktionen nur als Referenz übergeben. > D.h., einer Funktion wird immer nur die Startadresse des Arrays übergeben. > Nicht anders verhält sich dies bei hwcom.send(). > Nun erwartet hwcom.send() grundsätzlich ersteinmal ein Bytearray. > Dies kann man aber ohne weiteres ändern. > Ich verwende z.B. in einigen Projekten eine Funktion hwcom.sendint(), um direkt Integerarray > senden zu können. > Dies sieht dann so aus: > <code>//---------------------------------------- > function send ( int buf[], int length ) > //---------------------------------------- > { > capture; > wait ready(); > inline vmcodes.VM_LOAD_LOCAL_INT; > inline -8; > inline vmcodes.VM_LOAD_LOCAL_INT; > inline -6; > inline vmcodes.VM_HWCOM | (vmcodes.HWCOM_SEND << 8); > release; > }</code> > > Zu beachten ist hier aber, daß bei "length" die zu sendende Größe in Byte übergeben wird. > > Genauso kann man auch einen kompletten Speicherdump des RAMs machen, > wenn man die Funktion folgendermaßen nutzt: > <code>//---------------------------------------- > function sendmem ( int addr, int length ) > //---------------------------------------- > { > capture; > wait ready(); > inline vmcodes.VM_LOAD_LOCAL_INT; > inline -8; > inline vmcodes.VM_LOAD_LOCAL_INT; > inline -6; > inline vmcodes.VM_HWCOM | (vmcodes.HWCOM_SEND << 8); > release; > }</code> > > Hier wird der Inhalt des SRAMs ab Adresse "addr" mit der Länge length gesendet. > Wenn man nun Bytearrays mit einem Offset senden möchte, muß man sich mit > Hilfe dieser Funktion sendmem() eines kleines Tricks behelfen: > <code> > //--------------------------------------------------------------- > inline function getMemAddrByte(byte data[]) returns int > //--------------------------------------------------------------- > {// gibt die Startadresse des Arrays im RAM zurück :-) > // aus Modul mem.c2 > } > > //--------------------------------------------------------------- > function sendoffset(byte buf[], int offset, int length) > //--------------------------------------------------------------- > { > sendmem(offset+getMemAddrByte(buf), length); > }</code> > > Dies funktioniert sicher. > Man kann prinzipiell aber auch eine einzige Funktion draus machen, welche natürlich kürzer ist. > Jedoch müßte ich das erst testen. > Daher hier die Funktion ohne Gewähr: > <code>//---------------------------------------- > function sendmem ( byte buf[], int offset, int length ) > //---------------------------------------- > { > capture; > wait hwcom.ready(); > 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_HWCOM | (vmcodes.HWCOM_SEND << 8); > release; > }</code> > > > > 3. (Leicht OT hier) Ich denke darüber nach, für die nächste Umsetzung des Prototypen einen CC-Pro zu verwenden, > > wobei ich diesen noch nicht genauer kenne, außer, dass es ein ATMega ist. Kann er Multithreading? Wenn ja, ist das > > eine Eigenschaft aller Atmel-Controller (auch anderer Controller-Kits), oder gibt es beim CC-Pro so ein "Betriebssystem" > > wie hier beim CC2? > > Multithreading ist bei Controllern immer eine Softwarelösung. > Controller selbst, auch der ATMega, können dies nicht. > Es gibt aber verschiedene Ansätze, Multithreading zu implementieren. > Bei der CCPro ist dieses ähnlich, wie bei der CC2, in Form von Anzahl Instruktionen > bis Threadwechsel gelöst. > Eine andere Möglichkeit wäre eine interruptgesteuerte Zeitscheibe, wie es z.B. bei Windows der Fall ist. > Aber das ist um einiges aufwendiger, als das einfache Zählen der Instruktionen. > Man muß hier aber sagen, daß es bei der CCPro weniger Möglichkeiten gibt, in die Threadkontrolle > während der Laufzeit einzugreifen, als bei der CC2. > > 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. > Mehr schreibe ich dazu jetzt mal nicht. > Nur eines: Die Programmierung der CCPro ist um einges schwieriger, da diese schon > eher an das direkte Programmieren an µControllern erinnert. (Als wäre kein OS drauf.) > Dementsprechend viel muß man wegen Initialisierungen etc. beachten. > > > (* Projekt: Generisches Steuerungssystem auf Basis einer spezifischen regelbasierten Programmierung mit Interpreter > > im CC2; Anschluss mit Live-Abfrage über PC, Up/Download von Regeln über PC während der Laufzeit, LCDisplay und > > Tastatur zur direkten Kontrolle. Soll hier zur Steuerung der Heizungsanlage und ggf. weiterer Systeme eingesetzt > > werden) > > Ich sage, je umfangreicher das Projekt ist, desto eher sollte man bei der CC2 bleiben. ;-) > Und wenn es doch einmal zeitkritisch wird, kann man einzelne Routinen problemlos in ASM > umsetzen, und sich in bis zu 192kB Flash allein für ASM austoben. ;-) > Eine solche "Narrenfreiheit" in Sachen ASM hat man momentan ansonsten bei keinem > aktuellen Controller der C-Control-Serie. > Zudem ist bisher bei der CCPro noch kein ASM möglich. Es soll zwar geplant sein, aber > wann es implementiert wird, ist (zumindest mir) nicht bekannt. > > > MfG André H.
