Hi,
ich bin gerade in der Planungsphase von einem meiner ersten Projekte.
Meine Fragen berufen sicherlich darauf, dass ich noch keine Erfahrungen
im Umgang mit I2C (oder anderen Bus-Systemen wie SPI) gesammelt habe.
Ich habe eine vereinfacht gesagt eine Anzeigetafel mit einer
entsprechenden Steuerplatine.
Über I2C sollen nun diverse Platinen bzw. Mikrocontroller angeschlossen
werden, welche zusätzliche Informationen liefern, die angezeigt werden
können. Unter anderem soll so z.B. ein Controller angebunden werden,
welcher die aktuelle Uhrzeit zur Verfügung stellen soll. Diese soll er
über DCF77 empfangen und in einer RTC vorhalten. Aus Gründen der
Modularisierung möchte ich diese Funktionalität nicht in der
"Haupt-Platine" implementieren.
Nun bin ich auf der Suche nach RTC-Bausteinen darauf aufmerksam
geworden, dass diese i.d.R. auch über I2C angeschlossen werden.
Mir stellt sich nun folgende Frage: Wie "kapsele" ich diese zwei
Komponenten richtig voneinander ab? Die "Haupt-Platine" soll weder etwas
von der RTC auf der "Uhren-Platine" wissen, noch sollen sich die beiden
in die Quere kommen. Idealerweise würde die "Haupt-Platine" einfach jede
Sekunde registrierte Geräte fragen, ob diese Daten zum Anzeigen vorrätig
haben, und diese ggf. abfragen. Das würde garantieren, dass man
zusätzliche Peripherie nach dem Motto "Plug and Play" einfach nur
anschließen muss. Eine ordentliche Schnittstelle mal vorausgesetzt.
Lässt sich das irgendwie geschickt lösen? Spontan fällt mir nur eine
Lösung ein, welche darauf hinausläuft, dass man I2C in Software
nachbildet und somit zwei getrennte I2C Busse hat. Das kommt mir aber
weder besonders geschickt vor, noch weiß ich, ob bzw. wie einfach sich
so etwas realisieren lassen würde. Prinzipiell würde ich schon gern das
in Hardware zur Verfügung gestellte Two-Wire-Interface nutzen.
Ich könnte vermutlich auch RTCs finden, welche nicht über I2C
angesprochen werden, aber das Problem ist ja von grundsätzlicher Natur.
Ich hoffe, dass ich das Problem wenigstens halbwegs vernünftig erklären
konnte, und der Text nicht allzu lang ist ;).
Mit freundlichen Grüßen,
manitou
Du kannst an den I2C Bus bis zu 112 (8bit) bzw. 1136 (10bit) Teilnehmer
anschliessen.
Jeder Teilnehmer bekommt eine eigene Adresse unter der er ansprechbar
ist.
Im Single Master Modus könnte der Master dann die bekannten Slaves
abfragen und in regelmässigen Abständen nach neuen Teilnehmern auf dem
Bus suchen.
Gruß
Wieso genau willst bzw. brauchst du zwei getrennte I2C-Busse?
Was meinst du mit abkoppeln? Außer, dass die Module über I2C miteinander
verbunden sind, "berühren" die sich doch nicht.
1. Es gibts auch 1-wire RTCs
2. Ein AVR mit externem Uhrenquarz (bei eigtl. allen Megas möglich) ist
zwar nicht ganz so stromsparend wie ein RTC-Chip sollte an einer CR2032
Lithium-Batterie aber locker 5 Jahre durchhalten (eine exzessive
anwedung von sleep vorausgesetzt), er muss Ja im "Backup-Modus" nur 1x
pro Sekunde den Core aufwecken (32768 kHz / 128 (prescale) / 256
(Timer2) = 1 Hz) und die Zeit incrementieren, dadurch sparst du eine
externe RTC.
EDIT: Das is z.B. ein 1-wire RTC-Chip:
http://www.maxim-ic.com/datasheet/index.mvp/id/2911
Du könntest deine Hauptplatine bspw. nur bestimmte Adressen abfragen
lassen. Also einen bestimmten Adressbereich z.B. . Entweder du bekommst
dann eine Antwort oder nicht.
Hi,
vielen Dank schon einmal für eure Antworten.
R. F. schrieb:> warum nicht den "Uhrencontroller" über I2C verbinden und die> Kommunikation der restlichen Platinen über einen anderen Bus, z.B. UART.
Ehrlich gesagt wusste ich bisher nur über zwei mögliche Bus-Systeme
Bescheid: SPI und I2C. Aufgrund des geringeren Verdrahtungsaufwandes hat
mir I2C dann mehr zugesagt.
Ich sehe spontan auch nicht wie man mittels UART mehrere Controller
miteinander kommunizieren lassen könnte, ich dachte das wäre eine Lösung
für nur 2 Teilnehmer.
A. K. schrieb:> Hast du dich bereits auf Controller festgelegt, die nur eine> I2C-Schnittstelle besitzen? Es gibt auch welche mit zweien.
Nein, ich bin noch in der Konzept-Phase. Die "Haupt-Platine" ist zwar
größtenteils schon fertig, aber um die weiteren Bausteine habe ich mich
noch nicht gekümmert. Gibt es solche Controller auch von Atmel? Es ist
nämlich gar nicht so einfach nach "Two Two-Wire-Interface" zu suchen
bzw. etwas brauchbares zu finden ;). Ein Uhren-Controller muss ja
prinzipiell nicht viel Funktionalität bereit stellen und könnte
dementsprechend klein ausfallen. Ich bezweifle jetzt einfach mal, dass
es "kleine" AVRs gibt, welche zwei TWIs bereit stellen. Irre ich mich?
TWI schrieb:> Du kannst an den I2C Bus bis zu 112 (8bit) bzw. 1136 (10bit) Teilnehmer> anschliessen.
Das habe ich schon mitbekommen. Ich wollte es halt nur aus Gründen der
Einfachheit so gestalten, dass jeder angeschlossene Teilnehmer wirklich
etwas brauchbares liefert. Ansonsten müsste ich mir noch Gedanken über
eine vernünftige Adresseaufteilung machen und das ggf. in den
Schnittstellen berücksichtigen. Wie gesagt ich habe noch keinerlei
Erfahrung mit I2C, aber solche Lösungen scheinen das Ganze zumindest auf
den ersten Blick nicht einfacher zu machen. Insbesondere können sich die
beiden Controller ja dann in die Quere kommen.
TWI schrieb:> Achja, I2C kann man auch ohne Hardware I2C mit nicht sooo viel Aufwand> implementieren, somit bist Du von der uC Hardware etwas flexibler.
Ok, das ist schon einmal gut zu wissen. Dennoch wäre natürlich echte
Hardware I2C schöner ;).
EGS_TI schrieb:> Gibt es keine RTC mit SPI?
Sind mir jedenfalls noch nicht über den Weg gekommen. Wie erwähnt gibt
es noch 1-wire Lösungen. Ich wollte allerdings ganz prinzipiell wissen,
wie man so etwas "geschickt" löst. Ganz unabhängig von der RTC.
EGS_TI schrieb:> Du könntest deine Hauptplatine bspw. nur bestimmte Adressen abfragen> lassen. Also einen bestimmten Adressbereich z.B. . Entweder du bekommst> dann eine Antwort oder nicht.
Ja, das wäre eine Lösung. Siehe oben. Mir gefällt halt nur nicht die
Vorstellung, dass eine Kommunikation zwischen Uhren-Controller und RTC
den ganzen Bus "lahmlegt". Klar, in der Praxis dürfte das kaum eine
Rolle spielen. Da ich aber zur Zeit noch in der Entwurfsphase bin, würde
ich das Ganze gerne so sauber wie nur möglich gestalten.
Mit freundlichen Grüßen,
manitou
manitou schrieb:> Ja, das wäre eine Lösung. Siehe oben. Mir gefällt halt nur nicht die> Vorstellung, dass eine Kommunikation zwischen Uhren-Controller und RTC> den ganzen Bus "lahmlegt".
Was willst du denn mit deiner Uhr alles kommunizieren. Die brauchst du
doch eigentlich nur zur Stromausfallüberbrückung, damit dein System dann
nicht zeitlos dasteht.
manitou schrieb:> Gibt es solche Controller auch von Atmel? Es ist> nämlich gar nicht so einfach nach "Two Two-Wire-Interface" zu suchen
Es gibt auch bei Atmel eine parametrische Suche, in der man auf
mindestens 2 TWIs einschränken kann. Die klassischen Mega/Tiny Serien
sind da aber so gut wie draussen.
spess53 schrieb:> Selbstverständlich gigt es RTCs mit SPI:
Ok. Das ist natürlich gut zu wissen und eine Lösung für mein Problem mit
der RTC. Wobei ich natürlich in erster Linie an einer allgemeinen Lösung
interessiert bin. Insofern würde mir ein Atmel AVR mit zwei
Two-Wire-Interfaces bisher wohl am Besten gefallen ;). Gibt es denn
solche auch? Wie finde ich diese?
Wolfgang schrieb:> Was willst du denn mit deiner Uhr alles kommunizieren. Die brauchst du> doch eigentlich nur zur Stromausfallüberbrückung, damit dein System dann> nicht zeitlos dasteht.
Naja, der "Uhren-Controller" würde ja regelmäßig das DCF-Signal
empfangen und es in die RTC schieben. Über das Intervall kann man wohl
streiten (vermutlich reicht sogar einmal am Tag). Trotzdem gefällt mir
ein Design nicht sonderlich, bei welchem die Kommunikation zwischen
"Uhren-Controller" und RTC (welche ich als "sekundär" bezeichnen würde)
den gesamten Bus lahmlegt, über welchen ggf. "wichtigere" Daten (welche
ich als "primär" bezeichnen würde) transportiert werden könnten.
Wie gesagt: Ich bin noch in der Entwurfsphase und sammle Ideen.
Verständlicherweise will man zunächst ein "perfektes" System entwerfen
;).
Daher danke ich euch bereits jetzt vielmals für euren Input!
A. K. schrieb:> Es gibt auch bei Atmel eine parametrische Suche
Dürfte ich denn um einen Link zu dem Ganzen bitten? Ich war schon immer
auf der Suche nach so etwas. Habe zwar Inoffizielle Varianten gefunden,
diese waren aber entweder nicht (mehr) aktuell, oder überhaupt recht
eingeschränkt.
Mit freundlichen Grüßen,
manitou
manitou schrieb:> Dürfte ich denn um einen Link zu dem Ganzen bitten?
www.atmel.com
Products - By Device - Microcontrollers
links unten Parametric Table - Find
War das jetzt sooo schwierig?
usuru schrieb:>> bei Microchip erreichst Du das "Product Selector Tool" über>> http://www.microchip.com/productselector/MCUProduc...>> reichen 88 µCs mit 2 MSSP-Modulen (die können I2C) allein bei den> 8-bit-Typen ?
Ich würde schon ganz gern bei Atmel bzw. AVR bleiben. Dafür habe ich
bereits das nötige Equipment zum Programmieren sowie Erfahrung. Wird
wohl in diesem Fall darauf hinauslaufen, dass ich eine RTC mit SPI
verwenden werde und hoffen muss, dass auch eventuell in der Zukunft
verwendete Bausteine immer in einer SPI Variante verfügbar sein werden
;).
Mit freundlichen Grüßen,
manitou
manitou schrieb:> über welchen ggf. "wichtigere" Daten (welche> ich als "primär" bezeichnen würde) transportiert werden könnten.
Da klingelts bei mir: Schau doch mal nach dem CAN Bussystem.
manitou schrieb:> Naja, der "Uhren-Controller" würde ja regelmäßig das DCF-Signal> empfangen und es in die RTC schieben. Über das Intervall kann man wohl> streiten (vermutlich reicht sogar einmal am Tag). Trotzdem gefällt mir> ein Design nicht sonderlich, bei welchem die Kommunikation zwischen> "Uhren-Controller" und RTC (welche ich als "sekundär" bezeichnen würde)> den gesamten Bus lahmlegt, über welchen ggf. "wichtigere" Daten (welche> ich als "primär" bezeichnen würde) transportiert werden könnten.
Naja, was genau soll das werden. Eine eierlegende Wollmilchsau, die dann
am Ende 1 mal Pro Tag eine LED blinken lässt ?
Mach doch einfach den Uhr-Controller zur RTC (wie oben bereits gesagt)
das ist billiger als irgendein exotischer SPI-RTC-Baustein und so schwer
is das mit dem Sleep auch ned, du kannst ja ne Art "Wake-Up Pin"
vorsehen der hängt an nem Interrupt eingang und reagiert auf die
Rising-Edge der 5V Versorgungsschiene (mit nem 10k Pulldown (pullup im
Avr unbedingt ausmachen) an derselben is das recht zuverlässig)....
quak schrieb:> Da klingelts bei mir: Schau doch mal nach dem CAN Bussystem.
Danke für den Hinweis. Wobei das schon ein wenig komplexer aussieht.
Werde ich mich erst einmal vernünftig einlesen müssen.
quak schrieb:> Naja, was genau soll das werden. Eine eierlegende Wollmilchsau, die dann> am Ende 1 mal Pro Tag eine LED blinken lässt ?
So ungefähr ;). Klar, meine Konstruktion wird nicht den Weltfrieden
sichern. Aber es macht doch Spaß etwas von Grund auf vernünftig zu
planen.
Max D. schrieb:> Mach doch einfach den Uhr-Controller zur RTC (wie oben bereits gesagt)> das ist billiger als irgendein exotischer SPI-RTC-Baustein und so schwer> is das mit dem Sleep auch ned,
Das kommt wohl ganz drauf an wie man Kosten definiert. Selbst ein
solcher exotischer SPI-RTC Baustein ist für unter 5 Euro zu haben. Wenn
man das Ganze selber implementiert ist man sicherlich etliche Stunden
drüber.
Wobei es ja aus Lernzwecken durchaus seinen Reiz haben kann. Könntest du
deine Ausführung oben vielleicht etwas genauer beschreiben? Wofür
braucht es den Wake-Up-Pin bzw. wie hängt dieser mit der
Batterieversorgung zusammen (Eine RTC macht ja nur in Verbindung mit
einer "Notfall-"Batterieversorgung Sinn)? Wofür braucht es denn
Pull-Down Widerstand? Wenn keine Strom-Versorgung angeschlossen ist,
wohin soll dann "gezogen" werden? GND ist ja dann i.A. auch nirgends
angeschlossen? Vielleicht fehlt mir gerade das nötige
Vorstellungsvermögen, aber so ganz weiß ich nicht was du mir sagen
willst ;).
Dein Mega läuft, wenn das Modul Stromlos ist, mit (meist abgeschaltetem)
internem RC-Oszilator, wenn der Timer2 (von dem an den "Quarz-Pins"
angeschlossenem Uhrenquarz getaktet und mit 128 gepsrescaled) überläuft,
dann weckt er den mega der läuft mit 8 MHz los und erhöht die Uhrzeit
(in der Timer2 ISR), danach legt er sich wieder schlafen. Wenn du dein
Modul an eine externe Versorgung (in der Schaltung) hängst, dann muss
der Mega das ja merken, deswegen fragst du entweder jede sekunde nach,
ob das so ist, dann kanns bis zu einer Sekunde dauern bis der Mega an
dem Bus "erscheint" oder du verbindest einen Interrupt-Pin mit der
Versorgung der weckt dann deinen Mega einfach so auf. Der Pulldown bzw.
der Pullup (je nach art der Verbindung) is jedoch immer nötig um den Pin
in ein "sicheres" Low/High zu kriegen damit die eingangsbuffer nich
mittendrin rumhängen und zusätzlich strom wegsaufen. Der mega wird dann
der Einfachheit halber über ne (Schottky-)Diode aus der Batterie
gepuffert (bei nem Mega88v kann man mit dem clkpr-register den takt
runterteilen -> läuft auch bei 1,8 V noch) und läuft immer (der oszi
wird aber oft abgeschalten). Wenn er aus der Schltung (auch per diode)
Strom kriegt, dann hat er hald 5V zur Verfügung und skaliert evtl.
seinen Takt auf die 8 MHz hoch). Die Verwendung eines Interruptes zur
Clock-umschaltung hat den vorteil, dass man mit ner Schottky aus den 5V
seinen Saft zieht und wenn die dann abfallen sich kurz aus dem
obligatorischen elko auf dem modul (100 µF reichen be richtigem design)
ernährt und den Takt wieder auf "Batterie-betrieb" umstellt und sich
schlafen legt.
Das sollte in C mit etwas Erfahrung in etwa einem Tag gut zu proggen
sein, ausserdem lernt man viel über die AVRs...
