Bascom Master - Slave - Slave hängt manchmal

[tenor]

Hallo,
ich konnte die Tage den neuen Teil meiner RGB LED Steuerung in Betrieb nehmen, habe aber mit dem Slave noch ein paar Probleme.
Prinzipiell funktioniert es. Wenn man genauer und länger hinschaut, wieder nicht..
Werden Werte an den Slave (von Atmega 644 an den Atmega 48) gesendet funktioniert das meist nur beim ersten mal korrekt,
wenn sich die Werte dann nach einer Stunde oder so ändern, sollen diese auch an den Slave geschickt werden, dort kommen sie dann oft nicht an.

Ich habe dazu im Master Programm noch eine extra sub die ich mit einem Taster direkt anspreche, daher kann ich dann sehen das auch diese voreingestellten
Werte nicht beim Slave ankommen, (Da beim Slave dann falsche Farben dargestellt werden).

Hier mal der relevante Teil vom Master: (der ganze Code im Anhang, da zu lang)

Pwm_senden:
Start Watchdog
Disable Interrupts
For Zeiger2 = 1 To 6
    If Pwm_wert(zeiger2) <> Lastsend(zeiger2) Then
      Do
         Call Twi_send_byte(&H40 , Pwm_pos(zeiger2))        ' Den Wert zum Slave senden
         Call Twi_send_byte(&H40 , Pwm_wert(zeiger2))
         Try = Try + 1
         Waitms 10
      Loop Until Error = 0 Or Try >= 5
      Error_send = Error
      Lastsend(zeiger) = Pwm_wert(zeiger)                   ' Den Wert merken der zuletzt gesendet wurde
   End If
Next

Ocr2b = Pwm_wert(7)                                         'PWM auch für den Atmega644 setzen
Ocr2a = Pwm_wert(7)                                         'PWM auch für den Atmega644 setzen
Stop Watchdog
Enable Interrupts
Return

Pwm_test:
Start Watchdog
   Pwm_wert(1) = 0                                          'grün rechts
   Pwm_wert(2) = 30                                         'rot rechts
   Pwm_wert(3) = 30                                         'blau rechts
   Pwm_wert(4) = 1                                          'blau links
   Pwm_wert(5) = 30                                         'rot links
   Pwm_wert(6) = 1                                          'grün links
   For Zeiger3 = 1 To 6
      Call Twi_send_byte(&H40 , Pwm_pos(zeiger3))           ' Den Wert zum Slave senden
      Call Twi_send_byte(&H40 , Pwm_wert(zeiger3))
      Waitms 10
   Next
Stop Watchdog
Return

Hier der Code vom Slave:

'Der Atemga 644 steuert einen Atmega 48 der via I²C als Slave angesprochen wird.
'Der Atmega 48 ist für die Erzeugung von 6 PWM Signalen verantwortlich. (2 LED Bänder mit je RGB)
'Den Wert für die PWM Signale erhält er vom Master. 6 Bytes mit den PWM Werten werden für die einzelnen Kanäle übertagen.
$regfile = "m48def.dat"
$lib "mcsbyte.lbx"
$lib "i2c_twi.lbx"

Led_r1 Alias Ocr2b
Led_g1 Alias Ocr0b
Led_b1 Alias Ocr0a
Led_r2 Alias Ocr1a
Led_g2 Alias Ocr1b
Led_b2 Alias Ocr2a

Config Portd = Output
Config Portb = Output
Config Watchdog = 4096

'TWI Konfiguration
Twsr = 0                                                    ' status und Prescaler auf 0
Twdr = &HFF                                                 ' default
Twar = &H40                                                 ' Slaveadresse setzen
Twcr = &B01000100                                           ' TWI aktivieren, ACK einschalten

Dim Twi_control As Byte                                     ' Controlregister lokale kopie
Dim Twi_status As Byte
Dim Twi_data As Byte
Dim Neuesbyte As Byte                                       ' Bytemerker
Dim Pwm_pos As Byte
Dim Pwm_wert As Byte
Dim Pwm(6) As Byte
Dim Position_ok As Byte
Dim Error As Byte

Twi_data = 0
Position_ok = 0
Pwm_pos = 0
Error = 0

'PWM Kanäle konfigurieren
Tccr0a = &B10100001
Tccr0b = &B00000010
Tccr1a = &B10100001
Tccr1b = &B00000001
Tccr2a = &B10100001
Tccr2b = &B00000010

Led_r1 = 1
Led_g1 = 1
Led_b1 = 1
Led_r2 = 1
Led_g2 = 1
Led_b2 = 1

Do
   Start Watchdog
   If Pwm_pos <> 0 And Position_ok = 0 Then
      Select Case Pwm_pos
         Case 1 : Pwm(1) = Pwm_wert
                   Pwm_pos = 0                              ' Ausgabe der PWM Spannung
         Case 2 : Pwm(2) = Pwm_wert
                   Pwm_pos = 0
         Case 3 : Pwm(3) = Pwm_wert
                   Pwm_pos = 0
         Case 4 : Pwm(4) = Pwm_wert
                   Pwm_pos = 0
         Case 5 : Pwm(5) = Pwm_wert
                   Pwm_pos = 0
         Case 6 : Pwm(6) = Pwm_wert
                   Pwm_pos = 0
      End Select
   End If

   Led_r1 = Pwm(1)
   Led_g1 = Pwm(2)
   Led_b1 = Pwm(3)
   Led_r2 = Pwm(4)
   Led_g2 = Pwm(5)
   Led_b2 = Pwm(6)

  '##########################################################################################################
   ' TWI bytes empfangen wenn etwas gesendet wird
   'Neuesbyte = 0                                             ' Merker zurücksetzen
   Twi_control = Twcr And &H80                              ' schauen ob TWINT gesetzt ist - Bit7 von Controlregster
   If Twi_control = &H80 Then
      Twi_status = Twsr And &HF8                            ' Status
      If Twi_status = &H80 Or Twi_status = &H88 Then        ' wurde ein Byte geschickt
         Twi_data = Twdr                                    ' neue Daten merken
         Neuesbyte = 1                                      ' merken das ein neues Byte da ist
      Else
         Error = Twi_status                                 ' Fehler
      End If
      Twcr = &B11000100                                     ' TWINT muss immer gelöscht werden, damit es auf dem Bus weiter geht - TWINT löschen, erzeugt ACK
   Else
      Error = Twi_status                                    ' Fehler
   End If
   '#########################################################################################################
   If Error = 1 Then                                        ' Im Fehlerfall alles zurücksetzen
      Error = 0
      Neuesbyte = 0
      Pwm_pos = 0
      Position_ok = 0
   End If

   If Neuesbyte <> 0 And Position_ok = 0 Then               ' wenn ein neues Byte gekommen ist, dieses an PortD ausgeben
      Pwm_pos = Twi_data                                    ' empfangen Bytes in Array speichern
      Position_ok = 1
      Neuesbyte = 0
   End If
   If Neuesbyte <> 0 And Position_ok = 1 Then
      Pwm_wert = Twi_data
      Neuesbyte = 0
      Position_ok = 0
   End If
   Stop Watchdog
'##########################################################################################################
Loop

Um die Probleme besser in den Griff zu bekommen, bin ich davon weggegangen immer alle Werte in folge zu schreiben, also immer alle 6 bytes für die einzelnen Kanäle. Stattdessen schicke ich jetzt zu jedem Nutzbyte ein Positionsbyte, das der slave zunächst auch richtig auswerten kann..

Hat jemand einen Tipp?Anhang anzeigen aquarium_led_master.bas

 

[LotadaC]

Bist Du Dir sicher, daß Du mit dem Watchdog korrekt umgehst? Zu Bascom kann ich da nichts konkretes sagen, aber normalerweise wird der Hund durch Manipulation eines Watchdog-Kontrollregisters eingestellt/gestartet/gestoppt. Ich denke, daß dazu die Bascom-Befehle Config Watchdog (wobei es da eine default-Vorgabe geben wird), Start Watchdog (läßt den Timer (weiter-)laufen) und Stop Watchdog (hält ihn an) verwendet werden. Um den Hund aber zurückzusetzen, gibts ein eigenen Maschienencode-Befehl (Opcode=1001010110101000) bzw den entsprechenden ASM-Mnemonic: WDR (watchdog reset). Ob Config Watchdog den dann mit zurücksetzt, weiß ich nicht, bei start und stop kann ich's mir ehrlich gesagt nicht vorstellen.

Aber ob das jetzt was mit Deinem Problem zu tun hat...

 

[tenor]

Hallo Lota,
danke für die Mühe, aber ich denke das passt so mit dem Watchdog.
Auf jeden Fall wird er nicht ausgelöst, das könnte man dann am flackern der LEDs sehen.
Hab das aber zur Vorsicht nochmal in der Hilfe nachgesehen:
"After a CONFIG WATCHDOG, you always need to start the Watchdog with the START WATCHDOG statement"

Gruß
Tenor

 

[tenor]

Das Problem scheint am Bus zu liegen und mit dem DS1307 zu tun zu haben.
Wenn ich die Zeit im Menü ändere, dann kann ich Werte senden, ändere ich nochmal die stunde, dann wieder nicht..
Ich kann aber keinen Fehler bei diesen Programmteilen finden.

 

[TommyB]

Moin

Afaik ist der Watchdog auch in Bascom per Default deaktiviert (sonst würden wohl auch geschätzte 80% der Programme dafür nicht funktionieren). Außer natürlich man setzt die Fuses so dass es erzwungen wird dass der immer aktiviert ist.

Das WDR Equivalent in Bascom war meine ich "Reset Watchdog".

Solltest du den Watchdog nicht grade als "Timer" missbrauchen, denn solltest du den auch nicht berühren (der ist eh alles andere als Präzise, also ungeeignet um Zeiten zu generieren), abgesehen selbstverständlich vom Reset (wenn aktiviert).

Das Start / Stop Watchdog innerhalb der Haupt-Programmschleife ist nicht im Sinne des Erfinders. Stop Watchdog sollte eigentlich nie verwendet werden (wenn man den schon verwendet, warum denn deaktivieren?). Starten und denn in der Main Loop resetten. Aber Vorsicht (bei Wait, Sleep & co), nicht dass z. B. bei SLEEP (ich glaube das heißt in Bascom genau so) länger wartet als der Warchdog Intervall eingestellt ist (genügend Interrupts durch z. B. Timer?).

Ich würde den ganzen Watchdog Kram mal raus schmeißen (Config, Start, Stop, Reset, die Fuses sofern gesetzt) und denn noch mal probieren

 

[tenor]

Hi!
Es liegt nicht am Watchdog, den hatte ich erst später hinzugefügt um zu testen, ob der Slave Controller hängt.
Hab an dem Slave kein LCD dran und kann das daher nur schwer überprüfen.

Reset heißt doch im prinzip stoppen und dann wieder starten, das habe ich dadurch ja auch erreicht.
Aber wenn ich mir die Hilfe dazu nochmal anschaue, bekomme ich auch ein Reset durch den erneuten start.

Am Slave ist in der Mainloop halt die Abfrage für den TWI bus, da muß ich den ja auch da rein machen.
Ist mir ohne nur etwas zu unsicher, nicht das der Slave sich wegen dem Bus aufhängt da er ewig auf ein ACK wartet.

Deswegen habe ich das beim master auch nur in der sub drin.

 

[TommyB]

Nicht so ganz.
Soweit wie ich das verstanden hab (ich hab jetzt nicht den Code disassembliert den Bascom generiert, das wär mir eh zu wüst) wird beim Start dem Watchdog auch Strom zugewiesen, also im PRR Register, beim Stop wieder entfernt, ... Ob der Zähler zurück gesetzt wird bei Start/Stop, dazu finde ich keine Angabe. Reset ist ein einziger (Assembler) Befehl der nur den Zähler zurück setzt.

Am besten:

' bli bla blubb mit init und so
Start Watchdog

Main:
    ' der Programmablauf
    Reset Watchdog
Goto Main

Weil, wenn dein Controller nun zwischen Start und Stop in eine Interrupt Service Routine (ISR) springt ist dafür der Watchdog nicht aktiviert, wenn der sich da aufhängt hängt er bis zum nächstem Stromausfall

Ich weiß auch grade nicht wie Bascom intern das mit TWI/SPI handelt. Wartet der Befehl so lange bis Daten eingehen? Dann wäre der Watchdog da sehr Kontraproduktiv. Aber ok, du sagtest ja dass es ohne auch nicht geht, trotzdem nur zur Info

Sonst sehe ich kein Fehler, aber ich hab Bascom auch schon jahrelang nicht mehr angerührt, bin auf Assembler umgestiegen.

 

[Dirk]

Hi Tommy,

Weil, wenn dein Controller nun zwischen Start und Stop in eine Interrupt Service Routine (ISR) springt ist dafür der Watchdog nicht aktiviert, wenn der sich da aufhängt hängt er bis zum nächstem Stromausfall

also der Watchdogtimer läuft, einmal gestartet auch dann weiter, wenn das Hauptprogramm durch eine ISR unterbrochen wird, auch dann wenn eine ISR durch eine ISR unterbrochen wird. Der zum Systemtakt asynchron laufende Timer ist ziemlich hartnäckig Wenn die ISR zu lange benötigt und der Watchdogtimer nicht rechtzeitig zurückgesetzt wird (wdr), dann erfolgt ein Reset. Es ist sogar so, dass man den Watchdogtimer nicht durch eine einzige Assembler-Instruction stoppen kann (sicherheitsrelevant), hier ist eine bestimmte Vorgehensweise notwendig (findet man im Datenblatt, in einer Hochsprache interessiert das nicht).

Anscheinend liegt aber das Problem ja nicht am Watchdog. Dies ist auch ganz einfach auszutesten ... einfach nicht aktivieren

Dirk

 

[TommyB]

Sorry, etwas OffTopic,

also der Watchdogtimer läuft, einmal gestartet auch dann weiter, wenn das Hauptprogramm durch eine ISR unterbrochen wird

Er stoppt den Watchdog ja aber wieder
Und ich orakel mal dass Bascom das schon vernünftig macht und der nach "Stop Watchdog" nicht weiter läuft
Zusammen mit dem Start in der Hauptschleife. Und zwischen Stop und Start kann ja einiges passieren. Übersieht man nur schnell weil es ja nur ein Loop, GoTo, RJMP, was auch immer ist
Aber grade bei Bascom weiß man ja nie so genau wie das im Endeffekt umgesetzt wird, von daher lieber auf Nummer Sicher gehen. Zum testen am besten aus lassen (wie Dirk schon sagte) und später nur ein WDR / Reset Watchdog in der Programmschleife.

Man muss ja auch nicht gleich ein LCD zum debuggen anklemmen. Meist ist die serielle Schnittstelle ausreichend, häufig sogar ein oder zwei einfache LEDs

 

[tenor]

Hab nur im Slave Programm den Watchdog in der Main Loop.
Beim Master habe ich den extra nur in der relevanten Sub Routine zum senden.
Ein Reset ist dort nicht so schön, da ich den ansonsten an mehreren Stellen resetten müsste.
Wenn ich mal länger als 5 Sekunden im Menü bin z.B.

Gestern Abend hatte ich kurz vorm zu Bett gehen einen "kleinen" Erfolg. Zumindest sah es besser aus.
Hatte nur eine 100ms Pause in die Schleife gesetzt.
Richtig einleuchtend ist das für mich aber auch nicht, da er manchmal problemlos damit klar kam. manchmal jedoch wieder nicht...

Wird sich heute und morgen zeigen ob es sich insgesamt besser verhällt.

Dachte eigentlich das wäre egal mit der pause, da die beiden controller ja auf einander warten müssen, also auf das ACK.
Naja, mal sehen

 

[Uwe H.]

Hallo Tenor,

schau mal in meinen aktuellen Beitrag (150m Hardcoremagistrale entstoeren, ab Seite 3). Ich hab dasselbe Problem, dass sich mit einem Atmegaslave am Bus nach 1-6 Lesevorgaengen der Bus aufhaengt. Benutzt Du im Master die I2C-Befehle von Bascom? Les Dir mal die ERR-Variable bei jedem Schritt anzeigen. Bei mir ist sie dauernd auf logisch 1, auch wenn der Bus noch vernuenftig laeuft, was nicht sein sollte. Meine Vermutung ist ein Bug in Bascom, wenn es um die Kommunikation zwischen zwei oder mehr Atmegas geht. Zumindest siehts im Moment danach aus. Ich habe einen Testaufbau auf dem Steckbrett hier mit 10cm Buslaenge. Heute Vormittag werfe ich die Bascom-I2C-Kommandos aus dem Master raus und fahre auch dort direkt ueber die Register. Bis 14.00 poste ich die Testergebnisse. Wir haben das hier gestern Abend schon einmal probiert mit zwei Atmega8 (Master/Slave) und es hat erstmal geklappt. Es war aber schon spaet und ich hatte keine Lust mehr, noch zwei Stunden zu sitzen und das Programm im Loop zu testen, deshalb ist der Test nicht als verlaesslich anzusehen. Heute klemme ich 3 Atmegas als Slaves an den Bus und lese sie im Loop alle 500ms aus. Mit den Bascombefehlen hing der Bus bereits beim zweiten Slave ohne eine logische Erklaerung fest. Mal sehen wie es ueber die Register laeuft. Hast Du einen Logikanalysator?

 

[Uwe H.]

Hallo zurueck Etwas spaeter als geplant aber mit Ergebnissen:

Es liegt mit allerhoechster Wahrscheinlichkeit an Bascom. Warum weiss ich nicht aber nach dem Umschreiben der Schreib-/Leseroutinen auf manuelle Registerfahrt funktioniert alles einwandfrei. Es scheint tatsaechlich so zu sein, dass mit den Bascombefehlen "I2Cstart, I2Cwbyte, etc." im Master/Slavebetrieb mit Atmegas der Bus nach ein paar Durchgaengen haengt. Getestet haben wir mit einem Master und drei Slavecontrollern im Verbund ueber 40min in 500ms Abstaenden zwischen den Lesevorgaengen. Nach jedem Schritt hat das Programm das Statusregister auf einen nichterwarteten Wert geprueft und sollte im Fehlerfall den Status ans Hyperterminal senden. Nicht ein einziger Fehler ist waehrend der 40min aufgetreten.
Mit den Bascombefehlen haengt alles sofort ab dem zweiten Slave fest.

Also schreib dein Masterprogramm um und probier es aus. Aber vergiss nicht, das Ergebnis hier zu veroeffentlichen. Ich wuerd gern wissen, ob bei Dir das Gleiche rauskommt.

Gruesse
Uwe

 

[SickBoy]

Es liegt mit allerhoechster Wahrscheinlichkeit an Bascom.

starke Worte. Kannst du noch sagen, wie hoch die Wahrscheinlichkeit ist?

Warum weiss ich nicht

ach so, dann ist es doch kein Bascom Fehler?

Den Quelltext bist du leider bisher schuldig geblieben, deine Behauptung entbehrt daher der Grundlage.

Auch mit Wiederholung wird eine Aussage nicht wahrer.

SickBoy

 

[tenor]

Hallo,
wow, das der Beitrag nochmal rausgekramt wird

Ja, ich verwende die I2CSend Behfehle, zumindest auf der Master Seite.

Dachte erst mein Problem wäre gelöst, aber nach 2-3 Tagen stürtzt "ein Teil" des Controllers ab.
Sprich die Steuerung der Luft und Temp sind ok, aber PWM fällt komplett aus, und die Farbe bleibt im letzten Zustand stehen.
Hatte leider in den letzten Wochen zu wenig Zeit um mich weiter darum zu kümmern.
Stecker raus und gleich wieder rein und das problem ist erstmal abgwendet.

Hoffe aber das sich das in der nächsten Zeit bei mir wieder normalisiert.

Ich sende nur alle paar Minuten ca. 16 byte also eigentlich fast nichts.
Und ein paar Tage läuft es auch, also ein grober Schnitzer werde ich mir da nicht erlaubt haben.
Aber dennoch muß ich erstmal schauen ob das Problem am Slave oder am MAster liegt.

Gruß
Tenor

 

[StevieL]

Hallo zusammen,

dass das tatsächlich mit den I2C-Befehlen zusammenhängen soll kann eigentlich fast nicht sein. Ich habe hier eine Steuerung mit 7 Slaves, einigen Metern Kabel und einem Master, der die Bascombefehle verwendet. Läuft seit Jahren ohne einen Hänger.

 

[TommyB]

... Läuft seit Jahren ohne einen Hänger.

Denn muss es auch eine Jahre alte Bascom Version gewesen sein die vielleicht (was das angeht) fehlerfrei ist. Aber das sagt ja nichts über die aktuelle aus

 

[dino03]

Hallo,

muß ja nicht am Master liegen. Kann ja auch an den Slaves liegen das die evtl den Master durcheinanderbringen oder was ähnliches.

Gruß
Dino

 

[StevieL]

Hallo TommyB,

da würde ich dir zustimmen, wenn ich nicht immer mal wieder Kleinigkeiten an den Programmen ändern würde. Es kommt immer mal wieder ein neuer Slave dazu.
Die Änderungen werden immer mit der aktuellen Version compiliert. Wobei ...mit der ganz neuen und der Vorgängerversion habe ich bislang nichts an den Programmen geändert. Vielleicht liegt es tatsächlich daran...

 

[Uwe H.]

starke Worte. Kannst du noch sagen, wie hoch die Wahrscheinlichkeit ist?


ach so, dann ist es doch kein Bascom Fehler?

Den Quelltext bist du leider bisher schuldig geblieben, deine Behauptung entbehrt daher der Grundlage.

Auch mit Wiederholung wird eine Aussage nicht wahrer.

SickBoy

Bisher habe ich in diesem Forum nur nette und hoefliche Leute kennengelernt, die meine vollste Wertschaetzung und Respekt verdienen. Deshalb bitte ich Dich jetzt hoeflich auf derartige Ironie in deinen Antworten mir gegenueber in Zukunft zu verzichten. Genau wegen solchen provokanten Texten habe ich mich aus dem Mikrocontroller.net abgemeldet, da bekommt man nur noch solche Antworten, egal ob man Recht hat oder nicht. Nun zu deiner "Frage": Meine Aussage beruht auf Ergebnissen. Drei Tage lang haben wir (mein Arbeitskollege und ich) etliche Tests durchgefuehrt, da wir zur Zeit dasselbe Problem haben wie tenor. Nur bei uns betrifft es einen Kunden und keine private Schaltung bei mir Zuhause.

Seit gestern haben wir die neuen I2C-Routinen (ohne die Bascom-I2C-Befehle) in der Sporthalle installiert, wo wir I2C ueber 150m Kabel mit fast 20 Slavestationen am laufen haben. Auch hier gehts nicht um ein privates Vergnuegen, der Auftraggeber ist die Universitaet fuer Architektur in Krakau. Das System dient als Analyse- und Schulungssystem zur Ausbildung von Architekten im Passiv- und Nullenergie-Gebaeudebau.
Seit der Installation gestern gibts keine nennenswerte Stoerung mehr, sodass wir die Busgeschwindigkeit wieder auf 100kHz erhoehen konnten. Vorher waren staendig und alle paar Minuten Probleme mit Haengern waehrend der Kommunikation, manchmal wollte der Bus garnicht starten.

Die Schaltung vom Kunden laeuft seit Montag mit einer Testroutine ohne Bascom-I2C-Befehle auf meinem Schreibtisch auf dem Steckbrett Tag und Nacht. Kein einziger Haenger bis jetzt.
Daneben laeuft eine identische Schaltung mit Bascombefehlen, seit Montag habe ich dort 840 Fehler im Logger

Fazit:
1. Mit I2Cwbyte blabla gehts nicht im Slaveverband. System haengt entweder sofort oder nach kurzer Zeit irgendwo fest.
2. Mit direkter Steuerung uebers Controlregister (TWCR) gehts wunderbar und ohne jeglichen Haenger.

Nun erklaer mir mal Sickboy, woran das liegt, wenn nicht an Bascom? Was bleibt denn deiner Meinung nach noch uebrig, wenn der eine Befehl funktioniert und der andere, der das gleiche bewirken sollte, Fehler produziert? Meine "starken Worte" sind die Schlussfolgerung von Tatsachen und mein "Warum weiss ich nicht" begruendet sich auf mein Nichtwissen im Bezug auf die detailierten, verschiedenen Auswirkungen der Bascombefehle in den Maschinenregistern (uC). Dazu muesste man ein Programm mal reassembeln und schauen, was da abgeht. Das ich Dir meinen Quellcode nicht zur Ansicht schicke begruende ich damit, dass ich nach gut zwei Jahren taeglicher Arbeit mit I2C weiss, wie man I2C in allen Variationen schreibt und keine Zweifel daran habe, dass ich

Do
I2Cstart
I2Cwbyte Slave_r
I2crbyte Data1
.........
I2Cstop

Wait 10
Loop

beherrsche. Und damit hast Du auch schon mein Testprogramm fuer den Master. Mehr steht nicht drin, denn Auslesen tu ich mit dem Logikanalysator, der mir sofort zeigt, ob meine Routine irgendwo wegen eines Schreibfehlers crasht. Kuck mal in meinen aktuellen Beitrag "I2C Hardcoremagistrale 150m entstoeren", da steht der alte und der neue Code fuer die Schreib-/Leseroutine.



StevieL, hast Du nur Slaves in Form von Atmegas am Bus oder auch I2C-Bausteine? Ich hab vor einiger Zeit ein Master-Slave-System in Form einer Hausautomatik gebaut. Die funktioniert ebenfalls mit den Standardbefehlen, nur haengen da neben den Atmegas noch andere I2C-Bausteine am Bus. Vielleicht hat das irgendeinen Einfluss...?

 

[Uwe H.]

Kleiner Zusatz noch, auf dem Logikanalysator ist folgendes zu sehen:

- Master kontaktiert Slave 1, komplette Routine laeuft durch
- Master kontaktiert Slave 2, Slave schickt ACK, dann crasht die Routine.

Der Crash bei mir kommt also immer, wenn der Master dem zweiten Slave das erste Kommando schicken will. Dabei spielt es keine Rolle, welcher Slave zuerst angesprochen wird. Sprich: Kontaktiere ich zuerst Slave 2 und danach 3 oder 1, crasht die Routine eben an 3 oder 1.

Vielleicht kann ja jemand was damit anfangen?