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, > > ich bin dem Problem ein Stück näher gekommen. > Das unten beschriebene Verhalten entsteht durch ein Timing-Problem, da ich die Daten zu spät lese. > Da ich den 64-Byte FIFO-Baustein TL16C750 verwende habe ich den Fehler erst an anderer Stelle > gesucht. > Ich initialisiere die I2CCOM mit: > <code>init(1,0,1) </code> > Hierdurch sollte der 64-Byte FIFO Mode aktiviert werden. Zur Kontrolle ob der 64 Byte-Modus > aktiviert ist, habe ich an verschiedenen Stellen im Code das IIR Register des Bausteins abgefragt. > Wenn Bit 5 gesetzt ist, dann ist der 64 Byte Mode aktiviert. > Ich musste leider feststellen, dass ein Aufruf der Funktion > <code>i2ccom.flush(1)</code> > anscheinend den 64 Byte Modus zurücksetzt.Die Frage die sich mir stellt ist nur, wieso das geschieht? > Laut Datenblatt kann Bit 5 des FCR - dies ist Verantwortlich zum setzen des 64 Byte Modes - nur > geschrieben werden, wenn LCR Bit 7 gesetzt ist. Dies wird - soweit ich das i2ccom-Modul lese - auch > in der Funktion init korrekt gemacht. Flush setzt aber eben nicht das LCR Bit 7 vor dem Schreiben des > FCR-Registers, so dass sich am 64 Byte Mode nichts ändern dürfte - tut es aber bei mir. > > Ich verwende bei mir jetzt folgende neue flusch-Funktion die das Problem zumindest für mich löst: > <code> > function flush(byte Port) > { > wait i2ccom._setReg(i2ccom.set8N1|0x80, i2ccom.LCR, Port, i2ccom.COM); > wait i2ccom._setReg(0b00101011, i2ccom.FCR, Port, i2ccom.COM); > wait i2ccom._setReg(i2ccom.set8N1, i2ccom.LCR, Port, i2ccom.COM); > } > </code> > > @André: Solltest Du den Beitrag lesen. Kann es sein, dass ich hier auf ein Problem im i2ccom > Modul gestoßen bin? > > Viele Grüße > > Guido. > > > Ich benutze die CC2 zur Steuerung meines Hauses und bin derzeit dabei ein Toucpanel (HMI) mit in > > dieses System zu Integrieren. > > Das HMI wird mit der CC2 über RS232 verbunden. Das verwendete Kommuniaktaionsprotokoll ist > > Modbus RTU. > > In diesem Protokoll werden variable Datenblocks gesendet, die mit 2 CRC Bytes enden. > > Zur Kommunikation verwende ich das I2CCOM Modul von CC-Tools. Dessen Interruptausgang liegt auf > > P1H3. > > > > <b>Nun mein Problem:</b> > > Der Modbus Master (das HMI) sendet kontinuierlich Statuspakete die ich in der CC2 verarbeite. Es wird > > ein Interrupt ausgelöst und anschließend lese ich den Datenblock aus. > > Zur Unterscheidung, welcher Interrupt durch den FIFO erzeugt wurde hatte ich vor, dass IIR Register > > auszulesen. Sobald ich aber nach Auftreten des Interrupts das IIR Register auslese bekomme ich im > > Empfangspuffer genau ein Byte weniger zurück, wodurch ich CRC Fehler bekomme. > > > > Hier beispielhaft der Code: > > <code> > > loop{ > > wait (ports.get(11)==0); > > receiveCnt=i2ccom.receive(1,received,types.MAX_RTU_MESSAGE_LENGTH+1,types.FRAME_SEPARATOR_TIME); > > } > > </code> > > In diesem Fall erhalte ich z.B. 17 Byte für eine Modbus Frame. > > <code> > > loop{ > > wait (ports.get(11)==0); > > iir = i2ccom.getIIR(1); > > receiveCnt=i2ccom.receive(1,received,types.MAX_RTU_MESSAGE_LENGTH+1,types.FRAME_SEPARATOR_TIME); > > } > > </code> > > Verwende ich diesen Code bekomme ich für den gleichen Frame noch 16 Byte. Woduch in der > > weitern Verarbeitung CRC Fehler entstehen. > > > > Hat jemand eine Idee, was ich falsch mache? > > > > Viele Grüße > > > > Guido
