Druckbare Version
Hi
habe da ein Problem mit dem lieben PCF8574AP Baustein. Folgendes Verhalten
Schreiben:
Start OK
Slave Adresse OK
Data Byte ->Status 30=DataByte transmitted NOT ACK has been received
Lesen:
Start OK
Slave Adresse-> Status 48 = SLAe+R transmitted NOT ACK has been received
Hat da jemand Erfahrungen mit? Mache zum ersten Mal mit I2C rum. Weis hier aber nicht mehr weiter. Wäre für jede Hilfe dankbar.
Gruß
Peter
Hi
Komich. Nachdem bei mir die addy gestimmt hat, hat auch alles weitere gestimmt.
Welchen Status haben deine AINs?
Aber die Slaveaddy ist ok.
Bist du sicher, dass dein 8574 noch ganz ist?
Wie hoch sind deine Pullups?
Beschreib mal dein System genauer, bitte.
Ganz liebe Grüße,
Tobi
Hallo Tobi
AINs kann ich mir jetzt leider nichts drunter vorstellen.
Die PullUps haben 10k. ATMega32 mit 16MHz. TWBR=72=100KHz, TWAR=0xFE,TWCR=0x45. Adresse des 8574=0x7E.
Ich habe mal einen neuen 8574 eingebaut. Gleiches Ergebnis.
Reicht die Beschreibung oder fehlt noch was wichtiges?
Vielen Dank für die schnelle Antwort.
Liebe Grüße
Peter
Hi Peter!
Mit dem HD-TWI kennt sich der Florian besser aus (liebe Grüße! ;) ); aber das dürfte soweit OK sein.
Die AINs... Die heißen beim 8574 A0, A1 und A2.
Wie sind die bei dir? LOW oder HIGH?
Und was hast du mit dem DAW-Ausgang gemacht?
Kurz... (ich weis...) ...wie hast du den 8574 beschaltet?
Ganz liebe Grüße,
Tobi
Hi Tobi
also A0,A1,A2 liegen auf +5V. Daher die Adresse 0x7E. Pin 8 = GND, Pin 16 auf +5V. Die Ausgänge gehen zum Roboternetztwerk standart Steckerport (Wannenstecker), also 1-8 P0-P7, Pin 9 = GND, Pin 10= +5V. Der Stecker ist leer. Ich wollte erst mal sehen, dass das Teil überhaupt richtig antwortet.
Liebe Grüße
Peter
Hi
ich habe in der Zwischenzeit mal in einer Schleife von 0-254 alle Adressen als Slave Adresse gesendet. Ich bekomme bei jeder Adresse ein TWSR=18 = OK.
Kann das denn richtig sein???
Liebe Grüße
Peter
Hi Peter!
Nein!! Da stimmt was nicht.
Ich würde die I/Os des 74 mit 4,7K nach VCC "UpPullen".
Irgendwo steckt ein Fehler.
Und der liegt recht sicher nicht am 8574.
Sind das nciht die letzten 3 bit vor dem RW, die man mit den As verändern kann? Mein 8574 hat mit den 3As auf Masse die Adresse 0x40.
Da ist irgendwas faul. In welcher Sprache programmierst du?
Ganz liebe Grüße,
Tobi
Hi Tobi
Es gibt den 8574P mit Adresse 0x40 und den AP Typ mit Adresse 0x70. Ich habe den AP Typ. Die I/Os des 8574 sind übrigens alle High. Ich habe auch mal einen 24C65 (I2C EEPROM) eingesetzt und angesprochen. Absolut gleiches Verhalten. Mit einer Leuchtdiode am SCL/SDA sehe ich, das der ATMega arbeitet. Nur das Ergebnis ist nicht OK. Ich bin mittlerweile ziemlich sicher, das meine Softwareansteuerung nicht funzt. Probehalber habe ich den Hardware I2C auch mal deaktiviert und es mit der Ansteuerung der eingebauten I2C Routinen des CAVR C-Compilers probiert. Funzt auch nicht. Ich werde das nachher mal hochladen. Ich habe auch mal die Foren durchstöbert und einige Routinen für den GCC Compiler gefunden. Ich werde jetzt mal mit allen gängigen Compilern BASCOM, ICC AVR und GCC versuchen, das Ding zum laufen zu bringen. Leider sagt einem I2C nicht, was nicht stimmt. Es gint lediglich ein NACK. Messen kann man auch nichts. Sicher habe ich da irgendwo einen Fehler, aber welchen?. Erst mal vielen Dank für die Hilfestellung. Ich werde mich nach meinen Versuchen mit den diversen Compilern noch mal melden.
Liebe Grüße
Peter
Hi Peter!
Hm. Gestern Abend ist mir was eingefallen:
-> Sendest du eine Start- und eine Stopbedingung?
Dumme Frage ich weis; aber daran könnt's liegen....
Wenn nämlich die Adresse 0 gesendet wird, antworten alle Slaves am Bus. Und sowas wird's sein...
Ich denke auch, dass es am Code liegt.
Oooppss... AP hab ich übersehen. Sorry! :oops:
Hast du ein Oszi zur Verfügung? Dann check' mal, ob ein Signal genau SO
aussieht:
Bild hier
Du brauchst nicht alle Compiler durchprobieren... das muss auch mit dem funzen.
Die Emulation von BASCOM bekomme ich auch nur schleppend zum Laufen...
Ich werde das demnächst auch mal auf mich nehmen, mit dem HD-TWI...
Allerdings unter BASCOM...
Viel Glück!
Tobi
Hi Tobi
nein, einen Osci habe ich leider nicht. Aber die Led flackert. Deshab gehe ich mal davon aus, dass es wohl so etwa aussehen wird. Aber mir ist da noch was eingefallen. Die PullUps habe ich direkt an dem Prozessor liegen. In den diversen Bildern sehe ich sie als Terminatoren. Kann dass einen Einfluß auf die Funktion haben?
Gruß
Peter
HI Peter!
Was um Gottes Willen sind Terminatoren?
Bild hier
Aber nichtdoch!
Die Widerstände SOLLEN laut Phillips nahe am Master liegen.
Und es ist EGAL, wie sie aussehen, Hauptsache es ist für jeden Kanal einer da, der nach VCC zieht. Vorgeschalgener Wert: 4,7KOhm.
Die Kanäle müssen über einen Widerstand (versteht sich) nach VCC gezogen werden, das ist alles.
Haben der M32 und der 74 die gleiche Masse?
Ganz liebe Grüße,
Tobi
Hi Tobi
Terminatoren sind Abschlusswiderstände. Sie terminieren die Leitung. Gibt es vor allem bei SCSI und im 10Net (10MBit Netzwerk).
Die beiden haben die gleiche Masse. Ohne etwas an dem Prog gemacht zu haben, kriege ich jetzt beim ReadPort des 8574 den Status TWSR=40=SLA+R transmitted ACK received. Danach hängt sich das Teil auf. Also irgentwie ist bei mir absolut der Wurm drin. Ich werde jetzt noch mal alles kontrollieren. Ich melde mich dann noch mal.
Liebe Grüße
Peter
mit was programmierst du eigentlich?
könntest du mal den Code posten?
HI
Naja; mach's lieber so, wie du's jetzt hast.
Wie gesagt:
- Startbedingung?
Kommt beim lesen auch was brauchbares raus?
Ganz liebe Grüße,
Tobi
Hi
Nochwas: schau mal in den Fusebits! Hast du irgendwelche Kompatibilitätsmodi aktiviert?
Leibe Grüße,
Tobi
Hi Tobi
die Fusebits stehen bei mr so:
cksel3..0=0, SUT0=0,SUT1=1,BODEN=BODLEVEL=1,BOOTRST=1,BOOTSZ0.. 1=0,EESAVE-CKOPT-JTAGEN-OCDEN=1. Ich habe aber mit AVR Studio 4 gesehen, das es wohl noch eine Reihe anderer gibt. Die sind über Ponyprog aber nicht zu sehen. Meinst Du einen dieser Fusebits?
Liebe Grüße
Peter
HI Peter!
Schalte mal "On-Chip debugging" und das JTAG Interface aus.
(Wenn sie nicht schon aus sind.)
*EDIT*
Hast du auch die richtige Clock ausgewählt, also den Quarz?
(CKSEL)
Funzt's unter BASCOM?
Code wäre schon hilfreich...
Ganz liebe Grüße,
Tobi
Hi Tobi
JTAGEN=1=aus.Verquere Logik von Atmel. Leider finde ich nicht die Stelle, an der ich meinem Beitrag etwas beifügen kann. Das es geht, habe ich ja am "Terminator" und Deiner Grafik gesehen. Ich werde Dir mal dad PGM per eMail schicken.
Liebe Grüße
Peter
Hi
Habe gerade sie Source bekommen...
Also:
>#define PCF8574 0x40
- Ich dachte du hast einen AP?!
Oh mon Dieu AVR-C... da muss ich mich erstmal reinlesen...
Ganz liebe Grüße,
Tobi
Hi Tobi
hinzufügen geht nicht über Kurzantwort. Über Antwort schreiben geht es.
Anbei die Fusebits und das PGM
Liebe Grüße
Peter
HI Peter!
Hm. Ist das C mit Zügen zu C++?
*nuransicversteh* *c++buchauskram*
Mit AVRStudio kann man sich die FuseBits viel schöner anschauen.
Musst einfach auf den kleinen STK-Button klicken.
Und dann bitte das JTAG ausschalten; Habe zwar keine Hoffnung, dass das was hilft, aber mach' mal...
So... *codeweiterles*
Wo hast du eigentlich die main()?!
Ganz liebe Grüße,
Tobi
HI
In der Funktion TWI_Robot setzt du zwar das TWBR, aber nicht den TWI-Prescaler.
Den musst du auf 1 setzen; dann kannst du berechnete Werte einstellen.
z.B. 15 für 400KHZ
...ich habe mal ne Forme umgeformt........
Oder täusch ich mich da?
*EDIT
Ja, das tue ich; hast du gemacht;
*Nadel weitersuch*
*
Achso: Es wäre hilfreich-er, wenn du den main, mit nur den benötigten Funktionen schicken würdest. Denn wenn ich jetzt alle Funcs durchsehe, die z.T. die gleiche Funktion haben, bin ich noch ne Weile beschäftigt......
Ging das?
ganz liebe Grüße,
Tobi
Hi Tobi
es klappt jetzt. Nachdem ich einige Teile des Programmes umgestellt habe und ein repeated start eingefügt habe. Danach habe ich mein PCF8574_test nochmal laufen lassen und er hat den auf 0x70 gefunden. Ich hatte gestern die Adresse per DIP-Switch geändert und heute nicht mehr daran gedacht. Getestet habe ich aber weiter auf 0x7F. Dumm gelaufen für mich.
Der JTAG war aus. Du erinnerst Dich, verdrehte Logik von Atmel 1=aus, 0=an
Ich füge die lauffähige Version mal ein. Gelesen wird mit dem Aufruf Portwert = PCF8574_read(subadresse des PCF8574 von 0-7)
geschrieben mit dem Aufruf
PCF8574_read(subadresse des PCF8574 von 0-7, Portwert)
Wie gesagt geht das PGM von einem AP Type mit Hauptadresse 0x70 aus.
Bei einem P Typ muß lediglich die 0x70 in 0x40 in der Funktion
PCF8574_sendAdrRW()
geändert werden.
Nein, das ist kein C++, sondern der ganz normale CAVR C-Compiler. Er weicht aber ziemlich vom GCC oder ICC AVR C-Compiler ab. Ich finde die Dialektflut der C-Compiler auch nicht gerade toll, aber was will man machen. Ich habe mir den halt vor ein paar Jahren mal gekauft. Da war das GCC Projekt noch nicht so weit wie heute.
Nach dem Erfolg mit dem PCF8574AP habe ich ein EEPROM 24C65 getestet. Das läuft bis einschließlich lesen des ersten Byte. Danach ist Pumpe. Ich habe aber in anderen Artikeln gesehen, dass der Baustein Page weise angesprochen wird. Kann man bei dem nicht einzelne Byte lesen oder schreiben? Naja, werde ich auch noch herauskriegen.
Erst mal vielen Dank für Deine Hilfe.
Ganz ganz liebe Grüße
Peter
Hi Peter!
Super, dass das jetzt funzt! Wie gesagt, den dialekt habe ich nicht besonders verstanden.
Hast den Fehler ja auch selber gefunden!
Bei den EEPROMs muss ich leider Passen, da muss ich mich auch erst belesen.
Liebe Grüße,
Tobi
Hi Tobi
ich bin auch mit dem EEprom halbwegs klar gekommen. Ich habe zwei Stück davon. Laut TWI klappt jetzt alles wunderbar. Die Daten sind allerdings Schrott schreiben 0xegal, lesen 0xff. Beim zweiten schreibe ich 0x50 und bekommen 0x8A und beim zweiten Read ist hängen im Schacht.
Das sind aber alte Bauteile, die ich noch rumliegen hatte. Ich bin also nicht sicher, ob die noch OK sind. Werde mir am Montag mal neue besorgen.
Ich wünsche Dir noch ein schönes Wochende.
Ganz liebe Grüße
Peter
Hi
Ich war schon froh, als ich die Softwareemulation von Bascom zum Laufen gebracht habe, und das Dingen ACK gesendet hat.......
Dir auch ein schönes Wochenende!
Ganz liebe Grüße,
Tobi