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
Hallo, warum nicht den "Uhrencontroller" über I2C verbinden und die Kommunikation der restlichen Platinen über einen anderen Bus, z.B. UART.
Hast du dich bereits auf Controller festgelegt, die nur eine I2C-Schnittstelle besitzen? Es gibt auch welche mit zweien.
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ß
Achja, I2C kann man auch ohne Hardware I2C mit nicht sooo viel Aufwand implementieren, somit bist Du von der uC Hardware etwas flexibler. 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.
Achso, bei nochmaligem Durchlesen hab ich jetzt erkannt, wo das Problem ist. Gibt es keine RTC mit SPI?
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
Hi >> Gibt es keine RTC mit SPI? >Sind mir jedenfalls noch nicht über den Weg gekommen. Selbstverständlich gigt es RTCs mit SPI: http://para.maxim-ic.com/en/search.mvp?fam=rtc&374=SPI&tree=timers MfG Spess
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?
bei Microchip erreichst Du das "Product Selector Tool" über http://www.microchip.com/productselector/MCUProductSelector.html
> 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 ?
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.