C AT42QT2120 -> GPIO

Janiiix3

Aktives Mitglied
28. Sep. 2013
1.333
10
38
Hannover
Sprachen
  1. ANSI C
  2. C#
Nabend.

Lese ich das richtig, dass ich die Pins auch als GPIO nutzen kann?
Habe an KEY5 (Register Adresse 33) eine LED (Low Active) angeschlossen.
Und ihn versucht auf GPIO um zu programmieren.

Habe folgendes gesendet ->



CodeBox C
28 // I2C Adresse vom Chip
33 // Key5 Register
0b00000001 // Key als Output und auf Low gesetzt


Habe mehrere I2C Teilnehmer (keiner der diese Adresse hat) und bekomme leider diese LED nicht zum leuchten. Habe ich etwas übersehen?

Datenblatt.:
http://ww1.microchip.com/downloads/en/DeviceDoc/doc9634.pdf
 
Hallo Jan,

ich frage nur einmal sicherheitshalber ...

Du sendest auch die Slave-Adresse plus Write-Bit

SLA = 0x1C (28d, 7bit)
W = 0

also 0x38?
 
Wieso 38? Wird nicht bei einem Leseversuch + 1 auf die Adresse gerechnet?
 
Wieso 38? Wird nicht bei einem Leseversuch + 1 auf die Adresse gerechnet?

Du möchtest doch eigentlich schreiben. Das WriteBit ist 0. Die Adresse ist 0x1C (28d)

0x1C+W = 0b00111000
= 0x38 (56d)
 
0x1C+W = 0b00111000
Hm...

0x1C = 28dez ist 0b0001_1100

Wenn man dazu W=0 addiert, ändert sich ja nichts. Daß es sich hier um eine linksorientierte 7-Bit-Adresse handelt (und folglich vorher verdoppelt/linksgeschoben werden muß), ist bis dahin nicht ganz klar.
Der wesentliche Hinweis findet sich in "Section A auf Seite 41" des Datenblattes, genauer A.4 (leider scheint das kopieren/zitieren nicht erlaubt zu sein)...

Meine erste Frage wäre jetzt gewesen, ob Du überhaupt mit dem IC kommunizieren kannst, also plausible Werte lesen, setzen und zurücklesen.

Die oben angegebene Registeradresse 33 ist auch dezimal (allerdings auch als solche ohne 0x.. geschrieben).

Die GPOs scheinen auf maximal 10mA ausgelegt zu sein.

Im Standalone Mode wird explizit von Push-Pull-Outputs (auf den entsprechenden Beinen) geschrieben, im Communication MOde ist (bei entsprechender Konfiguration) nur von General purpose die Rede.
???
 
Guten Morgen zusammen :)
Hm...

0x1C = 28dez ist 0b0001_1100

Wenn man dazu W=0 addiert, ändert sich ja nichts. Daß es sich hier um eine linksorientierte 7-Bit-Adresse handelt (und folglich vorher verdoppelt/linksgeschoben werden muß), ist bis dahin nicht ganz klar.
Der wesentliche Hinweis findet sich in "Section A auf Seite 41" des Datenblattes, genauer A.4 (leider scheint das kopieren/zitieren nicht erlaubt zu sein)...

Bei I2C ist die Adresse eigentlich immer 7bit groß. Sie hat keine 8bit!
Nach dem Startbit folgt die Adresse und danach das R/nW bit.

SLA+W (SlaveAdresse + WriteBit)
Das "+" wird hier keine mathematische Addition sein, sonder zeigt die zeitliche Abfolge.

Ich gehe davon aus, dass sich die Datenblätter an die ursprüngliche Referenz von Philips halten.

Ab und zu sieht man, dass mit 8bit "Adresse" gearbeitet wird, das ist dann die 7bit Adresse mit rechts angehäntem R/nW Bit.
Das sind dann die Schreib- und Lese-Adressen.
Wenn man diese verwendet, hat es softwaretechnisch Vorteile, man spart sich Adresse shiften und R/nW Bit verodern, wenn über das I2C Hardwaremodul 8Bit übertragen wird.

Das sieht man ja zum Beispiel bei Bascom.

Oft wird das mit der Adressierung falsch gemacht, deshalb die Frage danach

Meine erste Frage wäre jetzt gewesen, ob Du überhaupt mit dem IC kommunizieren kannst, also plausible Werte lesen, setzen und zurücklesen.

Ja, das wäre zum Beispiel die LED an/aus Sache, die Jan probiert hat.
Und es geht nicht.

Eventuell gibt es bei dem einen Pin auch Einschränkungen, soweit habe ich nicht ins Datenblatt geschaut.
Ich würde erst mal schauen ob die Adressierung richtig ist. Am Bus sind auch andere Slaves, kann mit denen kommuniziert werden oder geht garnichts?

Dirk :ciao:
 
...Ja, das wäre zum Beispiel die LED an/aus Sache, die Jan probiert hat.
Und es geht nicht...
Wobei dadurch nicht unbedingt klar wird, ob es an der Kommunikation oder der angeschlossenen LED/irgendeiner Konfiguration liegt -->
...Eventuell gibt es bei dem einen Pin auch Einschränkungen, soweit habe ich nicht ins Datenblatt geschaut.
Ich würde erst mal schauen ob die Adressierung richtig ist. Am Bus sind auch andere Slaves, kann mit denen kommuniziert werden oder geht garnichts?...
Deswegen würde ich erstmal irgendein bekanntes Register prüfen; die Chip ID zB (Adresse 00, sollte 0x3E liefern).
Und dann, ob sich ein beschreibbares Register beschreiben und zurücklesen läßt (also zB die GPO-Bits).
Falls der Pin zu schwach für die verwendete LED ist, kann man erstmal mit'nem Multimeter prüfen (was bei 'nem Open Collector-Pin allerdings auch nicht ausreichen würde, ohne Pull-Widerstand).
...Ab und zu sieht man, dass mit 8bit "Adresse" gearbeitet wird, das ist dann die 7bit Adresse mit rechts angehäntem R/nW Bit.
Das sind dann die Schreib- und Lese-Adressen.
Wenn man diese verwendet, hat es softwaretechnisch Vorteile, man spart sich Adresse shiften und R/nW Bit verodern, wenn über das I2C Hardwaremodul 8Bit übertragen wird...
Wobei sich die Frage stellt, ob das ganze tatsächlich im Zielcontroller "gespart" wird, oder ob es sich nicht letztendlich um Compilerkonstanten handelt (die dann in den Programm-Opcodes fest sind (-> LDI...)).
Das geht natürlich nicht, wenn die Adresse(n) zur Laufzeit gesetzt/geändert werden soll - Konstante(n) eben.

P.S.: bei den mir bekannten AVR (mit HW-TWI) wird die 7-Bit-Slave-Adresse (des AVR selbst) auch immer linksorientiert in das TWI (slave) Adress Register (TWAR) geschrieben, und das LSB als General Call Recognition Enable Bit genutzt.

P.P.S.: Wie ist das mit dem TWI (slave) Adress Mask Register (TWAMR)? Das AVR-TWI reagiert dann (ggf) auf mehrere Adressen, da hier gesetzte Bits beim Adress-Match ignoriert werden, ok. Aber was bringt mir das? Oder kann man irgendwo auf die tatsächlich empfangene Adresse prüfen? (Sorry, daß das jetzt etwas OT wird)
 
Moin Moin.

Ich kann es mir ehrlich gesagt nicht vorstellen, dass es an der Adresse liegen soll...
An diesem I2C Bus habe ich bis jetzt erfolgreich eine RTC zum laufen bringen können. Die hat alles getan was ich wollte.

An dem GPIO (KEY5) können max. 10 mA fließen...Ich habe dort einen 560 R mit ner LED verbunden. Das sollte O.k sein.

Meine Frage war es jetzt ob ich was falsch gemacht habe (Source mäßig) um den GPIO5 zu Konfigurieren.
Habe in Register "33Dec" das erste Bit "EN" auf High gesetzt und das zweite "GPIO" auf "0"... laut Datenblatt sollte jetzt "0" Pegel an diesem Pin herschen und die LED zum leuchten bewegen...

Leider nichts...

Das sind meine Routinen.. (Ich arbeite hier mit einem ATxMega256A3BU)



CodeBox C
void twi_init(TWI_t * twiname)
{   
   twiname->MASTER.CTRLB   = TWI_MASTER_SMEN_bm;
   twiname->MASTER.BAUD   = TWI_BAUDSETTING;
   twiname->MASTER.CTRLA   = TWI_MASTER_ENABLE_bm;
   twiname->MASTER.STATUS   = TWI_MASTER_BUSSTATE_IDLE_gc;
}

void twi_write(TWI_t *twi,uint8_t slave_addr,uint8_t reg, uint8_t data)
{   
   twi->MASTER.ADDR   = slave_addr | 0x00;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = reg;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = data;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
}
 
Welchen Wert übergibst du der Funktion für slave_addr?


CodeBox C
void twi_write(TWI_t *twi,uint8_t slave_addr,uint8_t reg, uint8_t data)
{   
   twi->MASTER.ADDR   = slave_addr | 0x00;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = reg;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = data;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
}
 
Welchen Wert übergibst du der Funktion für slave_addr?


CodeBox C
void twi_write(TWI_t *twi,uint8_t slave_addr,uint8_t reg, uint8_t data)
{  
   twi->MASTER.ADDR   = slave_addr | 0x00;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = reg;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = data;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
}

0x1C
 
Bitte probiere einmal diese Routine...



CodeBox C
void twi_write(TWI_t *twi,uint8_t slave_addr,uint8_t reg, uint8_t data)
{   
   twi->MASTER.ADDR   = slave_addr<<1;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = reg;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
   twi->MASTER.DATA   = data;
   while(!(twi->MASTER.STATUS&TWI_MASTER_WIF_bm));
}
 
@Dirk
Hat leider auch nicht funktioniert.. :(
 
Hat leider auch nicht funktioniert.. :(

Schade. Jedenfalls gehe ich davon aus, dass mit der Adresse war nicht richtig!
Die SlaveAdresse (7bit) kommt linksbündig in das ADDR register, Bit 0 ist dann R=1 oder W=0.

Dies hat ürbrigends keine Wirkung:
slave_addr | 0x00;

Ich schaue später nochmal nach, vielleicht hat ja sonst noch jemand Ideen.

Dirk :ciao:
 
Wieso klappt das dann mit der RTC? Bei der Adresse habe ich nichts verschoben und es klappt.. Oder ist es erst bei einer bestimmten Adresse so (wenn evtl. das low_nibble betroffen ist) so?
Vielen dank schonmal ;)
 
Wieso klappt das dann mit der RTC

Eventuell verwendest du gleich eine ReadAdresse bzw. WriteAdresse, dann würde es funktionieren, weil ja die Adresse bereits verschoben und das R/nW Bit vorhanden ist.

define READ 1
define WRITE 0

ADDR = (SlaveAddress<<1) | READ; // Lesen
ADDR = (SlaveAddress<<1) | WRITE; // Schreiben

Ich schau später nochmal.
 
Versuche einmal die ChipID zu lesen (Register Adresse 0, Wert 0x3E)

Register Adresse
START
SLA+W
ACK
0x00 (Adresse)
ACK
STOP

Daten lesen
START
SLA+R
ACK
Datenbyte von RegAdresse 0 lesen (sollte 0x3E sein)
nACK
STOP
 
Sag ich doch schon die ganze Zeit...
Als vorhergehenden Schritt könnte man auch nur die Adresse senden (mit Start, klar), und prüfen, ob der Touch-IC überhaupt ein ACK liefert.
0x1C = 28dez ist 0b0001_1100
Die relevanten sieben Bits müssen aber linksorientiert als Adresse gesendet werden, also eben 0b0011_100x wobei x schreiben oder lesen des nächsten Bytes festlegt. 0b0011_100x ist 0x38 oder 56dez (für x=0, klar).
Verdoppelt, einmal nach links geschoben.
Man könnte auch das R/W-Bit in die Adresse "linksrollen"
Wieso klappt das dann mit der RTC? Bei der Adresse habe ich nichts verschoben und es klappt.. Oder ist es erst bei einer bestimmten Adresse so (wenn evtl. das low_nibble betroffen ist) so?
Welche Adresse soll die RTC denn haben?
Ist die bereits linksorientiert angegeben?
(dann muß ggf nur noch das R/W addiert werden (also hier im Sinne von "Plus eins" rechnen ohne Schieben)

P.S.: Beim lesen der ID über general call darf naturlich nur ein Slave am Bus hängen.
Kannst Du den Bus mit'nem LA loggen?

P.P.S.:
An dem GPIO (KEY5) können max. 10 mA fließen...Ich habe dort einen 560 R mit ner LED verbunden.
Ohne weitere Angaben zur LED...
Bei angenomenen 5V und vernachlässigtem Spannungsabfall über den Pin (bzw den internen Schalter) hätte 'ne durchschnittliche rote LED ca 5..6mA, 'ne durchschnittliche Blaue/Weiße 2,5mA. AFAIK gibts auch Superblaue mit 4,5V Vorwärtsspannung, die hätten dann nichtmal mehr ein mA.
Bei vielen Superhellen LEDs sieht man schon bei derlei geringem Strom was, aber ob das auf Deine konkrete LED zutrifft, mußt Du wissen...
 
Zuletzt bearbeitet:
Ähm... wäre zwar eigentlich 'ne "Idiotenfrage"(*), aber:

Der Chip befindet sich im Communication-Mode? (-> Mode-Pin auf Vss)

(*) Die meisten von uns befanden sich bereits in Situationen, wo man sich ganz gern selbst in anatomisch unmögliche Körperregionen gebissen hätte...
 
@Janiiix3 Du hattest doch mal einen I2C Scanner in C gebastelt (ich finde den Thread grad nicht). Warum lässt du den nicht mal drüber laufen? Denn würdest du zumindest mal sehen wo der Chip antwortet, wenn überhaupt…
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)