RN-Speak antwortet nicht auf I2C-Bus

Hallo,

ich habe das RN-Speak Sprachausgabemodul aufgebaut.
Es lassen sich Nachrichten über die Tasten und das Mikrophon aufnehmen und abspielen und auch über die RS232 läuft alles einwandfrei.

Doch leider reagiert das Modul nicht auf die I2C-Bus-Adresse 0x52. Die Jumper sind richtig gesteckt. Die Brücken J1 und J3 sind nicht eingelötet, weil Version 1.1! Das Modul habe ich in den I2C-Bus-Modus umgeschaltet. Es reagiert nicht mehr auf die Tasten wie in der Doku beschrieben.

Habe Direkt an den Pins die Signale von SCL und SDA gemessen und für gut befunden.

Das Modul weigert sich aber beharrlich nach der Adresse 0x52 ein ACK (SDA wird bei Bit 9 der Übertragung nicht auf LOW gezogen) zu senden, woran kann es liegen?

Habe noch andere I2C-Bus-Bausteine am Bus, die alle einwandfrei funktionieren! Den Bus betreibe ich zur Zeit mit 25kHz.

Bin sehr dankbar für schnelle Hilfe

Claus

Hallo,

klingt alles korrekt was du gemacht hast. Was die Jumper an betrifft, da ist in der Readme-Datei, die Firmware in dem mitgelieferten Mega8 gemeint, also nicht mit der Platinen-Versionsnummer verwechseln.
Die neuste Firmware hat die Version 1.3. Diese Nummer steht gewöhnlich auf einem roten Aufkleber auf dem Chip, wird aber bei RESET auch über die RS232 Schnittstelle angezeigt!

Hier gilt dann folgendes wie in der Readme steht:

Zitat:

---

Sollten Sie bereits die neuste Firmware von
RN-SPEAk Version 1.3 erhalten haben
(steht auf dem IC Aufkleber)
dann bitte beachten:

Die eingezeichneten Brücken auf der Bestückungsseite
J1,J2 und J3 müssen alle eingelötet werden!

Sollten Sie eine ältere Firmware besitzen, so
dürfen die Brücken J1 und J3 nicht eingelötet sein!

---

Die ältere Firmware ist von den Funktionen völlig identisch und hat keinen Nachteil, benutzt allerdings andere Leitungen für den I2C. Daher braucht bei älteren Versionen J1 und J3 nicht eingelötet werden.
Die Platine war von Anfang an für beide Varianten vorgesehen.

Also checke das nochmal genau mit der Versionsnummern.
Ansonsten ist eigentlich nur noch zu beachten das die I2C Befehle nicht zu schnell hintereinander folgen. Am betsen während der Testphase nur das Steuerboard und das RN-Speak am I2C-Bus anschließen um erst mal andere Konflikte auszuschließen.
Wenn du dann den Democode nimmst oder einen Auszug, dann sollte es eigentlich keine echten Hürden mehr geben.

Gruß Frank

Hallo,

inzwischen bin ich einen Schritt weiter. Zumindest sendet das Sprachmodul ein ACK auf seine Adresse 0x52. Bei meinen vorigen Versuchen hatte sich das Modul immer schon vom Datentransfer verabschiedet und deshalb nicht mehr geantwortet.

Auf dem Aufkleber steht Version 1.1; über die serielle Schnittstelle wird Version 1.2 gemeldet.

Habe den Datentransfer auf dem I2C-Bus mal genau untersucht. Das beiliegende Bild zeigt die Übertragung eines Bytes ans Sprachmodul. Oben ist das Datensignal SDA und unten das Taksignal SCL zu sehen. Das Sprachmodul antwortet ordnungsgemäß auf die Adresse 0x52 mit einem sauberen ACK. Doch nach dem Senden des Datenbytes 0x59 (01010100B) kommt es zum Komunikationsproblem zwischen dem eingesetzten Controler (80C552 mit "Hardware"-I2C-Bus) und dem Sprachmodul. Der nadelförmige Impuls auf der Clock-Leitung wird vom Controller als 9. Impuls (Bit) gewertet und somit als ACK interpretiert. Für das Sprachmodul ist dies aber kein Impuls. Es versucht wohl einfach die Clockleitung auf LOW zu ziehen um den Master zum Warten zu veranlassen (gemäß I2C-Bus Spezifikationen) doch geschieht dies zu spät, da der Controller bereits den Impuls erkannt hat. Das Sprachmodul hält im folgenden die SDA-Leitung auf LOW um dem Contoller ein ACK zu senden. (Auf das dieser nicht mehr wartet, da schon empfangen) Das anschließende Stop-Signal des Contollers wird vom Sprachmodul nicht erkannt, da die SDA-Leitung immer noch auf LOW gehalten wird.

Wenn mann 2 Bytes zum Sprachmodul sendet ist sehr schön zu erkennen, das Controller und Sprachmodul über die Anzahl der Impulse auf der Taktleitung uneins sind. Wird als 2. Byte der Wert 4 übertragen wird Meldung 8 abgespielt. Der erste Impuls der Controllers für die Übertragung des 2. Bytes wird vom Sprachmodul als das 9. Bit vom 1.Byte interpretiert, so kommt es zu einer Bit-Verschiebung.

Wird in der Version 1.3 exakt die gleiche Software für die I2C-Bus-Routinen verwendet und nur andere Pins belegt?

Ist eine Anpassung der Sprachmodul-Software möglich, so dass sie sich an den I2C-Bus-Standard hält?

Gruß Claus

Hi,

also ich hatte eigentlich auch mit Firmware 1.2 nie Probleme! Ich hab im Haus eine Anwendung mit Sprachnachrichten praktisch seit Monaten im Dauerbetrieb mit RN-control und rnspeak firmware 1.2 laufen - es gab noch nie den geringsten Fehler!
Aber du kannst auch Firmware 1.3 nehmen, da sind völlig andere I2C Routinen drin. Genauer gesagt steuert dort der Controller selbst den I2C-Bus. Die Hardware I2C-Unterstützung des Controllers stellt 100% richtiges Timing zur Verfügung.

Gruß Frank

Wo kann ich mir denn die Version 1.3 downloaden?

Gruß Claus

Guten Morgen,
schick einfach ne Mail mit deiner Realanschrift/damaligen Bestellanschrift oder Rechnungsnummer an robotikhardware.de

Gruß Frank

Hallo Frank,

vielen Dank für die neue Softwareversion 1.3. Habe heute morgen den Controller neu gebrannt.
Nun klappt die Kommunikation absolut einwandfrei! O:)

Ich möchte es nicht versäumen Dir an dieser Stelle ein großes Lob auszusprechen für Deine Einsatzbereitschaft in bezug auf dieses Forum und insbesondere für die Bearbeitung meines persönlichen Anliegens. Natürlich gilt dies auch für die Entwicklung des Sprachausgabemoduls RN-Spreak!
=D> (Klatschender Smilie - Wird in der Vorschau nicht angezeigt O:) )

Gruß

Claus