Guten Morgen, ich habe hier ein Problem mit TWI und dem PCF8574P: TWI: TWSR & 0xF8: start 0x08 sla+w 0x18 send data 0x10 SCL - Freq 50kHz, Interne Pullups ( Externe mit 4k7 oder 10k ergeben bei sla+w abwechselnd 0x18 oder 0x20), Low Current Leds am PCF gegen Masse. Aufgebaut ist alles auf einem Breadboard, Spannungsversorgung aus einem Steckerschaltnetzteil mit 5V. Könnt Ihr Euch bitte mal den Code ansehen ? Vielleicht ist da ein großer Bock drin.... Nachtrag: Ich habe gerade gelesen, dass der PCF8574 keine LEDs direkt treiben kann. Wie verträgt sich das mit der Aussage im Datenblatt? The PCF8574 has a low current consumption and includes latched outputs with high current drive capability for directly driving LEDs. Danke und Gruß, Stefan
Hi, ich habe auch direkt am PCF Low Current LEDs und es läuft bestens, also daran sollte es nicht liegen. Zum Programm...kann ich im Moment noch nichts zu sagen. Werden denn Daten überhaupt übernommen vom PCF? Ändern sich Pegel am Ausgang? Ganz wichtig: Externe 10k an SDA und SCL die internen reichen NICHT!
Hallo Harry, kurz zum Programm: Es sollen nur die LEDs am PCF geschaltet werden. Das LCD gibt über die Routine disp_err die Statuscodes aus, wenn sie nicht den Erwarteten entsprechen und beendet das Programm. Die Ausgabe der Fehler funktioniert auch bestens. Verhalten der Schaltung: interne pullups: Startcondition: => ACK (0x08) Adresse+LSB0: => ACK (0x18) Daten: => RepeatedStart (0x10) Der Level der Ausgänge ändert sich nicht. externe pullups: Startcondition: => ACK (0x08) Adresse+LSB0: => abwechselnd ACK (0x18) und NACK (0x20) Daten: => RepeatedStart (0x10) Der Level der Ausgänge ändert sich nicht. Ein ähnliches Problem habe ich auch mit einem EEPROM 24LC32. Das schreiben der Daten nach Adresse+LSB ergibt Repeated Start. Daher denke ich auch nicht dass es an der Schaltung liegt... Gruß, Stefan
Hm, also ich hab mir mal das Datenblatt vom PCF8574 angesehen. Dort ist als Adresse 0x40 angegeben wenn die Adressbits alle auf 0 sind. Sonst so wie evtl. bei Dir alle 1 -> 0x4E Schau Dir vielleicht nochmal das Datenblatt an, die Adresse ist auf jedenfall ganz anders als das was Du im Programm nutzt!
Hallo Harry,
vielen Dank für Deine Mühe!
>die Adresse ist auf jedenfall ganz anders als das was Du im Programm >nutzt!
Das sehe ich anders:
0b00100111 => 0x27 => Adresse ohne R/W Bit
0b01001110 => 0x4E => Adresse mit R/W Bit
(0b00100111 << 1) => 0b01001110 => 0x4E
Ich glaube auch nicht dass der Baustein auf1 | //Sla+W an PCF8574P
|
2 | TWDR = (IO_ADDR << 1); //TWI-Datenregister mit Adresse + W laden |
3 | TWCR |= 1<<TWINT | 1<<TWEN; //Übermittlung starten |
4 | while(!(TWCR & (1<<TWINT))) {}; //auf übermittlung warten |
5 | if((TWSR & 0xF8) != 0x18) //wenn Fehler Ausgabe auf Display |
6 | disp_err(TWSR, 2); |
mit 0x18 bzw. ACK antworten würde, wenn die Adresse nicht stimmt. Ich werde auf jeden Fall mal die LEDs auf low-aktiv umbauen. Das geht definitiv nicht anders. Hätte das Datenblatt genauer lesen sollen. Rein Sicherheitshalber werde ich auch mal direkt die Adresse 0x4E eintragen. Wenn alles nichts bringt werde ich mal mein CRUMB168 Modul nehmen und extrem kurze verbindungen benutzen. Ich halte Dich auf dem Laufenden. Gruß, Stefan
Hallo
0b00100111 => 0x27 => Adresse ohne R/W Bit
0b01001110 => 0x4E => Adresse mit R/W Bit
Was soll denn der Schwachsinn??
Es ist nicht mit/ohne R/W-Bit, sondern das R/W-Bit kann den Zustand 0
oder 1 annehmen.
Dann kommen wir zu den Adressen:
0b01001110
0b01001111
| Das ist das R/W- Bit
||| Das ist die Adresse, die extern an A2,A1,A0 eingestellt sein
sollte.
Harry S. hat also recht mit seiner Aussage 0x40, bei externer Adresse 0.
Gruß
Joachim
Hallo, >Harry S. hat also recht mit seiner Aussage 0x40, bei externer Adresse 0. Das bezweifle ich auch gar nicht. Harry ist warscheinlich über meine Konstante IO_ADDR gestolpert, welche mit 0b00100111 vorbelegt ist. Das ist die 7-Bit Adresse des PCF8574 mit A[0..2] auf 1. Diese verarbeite ich erst mittels (IO_ADDR << 1) zu 0b01001110 entsprechend 0x4E, also schreiben in den PCF. Sollte ich da einen dicken Knoten im Hirn haben lasse ich mich gerne eines Besseren belehren. Gruß, Stefan
Angehängte Dateien:
-
LED.PNG
1 KB
Guten Morgen, ich habe den Fehler gefunden. Das Bit TWSTA im Register TWCR muss manuell gelöscht werden. Mit der Zeile
1 | TWCR &= ~(1<<TWSTA); |
nach dem senden der Deviceadresse läuft alles. Jetzt habe ich ein neues Problem: Der PCF ändert den Zustande der Ausgänge nicht mehr. Auf dem TWI - Bus ist aber alles in Ordnung, zumindest entsprechen die Werte in TWSR den erwarteten. Zugriff auf ein EEPROM nach dem beschreiben des PCF klappt auch. PCF kaputt ? Die LEDs sind wie im Anhang angeschlossen. Gruß, Stefan
Hi, lass doch einfach mal deine Schieberei weg und stell auf Adresse 0x4E und probiers noch mal. Schaden nicht und tut auch nicht dolle weh^^
Hallo Harry, ich habe es mit 0x4E gemacht. Ging auch eine Weile ganz gut. Seit ich jedoch einmal (Ox0f & 0xFF) geschrieben habe, behalten die Ausgänge ihren Zustand auch nach dem Einschalten und beschreiben mit 0xFF. Die Kommunikation auf dem Bus ist in Ordnung. Deshalb vermute ich einen defekt im PCF. gruß, Stefan
Was für eine Last hast Du denn am Ausgang dran? Wenn Du LEDs hast wie hast Du sie angeschloßen und was für Widerstände nutzt Du?
Hallo Harry, ich habe 8 Low - Current LEDs rot von Reichelt angeschlossen. Bestellnummer war glaube ich LED 5mm 2ma RT. Vorwiderstände sist ein Netwerk 8x1k. Ok, 1,6k wären beser, hatte ich aber gerade nicht. Kathoden sind am PCF, Anoden (über Widerstand) an Vcc. Ich hatte das anfangs verkehrt rum. Vielleicht hat der Chip da etwas abbekommen. Im moment ist es halt so, dass der letzte Zusatnd beibehalten wird. Einige LEDs leuchten, einige nicht.... Gruß, Stefan
Hm, es könnte sein das der PCF etwas abbekommen hat kann oder aber am Bus liegen. Welche Geschwindigkeit fährst Du auf dem Bus? Teiler weit genug runter? Zu langsam geht nicht aber zu schnell. Leitungslänge evtl? Mach mal den Test-> Kurze Leitungen, niedriger Takt. Wenn das auch nicht hilft, andere Soft zum Testen. Schlimstenfalls nimm einfach mal die Demo Version von Bascom dort sind diverse I2C Routinen drin. Damit würdest Du zumindest einen defekt des PCFs ausschließen können....
Hallo, Systemtakt ist 8 MHz, TWI-Takt 50 kHz, Leitungslänge < 20cm. Mit den Zeilen
1 | #define SCL_FREQ 50000UL
|
2 | TWBR = (F_CPU/SCL_FREQ-16)/2; |
sollte das schon hinhauen. Am Bus befinden sich der Mega16, ein 24LC32 und der PCF8577. Der Zustand der IOs des PCF ändert sich auch nicht nach Reset oder ab- und anklemmen der Spannungsversorgung. Es leuchten immer die selben LEDs. Wenn ich das Datenblatt des PCF richtig interpretiere sollte nach Reset ein Tri-State Zustand sein. Also müssten spätestens nach dem schreiben von 0xFF alle LEDs aus sein. Die Übertragung scheint zu fünktionieren. Das Programm springt nicht in die Fehlerroutine. Ausserdem lasse ich mir jetzt nach jeder Operation eine Bestätigung auf dem LCD ausgeben. Da hängt also auch nichts. Nichts gegen Bascom, aber ich bin Froh wenn ich BASIC icht sehen muss. Gruß, Stefan
Das mit Bascom seh ich ein..habe es mit zwar damals bei so einer Aktion von Elektor gekauft weil ich dachte es ist vielleicht ganz nett, jetzt nutze ich aber immer noch WINAVR :-/
Ich war einige Zeit als Programmierer (Seiteneinsteiger) bei einem Kommunikationsdienstleister tätig. Da gab es für die Unix - Seite GCC und für Windows C#. Vor 3 Jahren musste ich dann mit VBA arbeiten. Ich dachte mir "kann ja nicht so schwer sein, ist ja dem VB.Net und damit C# recht ähnlich". Das war wohl nix....... :-( Letztens habe ich aus Interesse mit den µCs angefangen. Da musste ich dan feststellen, dass ich den größten Teil von C vergessen hatte. Jetzt rühre ich nix anderes mehr an, es sei denn, ich werde dafür bezahlt. Nochmal kurz zu TWI: Beim einschalten der Spannungsversorgung sind die Ausgänge des PCF Tri-State. Beim Ersten ansprechen des Chips schalten die Ausgänge ein bestimmtes Muster, welches nichts mit dem gesendeten Datenbyte zu tun hat. Nach einem Reset bleibt dieses Muster erhalten. Also denke ich mal, dass der PCF wirklich hin ist. Ich werde mal schauen, ob ich den MCP23008 in der DIP-Version irgendwo bekomme. Asonsten den MCP23016, den gibts bei Reichelt für 1,20 € un kann auch LEDs treiben.... Gruß, Stefan
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.