TWI_DevLockTN Task/Process beim XMega Frage...

  • 1
  • 2
  • Page 2 of 2
pvs-deck
PowerUser
Avatar
Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1341
Registered: 02 / 2009
Subject:

Re: TWI_DevLockTN Task/Process beim XMega Frage...

 · 
Posted: 15.03.2018 - 18:39  ·  #9
Hallo Thomas.
Quote by Thomas.AC

Mit lock und unlock?

Ja, aber erst seit ich das Display mit dem Graphics reingenommen habe. Vorher war das nie ein Problem.

Quote by Thomas.AC

Wie hoch ist dein TWI-Speed?
Wie sind die Werte deiner Pullups?
Kapazität an SDA und SCL?


Speed bei BR100 und BR400, mit SoftI2C funktioniert das gar nicht zuverlässig, nur mit viel Zwangs NOPs :-(
Die Steuerung besteht aus 3 Ebenen, der XMEGA befindet sich in der Mitte. An beiden Enden der I2C-Leitung je 10k dadurch habe ich auf den Leitungen je 5k. Keine Kapazitäten, nur kleine Filter L's für hochfrequente Störungen zwischen den Leiterplatten. Das mache ich schon seit Jahren so und bin damit schon bei mehren EMV-Prüfungen ohne Probleme duchgekommen.
Ich vermute irgendwie das es etwas mit dem LCDGraphic und den Task/Process zu tun hat,
da ich davor keine Probleme hatte, auch die Signal-Quallität auf dem I2C-Bus ist klar und sauber zu erkennen (Oszi).

Quote by Thomas.AC

Idee, um das zu Erkennen:
Den letzten IO beim PCA9555 auf GND legen, damit das entsprechende I2C Byte nicht FF sein kann.

Ja, genau so habe ich es jetzt gemacht, ich habe zum Glück auf allen 3 PCA9555 Pins frei ;-)

Liest er an diesen PINs eine 1, verwerfe ich das Byte, mache eine kurze Pause und lese erneut ein. Läuft jetzt schon seit Stunden ohne Probleme durch.

Thorsten
Thomas.AC
Benutzer
Avatar
Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013
Subject:

Re: TWI_DevLockTN Task/Process beim XMega Frage...

 · 
Posted: 15.03.2018 - 19:34  ·  #10
Cooler workaround! :thumbright:

Mal sehen was da mit dem Graphics rauskommt,
scheint ja irgendwo ein Bug zu sein.
pvs-deck
PowerUser
Avatar
Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1341
Registered: 02 / 2009
Subject:

Re: TWI_DevLockTN Task/Process beim XMega Frage...

 · 
Posted: 15.03.2018 - 20:41  ·  #11
Quote by Thomas.AC

Cooler workaround! :thumbright:

Mal sehen was da mit dem Graphics rauskommt,
scheint ja irgendwo ein Bug zu sein.


Ich habe mal zum Test die Lock/Unlock beim Lesen und Schreiben auf dem I2C rausgenommen.
Das ist eine absolute Katastrophe! Alle 4-5s erhalte ich ein $FF, ich denke da knallt die Task/Process Steuerung voll rein und macht Probleme. Schade, hätte gerne darauf verzichtet.

Ich werde es aber etwas optimieren und ein Function dafür erstellen.

Aktuell:
Code
    TWIoutE(I2CUNIT1, PCA_ReadRegsiter0);  // LeseBefehl InputIO senden
     TWIinpE(I2CUNIT1, inbuffer);     // Lese Inputbyte


Da ich erst auf das Leseregister zugreife mit einen TWIoutE() und kurz danach TWIinputE() ausführe, werde ich die Locks um die beiden Funktionen aufbauen, so kann der Scheduler im Rest der Subroutine immer mal wechseln.

In etwa so:
Code
  Lock;
    TWIoutE(I2CUNIT1, PCA_ReadRegsiter0);  // LeseBefehl InputIO senden
     TWIinpE(I2CUNIT1, inbuffer);     // Lese Inputbyte
  Unlock;
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: TWI_DevLockTN Task/Process beim XMega Frage...

 · 
Posted: 16.03.2018 - 12:58  ·  #12
Hallo Thorsten,

bei konkurrierenden Zugriffen auf IOs, z.B. durch zwei Prozesse/Main etc,
muss ein Zugriff geschützt werden, den kein einziger Hardware Treiber lässt
solche Zugriffe zu denn diese sind nicht re-entrant.

rolf
pvs-deck
PowerUser
Avatar
Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1341
Registered: 02 / 2009
Subject:

Re: TWI_DevLockTN Task/Process beim XMega Frage...

 · 
Posted: 16.03.2018 - 14:30  ·  #13
Quote by rh

Hallo Thorsten,

bei konkurrierenden Zugriffen auf IOs, z.B. durch zwei Prozesse/Main etc,
muss ein Zugriff geschützt werden, den kein einziger Hardware Treiber lässt
solche Zugriffe zu denn diese sind nicht re-entrant.


Hallo rolf,

genau deswegen Lese und Schreibe ich auf die I2C Hardware nur in einen einzigen Prozess.
Aber scheinbar haut da trotzdem ab und an was rein, evtl. ein Interrupt, keine Ahnung :-(

Die Function TWIinputC() gibt ja einen BOOL als Erfolg zurück, wie wird dies sichergestellt? Kann man sich auf dieses Bool verlassen? Kommt das als Erfolgsmeldung direkt von der I2C-Hardware?

Thorsten
  • 1
  • 2
  • Page 2 of 2
Selected quotes for multi-quoting:   0

Registered users in this topic

Currently no registered users in this section

The statistic shows who was online during the last 5 minutes. Updated every 90 seconds.
MySQL Queries: 15 · Cache Hits: 14   96   110 · Page-Gen-Time: 0.027313s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI