UART auf I2C Bus - geht das ?

[achim S.]

Hallo
habe so ein Problem. Möchte einen Sensor, der nur ausgibt "korrekt oder nicht korrekt" von UART nach I2C umsetzen. Habe einiges dazu im Netz gefunden, z.B. den FT232. Klingt nicht schlecht. lieber ist mir aber Prozessor, z.B. den Attiny 841. Könnte dann noch eine Adresswahl mit angeben. Frage ist dabei geht das überhaupt und natürlich wie?
achim

 

[LotadaC]

Frage ist dabei geht das überhaupt und natürlich wie?

UART ist üblicherweise Vollduplex zwischen zwei Teilnehmern - I²C ist ein Master-Slave-Bus; für Vollduplex müßtest Du also sowas wie Multi-Master-Arbitrierung vorsehen, und hast außerdem ein Problem(*) wenn beide Seiten gleichzeitig senden wollen.
(*) müßte also auf beiden Seiten in Software geprüft und umgangen werden.

Oder willst Du nur einen I²C-Slave realisieren, der auf einer Seite als I²C-Slave arbeitet, und auf der anderen Seite Vollduplex-UART, und das ganze ggf puffert?
Beim Tiny441/841 liegen SCL und RXD1 auf demselben Bein - Du könntest also nur UART0 in beiden Richtungen verwenden; UART1 nur als Transmitter.
Grundsätzlich sollte der UART schneller sein (können) als I²C.

Der Master müßte den 841 natürlich regelmäßig pollen...

Als der nächste Tiny mit UART und Master-TWI wäre der Tiny2313(A), wenn man I²C über das USI abwickelt.

Oder irgendein Controller mit Software.

Oder einer der X-Cores...

 

[achim S.]

Hallo
die Aufgabe des I2C Slave, z.B. er Attiny 841, soll sein, nur das Auslesen bzw. umsetzen des UART Signals zum I2C Bus. Dabei sollen keine Daten vom I2C zum USART gesendet werden. Möchte nur auswerten wenn der Sensor sagt, ist ok oder halt nicht ok. Keine Abfrage warum nicht oder anderes. Hatte den Ati 2313 auch schon gefunde, stört aber bei dieser verwendung halt USI. Wenn des Bus am Ati 841 belegt ist geht ja die Möglichkeit den UART auf normalen Pins? Pollen ist klar.
Habe im Netz einen Fingerprintsensor gefunden der bis zu 40 Abdrücke speichern kann und über einen eigenen Prozessor zur Auswetung verfügt, Ausgang über UART...
achim

 

[LotadaC]

Der 441/841 hat zwei UARTs, und nur RXD von UART1 liegt auf demselben Bein wie SCL. Nur dort kannst Du also dann nur den Transmitter nutzen. Aber bei UART0 stehen Dir Transmitter und/oder Receiver zur Verfügung, bei gleichzeitiger Verwendung des TWI.

Der 441/841 wäre als 150er SOIC mit 14 Beinen auch deutlich kleiner als der 2313 mit 20 Beinen als 300er SOIC, falls das ein Argument ist.

 

[achim S.]

Das ist ein Argument, da der 841 völlig ausreicht, brauche doch nur wenige Beine. Bleibt nur noch der Rest ....

 

[Hero_123]

welcher Rest

Der 841 soll also Daten vom UART einlesen und per I2C an den Master senden .. korrekt?

Also ein UART Protokoll so umwandeln, dass daraus ein I2C Protokoll wird bzw man das UART-Protokoll für die I2C Übertragung nutzen kann - habe ich das richtig verstanden?

Kann man da nicht ein "Empfangsbyte" des UART nehme und damit den I2C füttern?

 

[LotadaC]

Also ich hab's so verstanden:
Der Tiny stellt sich in beide Richtungen als Slave dar. Ändert sich der Zustand des Sensors, sendet dieser via USART irgendwelche definierten Telegramme. Diese gilt es also zeichenweise zu empfangen, zu puffern und auszuwerten. Als Ergebnis wird quasi der letzte (aktuelle) Zustand des Sensors in einer geeigneten Form im Tiny hinterlegt.
Vom TWI-Master her kann jederzeit 'ne Anfrage kommen, wie der derzeitige Zustand des Sensors ist (im simpelsten Fall einfach SLA+R). Er ACKt dann einfach, und sendet den Status als Antwort.

Ohne die konkreten Sendetelegramme des Sensors zu kennen wird's natürlich schwammig - UART und TWI entsprechend konfigurieren; im RXD-IRQ die empfangenen Bytes zusammenfassen und auswerten; das Resultat zwischenspeichern.

Beim TWI wird auf die Slave-Adresse ein IRQ getriggert. In der ISR wird nun einfach das gespeicherte Resultat ins TWSD übertragen, und anschließend die Clock freigegeben.

 

[achim S.]

Du hasr es richtig verstanden. Es gab mal ICs die so was gemacht, z.B. von (sorry Name vergessen. Die waren auf einem kleinen Board aufgebaut, sind allerdings abgekündigt. spreche immer da von von UART zu I2C zu kommen. Der Sensor hat 4 Anschlüsse. 3,3V, GND, RXD und TXD. Nach Angaben im Netz kann man ein Prozessor programmieren der sowas macht. Keine Ahnung wie, da ich noch nie mit UART geatbeitet habe. Da der Sensor einen eigenen MCU hat und ca. 40 Fingerabdrücke gespeichert werden können, erfolgt bei übereinstimmung wahr scheinlich eine entsprechende Ausgabe. Ist alles erstmal so eine Frage ob das überhaupt geht und sich lohnt, wenn nicht vergesen wir das Thema
achim

 

[LotadaC]

Wenn der Sensor nur UART bietet, solltest Du den vielleicht auch erstmal nur über UART in Betrieb nehmen und damit spielen, bevor Du den Controller dann auf TWI umsetzt. Der grundsätzliche Weg steht ja schon in #7 - also entweder Du denkst jetzt selbst, oder Du ruckst zumindest mal mit dem Datenblatt des Sensors raus...

 

[achim S.]

Habe das Datenblatt angehängt

 

[Hero_123]

Zielführender ist dieser link- mit DEM Datenblatt kann man nix anfangen

AD-013 (Retired !!!) - ADH Technology Co. Ltd.

edit - warum soll man damit nichts machen können??

 

[LotadaC]

Als ersten Test könnte man zB den Sensor direkt über ein Terminalprogramm ansteuern und auswerten (also zB so'n USB-Seriell-Wandler auf 3V3).
Als nächstes könnte man dann auf dieser Basis 'n VB-Programm schreiben - das zusammenstellen der Commandos mit Checksumme usw aus dem Kopf heraus und die Interpretation der Antworten ist ja recht komplex.
Alternativ geht man gleich den nächsten Schritt an: Ein Controller mit zwei UARTs wird zwischen Sensor und PC-Terminal geschaltet.
PC-seitig vereinbart man ein einfacheres Protokoll (Abdruck speichern, Abdruck lesen/vergleichen), der Kontroller verwendet dann sensorseitig das komplexere Protokoll des Sensors...

(P.S.: Hero hat ja 'ne Quelle, u.a. bezüglich des Protokolls verlinkt...)