I2C-Hardcoremagistrale 150m entstoeren :-)

[Uwe H.]

Hatte mein kleines howTo zum reassemblieren ja bereits oben verlinkt - wie beschrieben kommt mein betagter Rechner da an seine Grenzen. Wenn Du das Studio installiert hast, kannst Du es auch selbst reassemblieren, und hier (wenn kein geschützter Code enthalten ist (Deiner oder die lib)) als Code-Block einstellen. Ich selbst habe dieses WE wegen Arbeit nicht viel Zeit, wie's nächste Woche aussieht, kann ich nicht sagen. Aber ich schau in den Pausen mit'm Handy hier mal rein...

Frage noch am Rande: Warum verwendest Du (zumindest in der selbst implementierten Slave-Variante (Case-Struktur mit der Abfrage der Register)) nicht den TWI-Interrupt?

Hast Du meinen Vorschlag, Eeprom-ICs und AVR-Slaves mal zusammen zu testen versucht? (Kann man nach einem erfolgten Eeprom-Zugriff auf den AVR wechseln? Und umgekehrt?)

War das Verhalten jetzt eigentlich (sicher) reproduzierbar? Also hängt sich irgendwas genau dann auf, wenn Du versuchst, etwas von einer 2ten Adresse zu lesen? Immer?

Hallo und sorry fuer die spaete Meldung aber ich bin im Moment nur noch auf Achse :-(

Zu deinen Fragen:
1. Den TWI-Interrupt verwende ich nicht, weil er in meinem Fall nicht noetig ist und andere zeitkritische Programmablaeufe (DHT-22 Abfrage ueber Timer und Bitwait) stoeren kann. Da TWI nach dem Senden der Slaveadresse sowieso auf eine Slavereaktion wartet, kann man das bequem ueber Polling steuern und antworten, wenn der Slave wieder im Leerlauf ist.

2. Nein, bin noch nicht dazu gekommen, werd es aber machen.

3. Ja, das Verhalten ist reproduzierbar. Er haengt grundsaetzlich ab dem zweiten Slave, egal in welcher Reihenfolge oder mit welchen Adressen man die Slaves anspricht.
Wir haben jetzt ca. eine Woche lang die neue Software in der Sporthalle am laufen (ohne I2C-Befehle) und bis jetzt kein einziger Haenger. Hab extra im Server eine Mailfunktion integriert, die mir bei jedem Fehler ne Mail schickt. Registriert werden:

- Haenger in der Kommunikation (I2C haengt fest, Watchdog loest aus)
- Statusregister (Master) hat nicht erwarteten Wert
- Uebertragene Daten sind unplausibel (Out of Range)

Innerhalb einer Woche hab ich jetzt taeglich einen Fehler registrieren koennen, der Slave Nr. 3 betraf und als Out of Range registriert wurde. Grund des Fehlers ist die Bustopologie. Das Kabel von Slave Nr.3 geht vom Hauptkabel ab und durch zwei Ventilationsraeume mit extremen Stoereinfluessen. Obwohl meine Kabel sehr gut geschirmt sind, faengt er ab und zu mal einen Spike ein und interpretiert ihn als Clocksignal, was zu einer Bitverschiebung bei Data fuehrt. Ein erneutes Abfragen loest das Problem.

Aber suma sumarum laeuft der Bus fehlerfrei. Vorher hatten wir mehrmals pro Stunde einen Watchdog-Overflow, jetzt keinen einzigen mehr. Der Unterschied ist zu krass um uebersehen zu werden.

 

[Uwe H.]

Ich denke eher, daß ich den Mischmasch erzeugen lasse (wie gesagt ist mir nicht ganz klar, was Uwe als Bascom-Mastercode verwendet). Ob's bei den Einstellungen irgendwelche Defaults zum TWI gibt, hab ich nicht nachgesehen, wäre natürlich möglich.

Korrektur: "I2cinit" ist auch Software

"Config Twi" beschreibt das BitRateRegister und das Twi-StatusRegister (Status=0, Prescaler...) - hier wird also die Geschwindigkeit der Hardware eingestellt

"I2cinit" legt nur die beiden vorher zugewiesenen Pins auf Tristate (Config Scl/Sda erzeugt keinen Code) - Software

"I2start" usw schubsen diverse Bits/Bytes, die entsprechenden Bits (Config Scl/Sda) des entsprechenden Port-Registers werden direkt manipuliert (SBI/CBI). Software.

Die Software-Routinen verwenden 'ne Zeit(vernichtungs)Schleife fürs Timing.
Meiner Meinung nach sollte das Config Twi hier einfach keinen Effekt haben, aber auch nicht stören. Der Rest ist SW-Twi (wo wird das Tempo (für die Zeitschleifen) festgelegt?)

So wie ich den Code gepostet habe verwende ich ihn zum Testen. Das Originalprogramm aus der Halle kann und darf ich nicht zur Verfuegung stellen. Es waere auch unnoetig, da wir den Fehler bereits auf die Bascom-Routinen eingegrenzt haben. Config TWI muss ich schreiben, sonst laeuft der Bus auf 200kHz

 

[LotadaC]

So wie ich den Code gepostet habe verwende ich ihn zum Testen...

Du hast eben nur einzelne Schnipsel gepostet... ich hatte dann das oben gepostete Programm zusammenkopiert (aus irgendwelchen Deiner Schnipsel, und mit von mir selbst willkürlich gewählten (da sonst fehlenden) Variablendefinitionen). Dein Originalprogramm brauchen wir ja auch gar nicht, wenn wir denselben "Fehler" mit einem "veröffentlichbaren" Testcode erreichen...

... Es waere auch unnoetig, da wir den Fehler bereits auf die Bascom-Routinen eingegrenzt haben...

... oder auf eine falsche Verwendung der Bascom-Routinen - andererseits hast Du das Problem mittels eigener Routinen und Hardware-TWI ja bereits umgangen... MICH wurmt es bei sowas allerdings immer, wenn ich den Fehler trotzdem nicht finde...

...Config TWI muss ich schreiben, sonst laeuft der Bus auf 200kHz

Das zB ist mir komplett unbegreiflich; kommentiere ich die entsprechende Zeile raus, verschwindet logischerweise:

...
    17:  Adress_w = 8
0000004F  LDI R24,0x08		Load immediate 
00000050  STS 0x0060,R24		Store direct to data space 
[B][color=red]    24:  Config Twi = 100000
00000052  LDI R23,0x00		Load immediate 
00000053  OUT 0x01,R23		Out to I/O location 
00000054  LDI R23,0x10		Load immediate 
00000055  OUT 0x00,R23		Out to I/O location[/color][/B] 
    26:  I2cinit
...

also genau die 4 Zeilen, folglich verschieben sich dann auch die Adressen von direkten Jumps/Calls. Aber ansonsten ändert sich nichts im Code, insbesondere nicht die (in Z geladenen, und dort runtergezählten) Wartezeiten.
Config TWI manipuliert nur das TWI-Bitratenregister, und den Prescaler im TWI-Statusregister (eben um die entsprechende Frequenz des Hardware-TWI vorzubereiten), nebenbei wird der Status auf 0 gesetzt.
Es wird aber nie in irgendeiner Weise auf das TWI-Controlregister zugegriffen (was ja eine entsprechende Aktion im HW-TWI auslösen würde).
Die verwendeten Beine werden in Software manipuliert, und zwar in beiden Versionen (mit und ohne Config TWI) komplett identisch...
(also auch timingtechnisch identisch)

 

[dino03]

Hallo,

ich glaube ich kann da ein wenig was lüften ...

aus Beitrag #43 ...

Das zB ist mir komplett unbegreiflich; kommentiere ich die entsprechende Zeile raus, verschwindet logischerweise:

...
    17:  Adress_w = 8
0000004F  LDI R24,0x08		Load immediate 
00000050  STS 0x0060,R24		Store direct to data space 
[B][color=red]    24:  Config Twi = 100000
00000052  LDI R23,0x00		Load immediate 
00000053  OUT 0x01,R23		Out to I/O location 
00000054  LDI R23,0x10		Load immediate 
00000055  OUT 0x00,R23		Out to I/O location[/color][/B] 
    26:  I2cinit
...

also genau die 4 Zeilen, folglich verschieben sich dann auch die Adressen von direkten Jumps/Calls. Aber ansonsten ändert sich nichts im Code, insbesondere nicht die (in Z geladenen, und dort runtergezählten) Wartezeiten.
Config TWI manipuliert nur das TWI-Bitratenregister, und den Prescaler im TWI-Statusregister (eben um die entsprechende Frequenz des Hardware-TWI vorzubereiten), nebenbei wird der Status auf 0 gesetzt.
Es wird aber nie in irgendeiner Weise auf das TWI-Controlregister zugegriffen (was ja eine entsprechende Aktion im HW-TWI auslösen würde).
Die verwendeten Beine werden in Software manipuliert, und zwar in beiden Versionen (mit und ohne Config TWI) komplett identisch...
(also auch timingtechnisch identisch)

und der Quellcode aus Beitrag #38 ...

Ausgehend von den letzten Beiträgen hatte ich dieses Bascom Programm zusammengesetzt:

$regfile = "m32def.dat"
 $crystal = 4915200

 $baud = 9600
 $hwstack = 70
 $swstack = 70
 Dim Adress_w As Byte
 Dim Adress_r As Byte
 Dim Access_code As Byte
 Dim Data_t11_msb As Byte
 Dim Data_t11_lsb As Byte
 Dim Data_t12_msb As Byte
 Dim Data_t12_lsb As Byte
 Dim Data_t13_msb As Byte
 Dim Data_t13_lsb As Byte
 Adress_r = 9
 Adress_w = 8

'...............................................................................

 Config Scl = Portc.0
 Config Sda = Portc.1

 Config Twi = 100000

 I2cinit

 '--- Messung starten---

I2cstart
 I2cwbyte Adress_w
  I2cwbyte &HCC
   I2cstop

Waitms 200

'--- Daten abrufen ---

I2cstart
 I2cwbyte Adress_r
  I2crbyte Access_code , Ack
   I2crbyte Data_t11_msb , Ack
    I2crbyte Data_t11_lsb , Ack
     I2crbyte Data_t12_msb , Ack
      I2crbyte Data_t12_lsb , Ack
       I2crbyte Data_t13_msb , Ack
        I2crbyte Data_t13_lsb , Nack
I2cstop

(Jaja, da fehlt das End. tut hier aber nichts zur Sache...)

Ich habe mit der Zeit gelernt das BASCOM ohne die folgende Zeile ...

$lib "i2c_twi.lbx"                                          ' Bibliothek fuer Hardware-TWI einbinden

nur Software-TWI macht und nicht die Hardware einsetzt.

Das hat Cassio glaube ich schonmal geschrieben und der Ursprung davon kam glaube ich von Markus oder Thomas (Knickohr). Muß irgendwo hier im Forum drinstehen.

EDIT: Aus der Bascom-Referenz ...

'The chip will work in TWI/I2C master mode
'Connected is a PCF8574A 8-bits port extender
$regfile="M8def.dat"        ' the used chip
$crystal= 4000000           ' frequency used
$baud= 19200                ' baud rate
$lib"i2c_twi.lbx"              ' we do not use software emulated I2C but the TWI
Config Scl =Portc.5         ' we need to provide the SCL pin name
Config Sda =Portc.4         ' we need to provide the SDA pin name

Bemerkung (Kopf) aus der Lib:

copyright = MCS Electronics
www = http://www.mcselec.com
email = avr@mcselec.com
comment = BASCOM-AVR TWI master library
libversion = 2.0.7.5
date = 12 Okt 2007
statement = No SOURCE code from the library may be distributed in any form
statement = Of course this does not applie for the COMPILED code when you have a BASCOM-AVR license
statement = Based on ATMEL application note
history = This lib can replace the i2c.lib when your chip has TWI(M8,M128 etc)
history = removed interrupt bit as there is no ISR in this lib that services the interrupt
history = NOTE that no PULL UP is required for the TWI
history = i2cinit DDR set before pull up

(No SOURCE code ... was ich auch nicht mache. Nur den Infotext)

Ich hoffe mal das hilft euch weiter.

Gruß
Dino

 

[LotadaC]

Ist das denn nicht die zu kaufende lib?

Daß alle (von mir verwendeten) Befehle Software-TWI erzeugen, ihatte ich ja schon geschrieben - nur Config TWI manipuliert die Hardware Register.
Um die SCL-Frequenz im SoftTWI festzulegen ist "Config I2Cdelay= value" zu verwenden, wobei value als Prescaler den Maximalwert von 1MHz runterteilt.

So jetzt wirds interessant - verwendet man das mit einem anderen value als 5 (=200kHz=default), verändern sich die Timings (Zeitschleife, und teilweise NOPs im Code)... ABER ...

In der Hilfe zu Config I2cdelay steht, daß es Bestandteil der I2C.lib ist... also werden diese Routinen von dort automatisch verwendet...
Was ist mit i2cstart/stop/r/wbyte, wo werden die definiert?

Hmm... irgendwo hab ich mal gelesen, daß Bascom Befehle (?) (erst im Quellcode selbst?) erst in den eingebundenen libs sucht, dann diversen Standard-libs. Kann wer das bestätigen?
Dann könnten i2cstart & co natürlich ganz anders übersetzt werden, wenn man vorher irgend'ne lib konkret einbindet...

Also nochmal... wir brauchen hier wirklich ein konkret verwendetes Test-Code-Beispiel (ohne Uwe's geheime Hallenroutinen - nur alles, was mit der Kommunikation zu tun hat, und auf freien Bibliotheken basiert).

 

[Uwe H.]

Config Twi manipuliert TWBR und die letzten Bits im TWSR. Aufs Controlregister hat es keinen Einfluss. LotadaC, wir reden aneinander irgendwo vorbei In meinem Beitrag vom 04.09.2013 um 17:18 hab ich beide Testcodes gepostet. Einen der funktioniert und einen der haengt. Aber beide beinhalten die gleiche Aussage im Code. Auch habe ich geschrieben, dass ich es mit und ohne die I2C-Bibliothek geprueft habe und bei beiden Config-Varianten der Fehler auftritt. Der Fehler tritt auch auf, wenn Du TWBR manuell einstellst, solang du nur anschliessend die Bascom-Befehle nutzt. Was die Bibliothek angeht: Benutzt man sie nicht und konfiguriuert ueber Config SDA/SCL hat man Software-I2C. Beide Varianten (Hardware- und Software-I2C) hab ich seit zwei Jahren ohne Probleme am laufen.

 

[LotadaC]

So, fügt man " $lib "i2c_twi.lbx" " mit ein, wird auf die TWI-Hardware zugegriffen. Was genau geschieht, hab ich noch nicht eingesehen - allerdings werde ich hierzu keine konkreten Sachen posten (siehe Dinos Hinweis).
Das ganze geht übrigens trotz Definition der Pins (welche hier allerdings auch die Hardware Pins sind - was da passiert, wenn man andere nimmt, hab ich noch nicht probiert.)

Ein und denselben Slave kannst Du aber beliebig oft (mit der fehlerhaften Version) ansprechen, korrekt?

 

[Uwe H.]

So, fügt man " $lib "i2c_twi.lbx" " mit ein, wird auf die TWI-Hardware zugegriffen. Was genau geschieht, hab ich noch nicht eingesehen - allerdings werde ich hierzu keine konkreten Sachen posten (siehe Dinos Hinweis).
Das ganze geht übrigens trotz Definition der Pins (welche hier allerdings auch die Hardware Pins sind - was da passiert, wenn man andere nimmt, hab ich noch nicht probiert.)

Ein und denselben Slave kannst Du aber beliebig oft (mit der fehlerhaften Version) ansprechen, korrekt?

Mit einem Slave geht es auch nur ueber eine begrenzte Anzahl von Versuchen gut. Der Rekord lag glaub ich bei viermal nacheinander auslesen (im Abstand von ca. 5 sek).

 

[LotadaC]

In Deiner eigenen funktionierenden Lösung in #25 pollst Du das Twint in einer separaten Subroutine (denk ich mal - Twi_int_wait) - einfach durch warten auf das Flag, oder noch mehr?
Bascom macht das mit der Lib (Hardware) da ja ähnlich (Vergleiche das später), hier gibt es aber auch noch ein timeout (wird ein Bit in R6 gesetzt). Wo das dann ausgewertet wird, hab ich noch nicht gesucht.

Wenn Du mal einen definitiv mit diesem Fehler behafteten Testcode zusammenstellen könntest, würde ich nach dem compilieren versuchen, daß Timeout aus dem Reassemblat zu entfernen...

 

[Uwe H.]

In Deiner eigenen funktionierenden Lösung in #25 pollst Du das Twint in einer separaten Subroutine (denk ich mal - Twi_int_wait) - einfach durch warten auf das Flag, oder noch mehr?
Bascom macht das mit der Lib (Hardware) da ja ähnlich (Vergleiche das später), hier gibt es aber auch noch ein timeout (wird ein Bit in R6 gesetzt). Wo das dann ausgewertet wird, hab ich noch nicht gesucht.

Wenn Du mal einen definitiv mit diesem Fehler behafteten Testcode zusammenstellen könntest, würde ich nach dem compilieren versuchen, daß Timeout aus dem Reassemblat zu entfernen...

Da bin ich wieder. Sorry wenn ich nicht sofort zurueckschreibe aber ich hab zur Zeit Hoellenstress zuhause weil Ich bin nochmal Vater geworden



Am 12. ist unser Sohn geboren worden, leider mit einer Blutanomalie, weil wir feindliche Blutgruppen haben. Zur Zeit liegt er in einer speziellen Kinderklinik, die etwas weiter entfernt ist von uns und wo ich jeden Tag hinfahre. Ausserdem ist er per Kaiserschnitt geholt worden, sprich meine bessere Haelfte liegt ebenfalls im Krankenhaus und verlangt nach Gesellschaft. Deshalb Entschuldigung fuer etwaige Verspaetungen aber zur Zeit komme ich nur noch Nachts zum Arbeiten. Am Wochenende kam auch noch die Schwiegermutter mit der halben Familie vorbei, um auf die Gesundheit unseres Kleinen zu trinken. Jeder hier, der polnischen Wodka kennt, weiss, wie man sich nach 2 Litern auf vier Koepfe verteilt am naechsten Tag fuehlt

LotadaC, ich polle das TWINT in der Hauptroutine und steuer das Timeout (in der Halle z.B.) ueber einen Timer. Antwortet der Slave nicht, wird er uebersprungen und fertig. Mit den Bascombefehlen haengt die Routine fest. Hier die problembehaftete Masterroutine mit den original Bascombefehlen:

 $regfile = "m8def.dat"
 $crystal = 8000000

 $swstack = 70
 $hwstack = 70
 $framesize = 70

 Config Sda = Portc.4
 Config Scl = Portc.5

 Config Twi = 100000

 I2cinit


 Dim Buffer As Byte                                         'Dummy-Variable zur Aufnahme der Ablesung



 I2cstart
  I2cwbyte &H10                                             'Slave Nr.1 - W_adresse
   I2cwbyte &HCC                                            'Kommando "Messung starten"
    I2cstop

 Waitms 100

 I2cstart
  I2cwbyte &H20                                             'Slave Nr.2 - W_adresse
  'ACHTUNG: Bereits hier haengt der Bus in 99,9% aller Faelle fest.
  'Die Adresse von Slave Nr.2 wird bereits nicht mehr uebertragen
   I2cwbyte &HCC                                            'Kommando "Messung starten"
    I2cstop

 Waitms 100

 I2cstart
  I2cwbyte &H30                                             'Slave Nr.3 - W_adresse
   I2cwbyte &HCC                                            'Kommando "Messung starten"
    I2cstop


 Wait 2

 I2cstart
  I2cwbyte &H11                                             'Slave Nr.1 - W_adresse
   I2cwbyte Buffer , Ack                                    '1.Byte empfangen
    I2cwbyte Buffer , Ack                                   '2.Byte empfangen
     I2cwbyte Buffer , Ack                                  '3.Byte empfangen
      I2cwbyte Buffer , Ack                                 '4.Byte empfangen
       I2cwbyte Buffer , Ack                                '5.Byte empfangen
        I2cwbyte Buffer , Ack                               '6.Byte empfangen
         I2cwbyte Buffer , Ack                              '7.Byte empfangen
          I2cwbyte Buffer , Ack                             '8.Byte empfangen
           I2cwbyte Buffer , Ack                            '9.Byte empfangen
            I2cwbyte Buffer , Nack                          '10.Byte empfangen
    I2cstop


 Waitms 100

 I2cstart
  I2cwbyte &H21                                             'Slave Nr.2 - W_adresse
   I2cwbyte Buffer , Ack                                    '1.Byte empfangen
    I2cwbyte Buffer , Ack                                   '2.Byte empfangen
     I2cwbyte Buffer , Ack                                  '3.Byte empfangen
      I2cwbyte Buffer , Ack                                 '4.Byte empfangen
       I2cwbyte Buffer , Ack                                '5.Byte empfangen
        I2cwbyte Buffer , Ack                               '6.Byte empfangen
         I2cwbyte Buffer , Ack                              '7.Byte empfangen
          I2cwbyte Buffer , Ack                             '8.Byte empfangen
           I2cwbyte Buffer , Ack                            '9.Byte empfangen
            I2cwbyte Buffer , Nack                          '10.Byte empfangen
    I2cstop


 Waitms 100

 I2cstart
  I2cwbyte &H31                                             'Slave Nr.3 - W_adresse
   I2cwbyte Buffer , Ack                                    '1.Byte empfangen
    I2cwbyte Buffer , Ack                                   '2.Byte empfangen
     I2cwbyte Buffer , Ack                                  '3.Byte empfangen
      I2cwbyte Buffer , Ack                                 '4.Byte empfangen
       I2cwbyte Buffer , Ack                                '5.Byte empfangen
        I2cwbyte Buffer , Ack                               '6.Byte empfangen
         I2cwbyte Buffer , Ack                              '7.Byte empfangen
          I2cwbyte Buffer , Ack                             '8.Byte empfangen
           I2cwbyte Buffer , Ack                            '9.Byte empfangen
            I2cwbyte Buffer , Nack                          '10.Byte empfangen
    I2cstop

 End

 

[LotadaC]

So...
erstens: Herzlichen Glückwunsch, und trotz allem alles gute!
zweitens wollte ich nicht drängeln, sondern nur wissen obs überhaupt, und dann wie hier weitergehen soll. Also mach Dir keinen Kopf wegen Verzögerungen und so. Ist Dein Projekt.
drittens nutzt Du hier die lib nicht, also Software. Wäre das mit Hardware-TWI auch so?
Wenn ich das nachher noch schaffe, jage ich das durch Bascom und dann das Studio, und nehm's morgen mit in die Bahn...

Nachtrag: bei mir schmeißt Dein Code so lauter Fehler beim compilieren (mit und ohne lib).
Ich hab jetzt das reassembliert, und morgen gut 5 Seiten dichtgepackte Lektüre.

 $lib "i2c_twi.lbx"
 $regfile = "m8def.dat"
 $crystal = 8000000

 $swstack = 70
 $hwstack = 70
 $framesize = 70

 Config Sda = Portc.4
 Config Scl = Portc.5

 Config Twi = 100000

 'I2cinit


 Dim Buffer As Byte                                         'Dummy-Variable zur Aufnahme der Ablesung



 I2cstart
  I2cwbyte &H10                                             'Slave Nr.1 - W_adresse
   I2cwbyte &HCC                                            'Kommando "Messung starten"
    I2cstop

 Waitms 100

 I2cstart
  I2cwbyte &H20                                             'Slave Nr.2 - W_adresse
  'ACHTUNG: Bereits hier haengt der Bus in 99,9% aller Faelle fest.
  'Die Adresse von Slave Nr.2 wird bereits nicht mehr uebertragen
   I2cwbyte &HCC                                            'Kommando "Messung starten"
    I2cstop

 Waitms 100

 I2cstart
  I2cwbyte &H30                                             'Slave Nr.3 - W_adresse
   I2cwbyte &HCC                                            'Kommando "Messung starten"
    I2cstop


 Wait 2

 I2cstart
  I2cwbyte &H11                                             'Slave Nr.1 - W_adresse
   I2cwbyte Buffer                                          '1.Byte empfangen
    I2cwbyte Buffer                                         '2.Byte empfangen
     I2cwbyte Buffer                                        '3.Byte empfangen
      I2cwbyte Buffer                                       '4.Byte empfangen
       I2cwbyte Buffer                                      '5.Byte empfangen
        I2cwbyte Buffer                                     '6.Byte empfangen
         I2cwbyte Buffer                                    '7.Byte empfangen
          I2cwbyte Buffer                                   '8.Byte empfangen
           I2cwbyte Buffer                                  '9.Byte empfangen
            I2cwbyte Buffer                                 '10.Byte empfangen
    I2cstop


 Waitms 100

 I2cstart
  I2cwbyte &H21                                             'Slave Nr.2 - W_adresse
   I2cwbyte Buffer                                          '1.Byte empfangen
    I2cwbyte Buffer                                         '2.Byte empfangen
     I2cwbyte Buffer                                        '3.Byte empfangen
      I2cwbyte Buffer                                       '4.Byte empfangen
       I2cwbyte Buffer                                      '5.Byte empfangen
        I2cwbyte Buffer                                     '6.Byte empfangen
         I2cwbyte Buffer                                    '7.Byte empfangen
          I2cwbyte Buffer                                   '8.Byte empfangen
           I2cwbyte Buffer                                  '9.Byte empfangen
            I2cwbyte Buffer                                 '10.Byte empfangen
    I2cstop


 Waitms 100

 I2cstart
  I2cwbyte &H31                                             'Slave Nr.3 - W_adresse
   I2cwbyte Buffer                                          '1.Byte empfangen
    I2cwbyte Buffer                                         '2.Byte empfangen
     I2cwbyte Buffer                                        '3.Byte empfangen
      I2cwbyte Buffer                                       '4.Byte empfangen
       I2cwbyte Buffer                                      '5.Byte empfangen
        I2cwbyte Buffer                                     '6.Byte empfangen
         I2cwbyte Buffer                                    '7.Byte empfangen
          I2cwbyte Buffer                                   '8.Byte empfangen
           I2cwbyte Buffer                                  '9.Byte empfangen
            I2cwbyte Buffer                                 '10.Byte empfangen
    I2cstop

 End

P.S.: Bascom Version 2.0.7.3.001

 

[Uwe H.]

Danke fuer die Glueckwuensche
Ob mit oder ohne lib, das Problem tritt bei beiden Faellen auf.

 

[LotadaC]

Wenn Du irgendwann mal Zeit und Lust hast, kannst Du ja mal exakt meinen Code aus dem letzten Beitrag testen. Wenn der auch diesen Effekt aufweist (wovon ich ausgehe), müssen wir irgendwie versuchen, nach jedem twistart, stop, wbyte... Bit2 von R6 auszuwerten. Indem man einen Pin abhängig davon ansteuert, und das ganze mit'nem LA mitloggt - klar, was ich meine?

Kommt es irgendwo zu 'nem Timeout, wird dieses Bit (über das T-Flag) gesetzt, bisher habe ich aber noch nichts gefunden, wo das ausgewertet wird.

 

[dino03]

Hi Uwe,

Da bin ich wieder. Sorry wenn ich nicht sofort zurueckschreibe aber ich hab zur Zeit Hoellenstress zuhause weil Ich bin nochmal Vater geworden

Anhang anzeigen 5926

na denn auch von mir herzlichen Glückwunsch!
Schonmal Gehörschutz für die Nächte bereitgelegt?

Gruß
Dino

 

[Uwe H.]

Hi Uwe,


na denn auch von mir herzlichen Glückwunsch!
Schonmal Gehörschutz für die Nächte bereitgelegt?

Gruß
Dino

Hahahaha Schlimmer als in den letzten Monaten wirds sicher nicht. Meine bessere Haelfte hat die letzten Monate dermassen laut geschnarcht, dass ich entweder gar kein Auge zugemacht hab oder alle halbe Stunde davon wach geworden bin Letztendlich hab ich tatsaechlich mit meinen Gehoerschutz-Kopfhoerern, die ich noch von meiner Arbeit am Flughafen hab, geschlafen. Eigentlich die ideale Loesung, man hoert wirklich nichts mehr. Nur leider auch nicht den Wecker

 

[TommyB]

Letztendlich hab ich tatsaechlich mit meinen Gehoerschutz-Kopfhoerern, die ich noch von meiner Arbeit am Flughafen hab, geschlafen. Eigentlich die ideale Loesung, man hoert wirklich nichts mehr. Nur leider auch nicht den Wecker

Whoah du hast ne Marktlücke gefunden!
Lärmschutz-Mickeymäuse mit integriertem Wecker für die ruhige Nacht

Von mir auch alles Gute