Hilft dir zwar nicht weiter, aber ..... Probleme mit I²C hatte ich nur ein mal: Das war ein Display mit I²C und einem angegebenen Innen-R der Eingänge von 600-1000 Ohm. Bei sowas tut man sich dann mit "normal" bemessenen PullUps schwer und ich hab auch in diesem Fall mehr als 100kBit nicht geschafft. Zum Glück hat dieses Display auch SPI (DOG-XL).
Ich programmiere mit AVRCo
Hilft mir doch, danke! Im Moment gehts nämlich nicht wirklich weiter. Aber der Reihe nach.Zitat von Crazy Harry
An beiden Platinen - RNControl und RN MotorControl - die 10k ausgelötet und durch 2k7 ersetzt. Happy und übermütig gleich ISP mit 800k angefangen. Ging nicht. Mehrere Tests brachten:
o Senden geht bis etwa 400 k recht ordentlich (fünf Motordaten: Aktualisierungscode, Richtung1-vor/zurück, PWM1, Richtung2-vor/zurück, PWM2).
o Rücklesen (oder empfangen?) geht bei 200 k gerade noch - manchmal, nicht immer (Eine initialisierte Ziffernfolge im Slave vom Master überschreiben und zurücklesen, mit geänderten Daten überschreiben und wieder zurücklesen). Ob die I2C-Kommunikation beim Senden, Lesen oder Empfangen hängen bleibt weiß ich (noch) nicht.
Eigentlich geht es zwischen diesen beiden Platinen mit dem 55cm Flachband (RN-Definition-Belegung = zwischen SCL und SDA liegt ein GND-Strängelchen) richtig ordentlich nur mit 100 kHz. Ok, ich werde mal ne Weile damit leben, sonst läuft mir die Zeit weg.
Ciao sagt der JoeamBerg
Und bei den vielen Tests der letzten Tage war wohl der eine oder andere seltene Fall dabei, dass sich der Master auch bei 100 kHz aufgehängt hat - oder vom Slave aufgehängt wurde.
Codeschnippsel vom Master - Lesen I2C-Buffer
Kann das an den Interrupt(s) liegen? Der Master (mega1284) hat einen Timer-Interrupt, 50µs von TIMER2 COMPA, der Slave (mega32Code:// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Lesen vom Slave ##### mit Änderung/Zusatz if(!(i2c_start(SLAVE_MoCo+I2C_WRITE))) //Slave bereit zum schreiben/lesen? { // // - - - - - - - - - - - - - - - - - - - - - - - - - - // Musterzeile vom RN Wissen // i2c_write(0x00); //Buffer Startadresse zum Auslesen // i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen // - - - - - - - - - - - - - - - - - - - - - - - - - - i2cdmy = i2c_write(0x00); // Buffer Startadresse 0 zum Auslesen i2c_stop(); // i2cdmy = i2c_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen ////i2cdmy = i2c_rep_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen btst1 = i2c_read (ACK); // 1. von 5 Bytes lesen...hat ebenfalls Timer-Interrupt, 50µs von TIMER2 COMPA, dazu werden kommen zwei extINT0 und ~1 von den Encodern, evtl. noch andere Interrupts. Der TIMER2 COMPA ist mit Vector 8 resp. 10 relativ hoch priorisiert, die extINT mit 2 bzw. 3 sehr hoch - dagegen ist der TWI mit vector 25 resp. 27 weit unten. Nun soll natürlich eine IRS immer warten, bis die laufende fertig ist - ich lasse keine nestet Interrupts zu - aber
es könnte Zeitverschiebungen in der I2C - Kommunikation geben. Macht das etwas? Könnte das der Fehler sein?
Ciao sagt der JoeamBerg
Was ist denn hier los? NIX????
Hallo oberallgeier,
natürlich kann es an den Interrupts liegen.
------------- Halber - BLÖDSINN -------------------------------------------------
\/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/
Also als erstes: Die Fleurylib arbeitet NICHT mit Interrupts. Deine Ansatz mit dem INT-Vektor ist hier somit komplett vergeblich. Aber leider kommt es somit noch schlimmer.
Wenn nun die Fleurylib-Software ackert und das Timing durch NOP's oder Loop's erzeugt wird, dann jagen deine doch recht häufigen 50µs-Timer einiges an Zeit durcheinander. Zumindest deutet da vieles drauf hin.
/\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\
------------- Halber - BLÖDSINN -------------------------------------------------
Das da oben war nicht ganz richtig.
- Auf der Master-Seite wird nicht mit Interrupts gearbeitet.
Timing-Loops oder NOPs werden hier allerdings auch nicht benutzt. Die Lib arbeitet sauber mit den Statuswerten der I2C-Hardware. Somit läuft die Wartezeit ausserhalb der I2C-Hardware und darf entsprechend auch durch Interrupts unterbrochen werden. Die Hardware sollte dann aber ohne Probleme die Daten transportieren!
- Auf der Slave-Seite allerdings komplett im Interrupt.
Hier könnte die Fragestellung zur Priorität von oberallgeier also doch noch wichtig werden!
------------- Halber - BLÖDSINN - nachgearbeitet ende ---------------------------
Du solltest mal eine Abschätzung machen wie lange deine Interruptfunktion denn so benötigt.
Ein Ansatz zur Lösung könnte folgendermaßen aussehen:
- Am Ende der INT-Funktion setzt du einen Merker auf TRUE
- In deinem Hauptprogramm rufst du NUR dann eine I2C-Funktion auf, wenn der Merker gesetzt ist.
- Den Merker dann in dem if sofort zurücksetzten, damit eine weitere Main-Loop keine 2.tes I2C-Funktion aufruft.
- Main ackert weiter und bekommt nach dem Timer-Interrupt-Merker=TRUE wieder die Erlaubnis ein wenig Fleurylib-Zeit zu verbrennen.
Die Idee ist, dass du innerhalb der Fleurylib-Funktionen für die nächste Zeit nicht gestört wirst wenn die aufgerufene Fleurylib-Funktion selbst weniger als 50µs benötigt. Die Zeit kannst du ja selber mal nachrechen.
Wenn dein Rechen zu dem Schluss kommt, dass die Fleurylib-Funktion länger dauert, kannst du mein Geschreibsel sofort in die Tonne treten, da dann das Prinzip nicht mehr funktioniert.
Hier hätte ich aber auch noch einen Link zu einem Leidensgenossen von dir. Eventuell nützt es was: http://www.elektronik-projekt.de/thread.php?threadid=3197
Gruß Sternthaler
Geändert von Sternthaler (30.10.2012 um 22:45 Uhr) Grund: Bösen Fehler von mir beschreiben.
Lieber Asuro programieren als arbeiten gehen.
Danke erstmal für Deine freundliche Unterstützung und Deine Sorge.
Nix los? Na ja, es war die letzten Tage gigantisch sonniges Herbstwetter - oberhalb von 1200 MSL. Da rufen die Berge und die Kletterwände; Fliegen geht nicht, weil ALLE Landeplätze im Nebel liegen :-/ . Beispiel: Verschnaufpause knapp unter 2000 MSL mit freiem Oberkörper . . . auch geklettert wird derzeit öfters ohne Hemd. Aber Deine Frage zielt anderswo hin. Da ist auch nicht wenig los.
Servoplatine und -routine müssen noch werden. Die Routine hatte Probleme gemacht (weil ich mich eigensinnig wie immer auf ein bestimmtes Konzept versteif(t)e). Mittlerweile läuft die 10-Servo-Routine störungsfrei am Breadboard-m328-20Mhz. Was heißt störungsfrei? Gestern Nacht, eher heute, habe ich durch die fliegende und daneben gesteckte Verdrahtung zwei Billigservos gebraten. Richtig verdrahtet liefs dann wieder. Und ich bin richtig stolz darauf, zehn Servos (na ja, auf den meisten Kanälen läuft derzeit nur der Oskar) mit unterschiedlichen Geschwindigkeiten und unterschiedlichen Start- und Zielpunkten (zeitlich und örtlich) mit einer selbstgebauten Routine ansteuern zu können. Die Routine braucht noch einen Feinschliff z.B. für den spätere I²C-Datenaustausch, das Abfangen von Fehlern etc. Bekanntlich frisst so etwas die meiste Zeit.
Das mechanische Konzept des gesamten Projektchens macht auch Arbeit - ausser einem DINA0 mit etlichen Strichen, viel zu wenigen, steht noch nix.
Dazu kommen noch Nebenarbeiten durch ein Sonderangebot von Motoren, die ich für einen Hilfsantrieb einsetzen werde.
Schließlich zum I²C. Unser freundlicher Mathefreakkollege aus unseren gemeinsamen Navigationsdiskussionstagen unterstützt mich dabei. Da ich aber derzeit nur zwei endgültig einzusetzende Platinen habe, später werden es mehr, warte ich derzeit, bis ich a) die I²C-Geschichte des Kollegen halbwegs verstehe, b) mehr endgültige Platinen mit einer endgültigen Kabelbaumlänge habe und c) die kollegialen low-level-Programme des Kollegen mit meinen bescheidenen C-Kenntnissen ins fertige Projekt einbinden kann. Linken von relokativen Compilaten konnte ich vor vielen Jahren zu meiner Fortranzeit. Davon ist aber i) nix mehr übrig und ii) passt es sowieso nicht.
Du siehst - kein Moos, trotzdem was loos.
Freundliche Grüße aus dem mittlerweile kühlen Allgäu wo wir ruhig auf Winterreifen dem wochenendlichen Schneechaos entgegenträumen.
Nachtrag zum Wetter. Stand ungefähr Di, 23.10, 0830: meine Terrasse auf 812m MSL hatte 5°C, Terrasse einer Berghütte am Nebelhorn auf 1934m MSL hatte 16°C - da war es aber drei Stunden früher (also NACHTS!) etwas wärmer.
Geändert von oberallgeier (26.10.2012 um 08:31 Uhr) Grund: Wetterbericht
Ciao sagt der JoeamBerg
Ahhh, Wetterbericht live. Das lobe ich mir, da ich nun eine Justage meiner Wetteraufzeichnungen vornehmen kann. Was war das nochmal? MSL? Mars Science Laboratory oder doch nur eher vollkommen durchschnittliches, von dir weit entferntes, Salzwasser?
Hallo oberallgeier,
schön, dass du selbst mit weit mehr als 400kHz durch die Berge 'tikst'. So langsam werde ich aber echt ungeduldig da ich immer noch nicht mitbekommen habe warum du so viele Servos steuern willst. Ich kann mir nicht vorstellen, dass du dir einen elektrischen Konkurrenten für das Wandern und Bergsteigen bastelst. Es muss also irgendetwas anderes Sinnvolles sein. Oktopussy für 008?
Warum nur dein Satz: "Dabei drängt mich in meinem neuen Projekt die Zeit."?
Ich bin gespannt, was die Mathefraktion beisteuert und was du daraus wieder zusammenstricken wirst.
Frohes schaffen und eisfrei Straßen wünscht
Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Na sooo weit rauf reichen unsere Berge nicht. Die langen nicht mal für Höhenkrankheit . . . Der MSL ist zwar keine bodenständige Sache - im wahrsten Sinne des Wortes - aber doch terrestrisch gebunden; weißt Du ja.
Top secret.... immer noch nicht mitbekommen habe warum du so viele Servos steuern willst ...
Danke, dass Du mal was Nicht-Sinnfreies von mir erwartest. Denn so richtig sinnig ist es nicht, Getränkedosen so zu modden, dass man nicht mehr den Pullring mit der Hand ziehen muss, sondern die Dose mit der TV-Fernbedienung aufkriegt. Einen Vorteil aber hat mein "... drängt ... die Zeit ..." - Du musst nicht so lange warten, bis der Vorhang aufgeht. Hoffen wir beide jedenfalls.... muss also irgendetwas anderes Sinnvolles sein ... Warum nur ... "... drängt ... die Zeit."? ...
Ciao sagt der JoeamBerg
Berechtigungen
Zitieren
Lesezeichen