| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.0, OSOPT V3.1 |
> 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:
//----------------------------------------
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;
}
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:
//----------------------------------------
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;
}
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:
//---------------------------------------------------------------
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);
}
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:
//----------------------------------------
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;
}
> 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.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: Vorwärtsreferenzen / Bytearray-Pointer / Threading (von Michael Zapf - 22.07.2007 13:56)Re: Vorwärtsreferenzen / Bytearray-Pointer / Threading (von André H. - 4.08.2007 10:14)