| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.0, OSOPT V3.1 |
> Ich hab immer mehr den Verdacht, dass CC2 einfach nix taugt. Vielleicht kann mir deshalb keiner
> helfen.
Eigentlich habe ich vor lauter Arbeit keine Zeit zu posten.
Aber wenn ich mir Deine Postings durchlese, komme ich zum SchluÃ?,
daÃ? das einzige Problem ist, daÃ? Du nicht programmieren kannst.
Auch das gepostete Programm von Dir zeigt das.
Und jetzt alles auf die CC2 zu schieben, oder auch die Aussage in einem anderen
Thread von Dir, da� - sinngemä� zitiert - "das Multithreading nichts taugt", befestigt meine Meinung.
Natürlich ist es einfacher, die "Schuld" auf den Controller zu schieben,
als beim selbstgeschriebenen.
Aber das löst das Problem nicht.
Darum wäre es das beste, wenn Du erstmal Stück für Stück das Programmieren lernst.
Und das macht man mit einfachsten kleinen Programmen und arbeitet sich
Step by Step an die eigentliche Aufgabe voran.
Dazu gehört auch, das Handbuch zu lesen, um die Funktionsweise der CC2 zu verstehen.
Dazu noch ggf. die Dokumentation zu den neueren Modulversionen.
Nur als Anhaltspunkt:
Es sind mehrere zig-tausend CC2-Units/Stations im Umlauf/Betrieb.
Das sollte einem schon zu Denken geben.
Im Forum ist nahezu jeder bemüht zu helfen. Das setzt jedoch auch voraus, da�
man nicht sagt, "ich hab' ein Problem, nun macht mal", sondern, daÃ?
der hilfesuchende auch aktiv mit dem helfenden "zusammenarbeitet".
So aussagen, wie "ich habe schon alles versucht" sind hier wenig zweckmä�ig.
Denn das hast Du garantiert nicht. Denn dann würde Dein Programm laufen.
Besser wäre es, wenn Du einfach sagen würdest, was Du versucht hast.
Dann kann jemand anderen bei der Fehlersuche auch behilflich sein.
Und, was den Simulator angeht (nicht Debugger):
Ich (und andere) habe schon öfters gepostet, da� der Simulator nur
das simulieren kann, was er kennt.
Aufrufe von ASM-Treibern können nicht simuliert werden.
Und folgende Module nutzen eben u.a. zwecks Optimierung und Beschleunigung
eben ASM-Routinen: cap.c2, stports.c2, hwcom.c2, swcom.c2, flash.c2, i2c.c2, i2ccom.c2,
rblcd.c2, mem.c2, ram.c2, strx.c2, lcdext.c2, srlcd.c2, edip.c2, fs20.c2, irctrl.c2.
Kommt der Simulator zu einem ASM-Aufruf, geht dieser ins Leere und der Simulator
reagiert unvorhersehbar.
Das ist dann ähnlich, wie ein ASM-Aufruf in der CC2, zu dem der ASM-Treiber
nicht in den Falsh geladen wurde. Nur bricht das OS der CC2 dann die Ausführung ab,
und gibt eine Fehlermeldung an de Host-LED aus.
Der Simulator war nie dazu gedacht, komplette Programme zu simulieren,
sondern nur einzelne Routinen. Denn es kann keine Hardware simuliert werden.
Darum sollte der Seimulator nur dazu verwendet werden, um Berechnungen
und Programmlogik zu testen, aber nie eine Hardwareansteuerung, die
der Simulator sowieso nicht nachvollziehen kann. (LCDs, I²C-Bus, ICs, eigene HW etc.)
Also, mein Vorschlag wäre jetzt folgender:
�berprüfe zuerst, ob alles auf dem aktuellen Stand ist.
Damit meine ich die IDE, die Module, sowie das OS und die HEX-Treiber.
Das steht aber auch schon immer auf der Hauptseite von CC2Net.de .
Wenn das sichergestellt ist, fange mit einfachen Programmen an.
Das erste wäre dann wirklich das klassische "Hallo World":
thread main
{
lcdext.init();
lcdext.print("Hello World");
quit 1;
}
Dann kannst Du Dir eine einfache Uhr bauen:
thread main
{byte second;
lcdext.init();
loop
{
lcdext.line(1);
lcdext.time(0);
lcdext.line(2);
lcdext.date(0);
wait second!=system.second();
second=system.second();
}
}
usw.
Prinzipiell kann ic auch empfehlen, einfach mal alle Beispiele im "Samples"-Verzeichnis
der IDE durchzugehen.
Danach erst solltest Du Dich erst an Deine eigentliche Aufgabe machen.
Das kostet natürlich Zeit. Aber die ist dann sinnvoll investiert, statt die Zeit damit
zu verschwenden, rumzumeckern.
Denn auf eines kannst Du Gift nehmen: Die CC2 hat so gut, wie keine Bugs.
Die zwei Bugs, die momentan noch enthalten sind, betreffen aber nicht Dein Programm.
Und beide betreffen nur HWCOM beim übertragen gro�er Datenmengen.
(kleiner, leider schwer zu reproduzierender Handshake-Bug und das gelegentliche
"Lost"-Byte beim Empfang. Aber beides scheint zusammenzuhängen.)
Poste auch mal in Stichpunkten, wie Dein Programm ablaufen bzw. was es genau
machen soll. Dann können ich, und auch andere, sagen was Du falsch machst.
Denn aus Deinem Code werde ich nicht ganz schlau, da dort einige
Ungereimtheiten enthalten sind.
Hier wollen Dir die Leute helfen, und das in ihrer Freizeit, ohne irgendeine Bezahlung.
Das können sie aber nur, wenn Du auch ausreichend Informationen lieferst.
Denn Gedankenlesen kann bisher noch keiner. ;-)
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: Wie flasht man das Teil überhaupt? (von Erich - 13.07.2006 12:59)Re: Wie flasht man das Teil überhaupt? (von Holger - 13.07.2006 13:33)Re: Wie flasht man das Teil überhaupt? (von Erich - 13.07.2006 14:20)Re: Wie flasht man das Teil überhaupt? (von Holger - 13.07.2006 18:28)Re: Wie flasht man das Teil überhaupt? (von Erich - 13.07.2006 19:16)Re: Wie flasht man das Teil überhaupt? (von Holger - 13.07.2006 19:22)Re: Wie flasht man das Teil überhaupt? (von Erich - 13.07.2006 19:29)Re: Wie flasht man das Teil überhaupt? (von Holger - 13.07.2006 19:31)Re: Wie flasht man das Teil überhaupt? (von Erich - 13.07.2006 19:45)Re: Wie flasht man das Teil überhaupt? (von Leo - 18.07.2006 11:56)Re: Wie flasht man das Teil überhaupt? (von Erich - 18.07.2006 12:28)