TWI_DevLockTN Task/Process beim XMega Frage...

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

TWI_DevLockTN Task/Process beim XMega Frage...

 ·  Posted: 14.03.2018 - 19:29  ·  #1
Hallo,

ich hatte eine ganze Zeit nur den USB-Task/Process beim XMEGA am laufen, nun habe ich den Ablauf des Programms erweitert und angepasst.

Und habe immer wieder mal beim lesen / schreiben des TWI_E Müll drauf.
(Vieleicht hat das was mit den Stack-Überlauf aus dem anderen Thema zu tun und ist nur ein Nebeneffekt)

Ich werde jetzt zum testen mal den TWI_E abschalten und auf den Software-TWI umsteigen.

Aber nur zum Verständnis, wenn ich Daten lese oder Schreibe habe ich die ganze Zeit immer die Unterbrechung so verhindert:

Code
  LOCK( MAIN_PROC );
   ReadInput(); // Lese Eingangsspeicher
   UNLOCK( MAIN_PROC );


und

Code
  LOCK( MAIN_PROC );
     WriteOutput(); // Schreibe Ausgänge zur Hardware
   UNLOCK( MAIN_PROC );


Jetzt habe ich im Handbuch den Hinweis auf Devicelock gesehen
"TWI_DevLockTN"! Verstehe ich das richtig, das damit mein "per Hand lock" unnötig ist und dies im Treiber bereits Verwendung findet? Oder muss ich das zusätzlich irgendwo im DEFINE festlegen?
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 - 09:31  ·  #2
Ein Device Lock verhindert, dass Threads gleichzeitig auf die selbe Hardware zugreifen. Auch bekannt als Mutex.
Es sperrt aber nicht den scheduler. Threadwechsel finden weiterhin statt.
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 - 10:26  ·  #3
Quote by Thomas.AC

Ein Device Lock verhindert, dass Threads gleichzeitig auf die selbe Hardware zugreifen. Auch bekannt als Mutex.
Es sperrt aber nicht den scheduler. Threadwechsel finden weiterhin statt.


Das heisst die Unterprogramme werden dann unterbochen (Scheduler), aber die Schreib-/Lesebefehle wie TWIoutC/( usw. werden am Stück abgearbeitet? Ich hatte das im Handbuch so verstanden...
Es werden die laufenden Schreib/Lesebefehle nicht unterbrochen und der Treiber wird für andere Tasks/Proc. gesperrt.

Das hätte dann einen besseren Effekt als meine Variante, da meine Lösung ja den ganzen Scheduler sperrt.

Nur muß ich diese irgendwo deklarieren? Ich Handbuch bin ich dazu leider nicht schlau geworden.
Oder ist das bei empfindlichen Treibern wie I2C/TWI/SPI beim AVRco bereits enthalten?

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 - 11:47  ·  #4
Laut Doku ist das enthalten und passiert automatisch.
Wenn der Treiber im Interrrupt läuft, dann ist das Schreiben und Lesen quasi am Stück. Ansonsten sind aufgrund von Threadwechseln Pausen zu erwarten. Ist das bei I2C ein Problem?
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 - 11:59  ·  #5
Quote by Thomas.AC

Laut Doku ist das enthalten und passiert automatisch.
Wenn der Treiber im Interrrupt läuft, dann ist das Schreiben und Lesen quasi am Stück. Ansonsten sind aufgrund von Threadwechseln Pausen zu erwarten. Ist das bei I2C ein Problem?


Bei jedem Ser.-Datenverkehr könnte eine Unterbrechung mitten im Schreiben oder Lesen Probleme auslösen. Da hier TIMING wichtig ist, wenn ich ein Byte Schreibe, dann darf er nicht nach 6 BITs eine Pause machen. Dies wird wahrscheinlich zum verwerfen dieses Telegra. führen. Wenn er bei dem senden / lesen immer nach jedem kompletten TWIout eine Pause macht und dann ein paar ms später das nächste komplett sendet, ist das kein Problem. (Auf jedenfall bei meinen I2C Teilnehmern)
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 - 12:46  ·  #6
Das ist blöd.
Hab es gerade nachgelesen. Der TWI Master Treiber arbeitet im Polling Verfahren.
Lock und unlock um IO Routinen herum ist aber nicht zu empfehlen, wegen möglichen Timeouts und Deadlocks bei I2C
Wenn man ganz sicher weißt, dass TWIOUT oder TWIINP schnell sind (kleiner ms Systick), dann könnte man
wie folgt vorgehen.
Code

Schedule;
lock;
TWIOUT
unlock;
Schedule; // überflüssig?
lock;
TWIINP
unlock;
Schedule;
lock;
TWIOUT
unlock;
Schedule;



Dann käme der USB Task immer mal wieder zum Zuge.

Hängt das Display auch am I2C?
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 - 15:25  ·  #7
Quote by Thomas.AC

Das ist blöd.
Hab es gerade nachgelesen. Der TWI Master Treiber arbeitet im Polling Verfahren.
Lock und unlock um IO Routinen herum ist aber nicht zu empfehlen, wegen möglichen Timeouts und Deadlocks bei I2C
Wenn man ganz sicher weißt, dass TWIOUT oder TWIINP schnell sind (kleiner ms Systick), dann könnte man
wie folgt vorgehen.
Code

Schedule;
lock;
TWIOUT
unlock;
Schedule; // überflüssig?
lock;
TWIINP
unlock;
Schedule;
lock;
TWIOUT
unlock;
Schedule;



Dann käme der USB Task immer mal wieder zum Zuge.

Hängt das Display auch am I2C?


Nein, das Display läuft auf einen SPI 4Draht-Bus.

Irgendwie scheint sich beim lesen des TWIinputC immer wieder mal etwas zu verschlucken.
Ich erhalte ab und an mal ein $FF beim lesen der IOs vom PCA9555. Das bin ich eigentlich von meinen ATMEGA-Steuerungen mit den PCA9555 nicht gewohnt. Allerdings nutze ich da kein Tasksystem und keine LCD-Graphic-Funktionen

Ich befürchte da ein Task/Process Problem im Ablauf.
Und warum erhalte ich beim lesen eines fehlenden oder nicht richtig antwortenden I2C-Slaves mit TWIinputC dann überhaupt ein $FF zurück? macht das der Treiber? Kann man das irgendwie vor Verwendung prüfen?

Ein TWIstatC() vor dem lesen ist ja auch keine Garantie, das der Teilnehmer beim 2. Lesen dann die Daten richtig liefert oder?

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 - 16:24  ·  #8
Quote
Irgendwie scheint sich beim lesen des TWIinputC immer wieder mal etwas zu verschlucken.

Mit lock und unlock?


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

zu $FF:
Richtig. Bei einer Master-Read-Transmission quittiert das Slave nur das Adressbyte mit einem ACK, danach werden alle Datenbytes vom Master quittiert.
Wenn das Slave meint aufzuhören, dann gibt dieses die SCL und SDA Leitungen frei (deswegen $FF) und wartet auf eine neue Start-Kondition.
Der Master kann das leider nicht feststellen.

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


Keine
  • 1
  • 2
  • Page 1 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   141   155 · Page-Gen-Time: 0.032092s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI