| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.0, OSOPT V3.1 |
Bevor Du weiter unnötig rumprobierst, eine kurze Antwort:
Ein direktes Laden von Programmen über den COM-Port-Redirector aus
der IDE heraus ist nicht möglich. (Au�er man macht wirklich solche Klimmzüge)
Das liegt daran, daÃ? man die Baudrate beim XPort nur FIX einstellen kann, und
der Redirector selbst keinerlei Zugriff auf diese Einstellungen im XPort hat.
D.h., es ist hier egal, welche Geschwindigkeit man am COM-Port des Redirectors
einstellt. Es zählt nur die im XPort eingestellte Geschwindigkeit.
�ber LAN werden die Daten immer so schnell, wie möglich, übertragen.
In der IDE werden für das Laden von Programmen zwei Geschwindigkeiten genutzt.
1. 19200 Baud, die Standardgeschwindigkeit im Hostmode
2. 57600 Baud für das Laden selbst.
Wenn man im Programm fix 19.200 Baud nutzt, uns dies auch im XPort konfiguriert,
kann man das CC2Net.de-Download-Tool bis V2.24 zum Laden von Programmen
hier einsetzen, wenn man dort 19.200 Baud als Geschwindigkeit wählt.
Das Thema gab's aber z.T. schon im Forum.
Derzeit ist die Version 2.3 des DL-Tools in Entwicklung und im Betatest.
(Interne Versionsnummer 2.29)
Hiermit ist das Laden von Programmen, HEX-Dateien bzw. Download-Makros direkt
über eine Socks-Verbindung möglich. D.h., der COM-Port-Redirector wird hier nicht benötigt.
Man muÃ? nur die IP bzw. den Host und den TCP-Port angeben.
Was nicht über den XPort funktioniert, ist das Laden eines OS.
Um über den XPort mit dem CC2Net.de-DL-Tool V2.3 Programme laden zu können,
ist mindestens OSOPT V3.1b1 notwendig.
Für das Einleiten des Hostmodes ist das Kommando etwas anders.
(Nicht 2x Byte 254, sondern Byte 254 Byte 253)
Daraufhin kann man unterscheiden, ob die Verbindung über einen XPort oder direkt erfolgt.
Dementsprechend wird das Programm mit einem normalen quit beendet (Parameter 1 bis 255),
oder mit dem extended quit (>255), um die Einstellungen von HWCOM auch
im Hostmode beizubehalten.
Allerdings gibt es leider immernoch ein Problem: Die netzwerkbedingten Latenzzeiten.
Da beim �bertragen von Programmen mit 32Byte-Datenblöcken gearbeitet wird, auf dessen
Echo normalerweise gewartet werden mu�, dauert das �bertragen erheblich länger.
Im lokalen LAN ist das zwar noch erträglich, jedoch spätestens, wenn das Programm
über WAN übertragen werden soll, kann man zwischenzeitlich, je nach Programmgrö�e,
eine Tasse Kaffee trinken gehen. ;-)
Ich habe zwar damit experimentiert, die Blockgrö�e zu erhöhen, jedoch funktioniert
eine �bertragung nur bis 64 Byte Blockgrö�e noch zuverlässig.
Die einzige Möglichkeit, das �bertragen wirklich zu beschleunigen, wäre
das Integrieren eines erweiterten Lade-Protokolls inkl. Fehlerkorrektur im OS.
Das wäre aber erheblich extra-Arbeit, was ich zeitlich leider nicht so schnell realisieren kann.
Daher werden ich wahrscheinlich vorerst das Download-Tool in der V2.3 mit den momentanen
Routinen herausbringen, und ein erweitertes Protokoll in einer künftigen OS-Version
erst bei einer weiteren Version des DL-Tools vorsehen. (V2.31 aufwärts)
Prinzipiell kann ich V2.3 des DL-Tools veröffentlichen, sobald ich noch
ein paar "kosmetische" Dinge erledigt habe. (Textmeldungen etc.)
Allerdings bin ich am �berlegen, ob ich noch einen Kennwortschutz für das Laden
über den XPort einbauen soll. Nicht, da� dann jemand über LAN eine CC2 hackt. ;-)
(Die CC2 fragt dann nach einem Kennwort, bevor diese in den Hostmode wechselt.)
Wenn ich diesen Kennwortschutz nicht implementiere, werde ich Version 2.3
wahrscheinlich in etwa einer Woche rausbringen.
Mit dem Kennwortschutz erst eine Woche später.
Gut, das dazu.
Wenn Du bereits eine lizensierte Version des DL-Tools haben solltest, kann ich Dir vorab
die Beta von Version 2.3 zukommen lassen.
MfG André H.
> Mhm... zu früh gefreut aber es geht.
> Leider musste ich feststellen das es nach einem Reset der CC2 nicht mehr funktioniert mit dem Upload,
> denn dann kommt die Meldung : Kein Hostmode?
> Allerdings habe ich dann folgendes festgestellt wie es funktioniert
> 1. CC2 in den Hostmode bringen
> 2. dann den XPORT per Weboberfläche auf 19200baud stellen
> 3. Einmal versuchen das Programm per IDE laden, CC2 wird gelöscht aber Programmladefehler erscheint.
> 4. dann den XPORT per Weboberfläche auf 57600baud stellen
> 5. Nochmal versuchen Programm per IDE laden, CC2 wird fehlerfrei programmiert.
>
> Ist ätzend aber funktioniert........
>
>
> > Naja manchmal kann man sich auch selber helfen^^
> >
> > Nach ca 3h weiterem rumprobieren hab ichs denn doch endlich gschafft.
> > Dann will ich euch die Lösung auch net vorenthalten:
> > In der Systemsteuerung/Gerätemanger habe ich für den virtuellen ComPort von Lantronix folgendes eingstellt:
> > Baud: 57600 !!!!!!
> > Datebbits: 8
> > Parität: Keine
> > Stoppbits: 1
> > Flussteuerung: Keine
> >
> > Das gleiche dann auf der Seite des XPort per Webconfiguration
> > Protocol: RS232
> > Baud: 57600 !!!!!!
> > Datebbits: 8
> > Parität: Keine
> > Stoppbits: 1
> > Flussteuerung: Keine
> >
> > Bei Pack Control alles aus!
> >
> > Flush Mode
> > Flush Input Buffer Flush Output Buffer
> > With Active Connect: Yes With Active Connect: Yes
> > With Passive Connect: Yes With Passive Connect: Yes
> > At Time of Disconnect: Yes At Time of Disconnect: Yes
> >
> > Protokoll TCP der Rest ist bei meine Test egal gewesen.
> > Die Baudrate jedoch ist wichtig :-)
> >
> > Naja evtl hilfts ja noch mal einem.
> >
> >
> >
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: Probs mit CC2 mit Starterboard und XPort (von Alex - 21.08.2007 12:03)Re: Probs mit CC2 mit Starterboard und XPort (von André H. - 2.09.2007 15:50)Re: Probs mit CC2 mit Starterboard und XPort (von Alex - 3.09.2007 10:00)Re: Probs mit CC2 mit Starterboard und XPort (von Alex - 14.03.2007 17:45)