Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum

Wichtig: Bevor Du wegen einem Problem mit der CC2 postest, stelle sicher, daß Du
die neueste OS-Version, die neuseste Compiler-DLL und die neuesten Modulversionen benutzt!
Beachte, daß sich auf der CD zur CC2-Unit/Station auch jetzt noch die ältesten Dateien befinden!
Es gelten folgende Anleitung und Regeln: Regeln CC2Net.de-Forum
Zurück zum Artikel  (Blaue Felder sind Pflichtfelder)


Name:   UserID: 
 E-Mail:
Kategorie
Betreff
Homepage:
Link-Titel:
Link-URL:
Cookie für Name, UserID, E-Mail, Homepage-URL setzen
(Erspart die Neueingabe bei Beiträgen und Antworten)
(Zum Löschen des Cookies hier klicken)
Ich nutze:
C-Control II Unit
C164CI-Controllerboard
C-Control II Station
CCRP5 mit CC2-Unit (Conrad Roboter)
CC2-Application-Board
CC2-StarterBoard
CC2-ReglerBoard
eigenes Board
original OS     OSOPT_V2     OSOPT V3.0 OSOPT V3.1

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 Günni, > > > das flush() Problem kann man jederzeit nachvollziehen, wenn Du z.B. an einen PC ein längeres > > Datenpaket schickst und dann gleich wieder in eine Funktion reinspringst, die etwas empfangen > > soll und vorher den Buffer flushed. Dann kommt am PC nur ein Teil an. > > Das Problem tirtt nicht auf, wenn Du z.B. nach dem send ein sleep 100; einbaust - also der cc2 etwas > > Zeit zum senden gönnst. > > Ich werde das demnächst einmal testen. > Ich kann mir aber vorstellen, daß es evtl. wirklich zu Timing-Problemen kommen, > aber dennoch alles gesendet wird. Allerdings dann eben zu langsam. > Statt dem <code>sleep 100;</code> sollte aber ein <code>wait swcom.ready();</code> genauso funktionieren. > > > > Dem receive Problem bin ich längere Zeit aufgesessen bis ich dann man die alte Funktion ausprobiert > > habe. Das Problem macht sich auch erst bei einem etwas längen Datenrahmen (bei mir 32 Bytes) > > bermerkbar. > > Ich dachte, Du wüßtest gleich woran es liegt. Aber egal, die alte Funktion tut's auch. > > Das werde ich dann auch testen. > Ich vermute, daß es evtl. dieselbe Ursache, wie beim flush sein könnte. > > > Ob die Probleme auch bei hwcom auftreten habe noch nicht ausprobiert > > Nein, hier treten solche Probleme nicht auf. > Denn ich sende in diversen Anwendungen größere Datenpakete. > Allerdings tritt dann bei höheren Baudraten ein anderes Problem auf: Baudratenabweichung. > > > Was machen die AVR Erweiterungen? > > Die liegen neben mir und warten auf die Firmware. (Ich komme einfach zeitl. nicht dazu.) > Ich muß dabei sagen, daß die 10Bit-AD-Wandler der AVRs echt lausig sind. > Ich bekomme einfach keine stabilen Werte, obwohl ich allen Empfehlungen von Atmel folge. > > Naja, aber eine Erweiterung will ich auf jeden Fall diesen Herbst noch rausbringen: > Ein USB-Interface für den I²C-Bus. Also I²C-Slave und USB-Device. > Das wäre dann sozusagen die Ergänzung zum I2C-COM. > Zusätzlich werde ich noch ein RS232/USB-Interface als kleine Platine anbieten. > > MfG André H.
Dateianhang: (.gif, .png., .jpg, .zip, .rar)
max. 256kB
max. 256kB