Software-I2C vs. HW-I2C

Hallo,

ich sitze gerade vor der Aufgabe ein uC Board zu bauen, basierend auf dem MSP430. Ich möchte einerseits gerne einen I2C-Bus nutzen. Daher habe ich die F169er Variante ins Auge gefaßt. Andererseits würde ich gerne 2 RS232 Schnittstellen nutzen. Aber wie ich das Datenblatt verstehe, schießen sich diese 3 (seriellen) Schnittstellen zwar nicht pin-mäßig jedoch aber konfigurationsmäßig aus.

Irgendwo habe ich gelesen, dass man einen I2C-(single-master)-Bus auch in Software realisieren kann?! Dazu bräuchte ich dann ja vermutlich nur

2 Portpins?! Stimmt es, dass der Hardware-I2C-Bus beim MSP430 einen Fehler hat? In der Doku schreibt TI aber nichts dazu... .

Hat jemand eine Ahnung, ob man den Code dazu irgendwo schon mal einsehen kann? Wie stark wird der Prozzi mit dem Emulieren ausgelastet?

Könnte man auch alle drei Schnittstellen (s.o.) verdrahten und dann im Betrieb zwischen einer RS232 und dem I2C toggeln?

Christian

Reply to
Christian Schulz
Loading thread data ...

Christian Schulz schrieb:

ur=20

n=20

Hallo,

bei Phytec wird beim miniMODUL167 ein Software I2C Bus mit nur 2=20 Portpins gemacht, aber nur zum Anschluss von einer RTC, daher also keine =

so hohe Prozessorbelastung. Beispielcode gibt es beim Kauf von Modulen=20 auf CD dazu.

Bye

Reply to
Uwe Hercksen

Ja, bei mir geht es (zumindest in der ersten Phase) auch um eine RTC...

Christian

Reply to
Christian Schulz

Uwe Hercksen schrieb:

Das macht nix.

I2C ist sowieso recht langsam (früher 100 kHz, heute meist 400 kHz), und wenn man eh auf die Daten vom Peripherieteil warten muß, würde auch eine "Belastung" des Prozessors während dieser Zeit nicht stören. (Zeitkritische Sachen laufen währenddessen eben im Hintergrund mit Interrupts weiter.)

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß
Reply to
Tilmann Reh

Software I2C geht wundebar. Aber...

Was bei solchen Lösungen zu bedenken ist: Die I2C Routine braucht Zeit. (Das meiste braucht wohl die delay Routine wegen des arschlangsamen Protokolls). Und soll sie sicher sein, darf Sie eben nicht von einem anderen Interupt unterbrochen werden. Wenn da also noch andere Schnittstellen int-maessig bedienst werden sollen, kann da was verlorengehen, weil der int ja gesperrt ist. Also muss man sich immer auf etwas priorisieren. D.h. wenn die RS232 sauwichtig ist, muss halt das Software I2C Protokoll unterbrochen werden, und damit eventueller Datenverlust in Kauf genommmen werden.

Das passiert mit Hardwareperipherie nicht, zumindest wenn man alles richtig macht.

MIKE

Reply to
M.Randelzhofer

M.Randelzhofer schrieb:

I2C hat zwar minimal-Zeiten aber keine maximal-Zeiten. Ich kann also (als Master grundsätzlich und als Slave eingeschränkt) den Bus beliebig lange anhalten. Es dürfte also bei Unterbrechungen Interrupts keine Datenverluste geben.

--
Matthias Weißer
matthias@matwei.de
 Click to see the full signature
Reply to
Matthias Weißer

Prinzipiell richtig, aber eben keine universale Lösung. I2C ist multimasterfähig, und eventuell braucht ein anderer Master ein Device, das länger als nötig blockiert wird. Für eine einfache EEPROM Anbindung eventuell vernachlässigbar.

Mike

Reply to
M.Randelzhofer

M.Randelzhofer schrieb:

Die Frage des OP zielte eindeutig auf ein Single-Master System. Außerdem sollten ISR generell so kurz wie möglich sein, was auch die möglichen "Pausenzeiten" innerhalb der I2C-Bearbeitung begrenzt.

Nicht nur eventuell, und in den meisten anderen Anwendungen auch. Multi-Master I2C ist in der Praxis übrinx eher selten.

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß
Reply to
Tilmann Reh

Hallo,

Man kann die Delay Routinen aber auch als Timer laufen lassen so das man eine Art Multithreading hat. Also Timerinterrupt erzeugt Interrupt (niedriger Prioritaet) der dann, je nach anstehender Aufgabe und vergangener Zeit, deine I2C Routine ansteuert. Das geht wunderbar und dir geht kein Interrupt verlohren.

Tschüss Martin L.

Reply to
Martin Laabs

I2C per Software ist kein Problem. auf ti.vcom/msp430 findest du etliche I2C Routinen (Beispiele für EEPROM oder auch andere I2C-Chips). Unterbrechungen per Interrupt sind für I2C kein Problem! Das ist der grosse Vorteil von I2C (gegenüber 1-wire von Dallas zum Beispiel).

Warten musst du sowieso auf den I2C-Chip. Bei 100kHz wartest du auf 1 Byte ca. 100us. Das könnte der Controller im LPM0 verbringen (spart ein bisschen Strom) oder in Multimastersystemen anderen Tasks geben. 100us sind aber nicht viel und werden schon fast nur vom task switching gebraucht. Imho hat die I2C-Einheit im MSP430 nur wirklichen Nutzen im Slave-Mode.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

Aha, Du meinst also, weil dann der MSP430 als Slave betrieben weniger rechnen/leisten muß und mehr schlafen kann?

Wie erwähnt, geht es bei mir darum zunächst ein RTC anzubinden, da mir die Kollegen sagten, dass die interne Uhr des MSP sehr ungenau ist und mit der Temperatur stark veränderlich ist. Habt Ihr diese Erfahrung auch gemacht? Habt Ihr eine andere Lösung dafür gefunden, als eine RTC zu bemühen?

Christian

Reply to
Christian Schulz

Christian Schulz wrote in news: snipped-for-privacy@individual.net:

Ich meinte, das der Stromverbrauch bei der I2C-Kommunikation nicht gross ins Gewicht fällt, so selten du den abfragst (1sek Schlafen zu

1ms-I2C sind 1/1000). Die Hardware bringt nur Nutzen als Slave (weil das zeitkritisch ist und der MSP ev. nicht schnell genug reagieren kann bei Start/Stop) bzw. wenn man die 400kHz Takt als Master wirklich braucht (grosse Datenmengen schieben muss).

Die Genauigkeit hängt nicht vom MSP430 ab. Die Uhr ist so genau wie der

32kHz Quarz den du da dran hängst. Wenn du da einen teuren nimmst, wird das schon genauer, sofern du die genau zum Quarz passenden C's dran machst (der MSP hat schon 6pF drinnen bzw. man kann die beim 4xx auswählen). Externe RTC's sind imho nicht besser mit der Temperatur; weil die auch nur mit Wasser kochen (sprich die gleiche quadratische Temperaturabhängigkeit haben). Wenn du mehr Grips investierst, kannst du sogar einen einfachen TCXO bauen. Ab und an mit dem internen Temperatursensor den Unterschied zur Raumtemperatur messen und dann entsprechend einer Parabelfkt immer mal ne Schaltsekunde addieren bzw. abziehen. Man kann die Uhr auch in der Produktion kalibrieren. Einen der Timer mit genauen externen 10MHz speisen und den ACLK auszählen. Das für eine Sekunde machen und man weiss die Abweichung in 0.1ppm (die man dann wieder ab und an als "Schaltsekunde" addiert bzw. abzieht).

Letztlich alles nur eine Frage des Aufwandes. Da ist ein externer RTC (oder TCXO) sicherlich einfacher zu integrieren, aber auch teurer und vielleicht auch hungriger.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.