Hallo, ich möchte ein kleines Interface bauen und möchte dazu einen Drehencoder/Drehgeber verwenden. Mir ist das gnaze bis jetzt auch teilweise gelungen dank Peter Dannegger's Hilfe im Wiki womit ich den Drehgeber präzise auswerten konnte. Allerdings hing dort der Drehgeber direkt am Prozessor. Ich möchte nun jedoch ein Display und Drehegber über I²C bzw. TWI ansprechen. Als Portexpander nutze ich einen PCF8574. Einen vorgefertigten Code um das Display anzusprechen sowie grundlegende I²C/TWI Funktionen nutze ich von Peter fleury.(http://homepage.hispeed.ch/peterfleury/avr-software.html ) Das Display lässt sich ohne jegliche Probleme ansprechen d.h. die Texte sind schnell da. Das Problem was ich nun habe ist das sich der Drehgeber nicht auswerten lässt bzw. ich nicht weiß wie ich den PCF8574 richtig nutzen kann. Ich hatte mir das so vorgestellt das ich den PCF ganz normal abfragen kann wie eben beim Prozessor. Ansonsten gab es im restlichen Internet auch nicht wirklich viele Infos geschweige denn ein vernünftiges Tutorial un nun stehe ich in einer Sackgasse. Wie kann ich festlegen weclhes Device Master/Slave ist ? Wie kann ich festlegen welche Pins vom PCF Eingang / Ausgang ist ? Wie kann funktioniert das ganze denn überhaupt grundlegend ? usw. Ich würde mich freuen wenn ihr mir vielleicht bei meinem Problem weiterhelfen könntet.
criztalize schrieb: > Ich hatte mir das so vorgestellt das ich den PCF ganz > normal abfragen kann wie eben beim Prozessor. So in etwa funktioniert das ja auch, wenn Du das I2C-Protokoll in den Griff bekommst. Anstelle des Lesens von einem I/O-Port des µCs musst Du hier halt den Eingang des Portexpanders über I2C lesen, die restliche Behandlung ist identisch. > Wie kann ich festlegen weclhes Device Master/Slave ist ? Das gibt die Hardware vor; Dein µC ist Master, der Portexpander ist Slave. > Wie kann ich festlegen welche Pins vom PCF Eingang / Ausgang ist ? Steht in dessem Datenblatt.
Wenn ich Dich richtig verstehe, willst Du den Drehgeber über die Ports des PCA8574 einlesen, oder? Hast Du bedacht, daß die Abtastrate dieser Ports durch die I2C-Verbindung begrenzt ist? Angenommen, Du taktest den Bus mit 400kHz (Maximum für den PCA8574). Du brauchst pro Telegram ca. 20 Bitzeiten (1x Start + 9x Slave-Adresse + 9x Portinhalt + 1x Stop). Dann bekommst Du im allerbesten Fall eine Abtastrate von 50us (20kHz) hin. Und auch nur, wenn der I2C-Bus alleine dem PCA8574 gehört (ohne weitere Slaves) und immer mit höchster Priorität bearbeitet wird. Reicht Dir das?
Genau Bronco :) Ich weiß nicht ob das reicht aber ich dachte das würde so funktionieren. In der tat hatte ich es mal kurzzeitig geschafft Werte auszulesen und diese dann an Peter's Funktion weiterzugeben jedoch war die Auswertung dann ziemlich Bananne: ich hab meisten nur Stichpunktartig werte bekommen. Ich dachte eben das ich irgendwas falsch gemacht hatte. An dem einen I²C Port hängt ja auch das Display und direkt dahinter der Drehgeber. Derzeit läuft der PCF im normalen Modus.
Du hat die Frage von Bronco nicht verstanden. Bronco schrieb: >Dann bekommst Du im allerbesten Fall eine Abtastrate von 50us (20kHz) >hin. criztalize schrieb: >Ich weiß nicht ob das reicht aber ich dachte das würde so funktionieren. Bronco meint ob die Abtastrate ausreichend ist für Deine Anwendung. Der Hintergrund ist, was bewegt den Drehgeber? Ein Motor? So kann es ja nach Geschwindigkeit schon eng werden. Ein Mensch? Dann ist die erzielbare Abtastrate ausreichend. Dann hängt alles nur noch von der Einbindung im Main ab.
Achso.
Ja also natürlich wird der von einem Mensch bedient sprich der dient
dazu um durch ein Menü zu gehen.
Dann dürfte es von der Geschwindkeit ja passen.
> den Eingang des Portexpanders über I2C lesen
Gibt es da evtl. Beispielcodes ?
Der I2C ist nicht geeignet für hohe Datenraten. Bei 1ms Abtastrate des Encoders hast Du schon 20% CPU-Last. Und Du hast das Problem, daß nur eine Instanz des I2C laufen darf. Wenn es unbedingt I2C sein muß, dann nimm einen 2.MC für LCD und Encoder als I2C-Slave, z.B. ATtiny24. Peter
Da nur eine Instanz laufen darf und ständig per Timer ausgelesen wird kann das ganze doch gar nicht laufen oder ? Sprich LCD & Encoder gleichzeitig an einem Bus. Dein Vorschlag wäre also jetzt einen Attiny zu nehmen und Encoder + LCD direkt an den tiny zu hängen ? Und der wird dann wiederum per I²C an meinen Atmega rangehängt ?
entschuldigt- der atmega macht das lcd und der tiny den drehehncoder. So wars gemeint :)
criztalize schrieb: > Dein Vorschlag wäre also jetzt einen Attiny zu nehmen und Encoder + LCD > direkt an den tiny zu hängen ? > Und der wird dann wiederum per I²C an meinen Atmega rangehängt ? Genau so. Der ATtiny kümmert sich um Encoder und LCD und entlastet damit den I2C und die Master-CPU. ATtiny lesen: Encoder als 32bit Wert ATtiny schreiben: Position + Text der LCD-Ausgabe Peter
Jetzt bin ich etwas verwirrt. Der Attiny tastet den drehgeber ab gibt das dem Atmega, der macht das menü und gibt den zu schreibenden text dem attiny der wiederum das LCD ansteuert ? Oder war das jetzt so gemeint das der Attiny das gesamte Menü macht sprich alles am Attiny hängt und der einfach nur dem Atmega per I2c sagt (per int wert) was jetzt gemacht wird. der wiederum gibt dann per I2c das ergenis zurück und der tiny schreibt das dann einfach oder wie ?
Der Punkt ist: Das Abfragen des Drehgebers erfordert eine mit der Drehzahl steigende Rechnleistung. Wenn Du den Drehgeber ganz einfach an Portpins anschließt und Pin-Interrupts verwendest, um die Flanken zu erkennen, steigt die Interrupt-Last mit der Drehzahl. Die Frage ist: Kannst Du in Deinem AVR soviel Interrupt-Last vertragen oder nicht? Wenn ja: Häng den Encoder direkt an Port-Pins. Wenn nein: Könntest Du z.B. einen zweiten, kleinen AVR spendieren, der nichts anderes tut, als den Drehgeber auszuwerten und dessen Zustand "mundgerecht" an den Haupt-AVR zu melden.
Ich würde es natürlich eig auch ganz gerne so wie von euch vorgeschlagen machen aber ich MUSS das so machen weil mir das so vorgesetzt wurde. Sprich ich muss das ding irgendwie mit I2C auswerten daneben muss aber auch noch das LCD funktionieren und ich darf rein gar nichts an der Hardware ändern. Wie ich das mache : Ich habe keine Ahnung.
criztalize schrieb: > ich MUSS das so machen weil mir das so vorgesetzt wurde. Komisch, der Thread fing damit an, dass du was bauen moechtest. Die Frage ist nun, wie viel Hilfe du noch bekommst, wenn die Leute merken, dass du sie belügst.
Du kannst natürlich einen ATtiny25 nehmen und damit nur den Encoder auslesen und über I2C abfragen. Ich dachte nur, daß man den Haupt-MC auch etwas vom LCD entlasten kann, also die Delays, E-Pin wackeln, Nibble Zerlegung usw. Der ATtiny24 wäre mit dem Encoder ja nicht ausgelastet. Peter
criztalize schrieb: > Sprich ich muss das ding irgendwie mit I2C auswerten daneben muss aber > auch noch das LCD funktionieren und ich darf rein gar nichts an der > Hardware ändern. Wenn die Hardware fest steht, ist es eigentlich ganz einfach: 1. Du fragst die Portpins des PCA8574 in einem festen Zeitraster ab. Dieses Zeitraster wird dadurch festgelegt, was Du in der Software realisieren kannst, d.h. wenn noch ein LCD und ein EEPROM und eine RTC an diesem I2C-Bus hängen und Dein AVR noch wichtigere Dinge zu tun hat, dann kommst Du am Ende eben nur auf z.B. 100Hz. Wichtig ist, daß die Abfrage immer genau in diesem Zeitraster erfolgt, also nicht schwankt. 2. Diese 100Hz legen dann fest, welche Drehzahl Du am Encoder maximal erkennen kannst. D.h. wird der Encoder schneller gedreht, gehen Dir Flanken verloren und Du erkennst die Drehung gar nicht oder falsch. Aber das kannst Du nicht ändern. 3. Dann kannst Du festlegen, daß der Encoder nicht schneller gedreht werden darf. Wenn das nicht akzeptiert wird (von Deinem Auftraggeber), soll er Dir ein andere Hardware geben. Er kann verlangen, daß Du alles tust, um diese Abtastung möglichst schnell zu machen, aber Du kannst nicht die Grenzen der Hardware sprengen.
Marwin schrieb: > criztalize schrieb: >> ich MUSS das so machen weil mir das so vorgesetzt wurde. > > Komisch, der Thread fing damit an, dass du was bauen moechtest. Die > Frage ist nun, wie viel Hilfe du noch bekommst, wenn die Leute merken, > dass du sie belügst. Weil man mir dann wohl gar keine Lösungvorschläge gegeben hätte, wenn das ganze so nicht geht und ich hätte dann doch lieber mehrere verschiedene Lösungswege die ich dann auch auf andere sachen anwenden kann. Ja aber ich gebe zu es war ein Fehler. Mir selber geht es nur um den Lern Erfolg, weil mir das eigentlich auch Spaß macht. Peter Dannegger schrieb: > Du kannst natürlich einen ATtiny25 nehmen und damit nur den Encoder > auslesen und über I2C abfragen. Das Problem ist das alles über den einen MC erfolgen soll d.h. über I2C auch den Drehgeber abtasten und das LCD soll auch noch mit texten gefüttert werden ebenfalls über I2C. Das ganze funktioniert über Taster zwar aber anscheinend gibt es irgendwie beim abtasten über I2C Probleme. > Ich dachte nur, daß man den Haupt-MC auch etwas vom LCD entlasten kann, > also die Delays, E-Pin wackeln, Nibble Zerlegung usw. > Der ATtiny24 wäre mit dem Encoder ja nicht ausgelastet. > > > Peter Ich finde den Weg nicht schlecht aber mir sind die Hände gebunden.
Guten Morgen, criztalize schrieb: > Ich finde den Weg nicht schlecht aber mir sind die Hände gebunden. dann müsstest Du alle führ und wieder darlegen und entsprechend Deiner Beurteilung des Problems und seiner Lösung einen Vorschlag unterbreiten. Entweder man entspricht diesem oder anderenfalls müsstest Du Dich aus der Problemlösung zurückziehen. Da Du dann unter diesen ursprünglichen Bedingungen keine Lösung anbieten könntest.
Danke schonmal an Bronco. Aber wie genau farge ich die Poortpins denn ab bzw setze ich welche ? Mit der send byte funktion kommt nichts raus sprich ich kann so nichtmal ein einfaches LED Modul ansprechen. Wie soll das dann mit der read_byte funktion dann klappen ?
criztalize schrieb: > Aber wie genau farge ich die Poortpins denn ab bzw setze ich welche ? Daß wir die Probleme Deines Konzepts diskutieren, ist eine Sache. Aber Deine Hausaufgaben mußt Du schon alleine machen!
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.