Das Delay liegt jetzt bei unter 2us von der fallenden Flanke der CLK aus gemessen. Zumindest in allen Fällen die ich gesehen hab...
Da das kurze Delay zu Problemen führen kann wenn die Flanken auf der Datenleitung wesentlich flacher sind als die der CLK empfehle ich für den Einsatz weiterhin die Version vom 31.12.2010.
Da das kurze Delay zu Problemen führen kann wenn die Flanken auf der Datenleitung wesentlich flacher sind als die der CLK empfehle ich für den Einsatz weiterhin die Version vom 31.12.2010.
Das verstehe ich jetzt nicht, von welchen Problemen redest du hier? Ich hab das Delay nun rein rechnerisch auf 0,3µs runter gebracht, mit externem Quarz nochmal ein Faktor 2. Für die 74kHz Clock Objektive ist das egal, aber die gibt es auch in 500kHz und da wird es schon kritisch.
Was soll eigentlich die Zeile:
.org 0x0012
ohne dass ein Argument in den Interrupt geladen wird?
__________________ "Das Wasser und die Zeit, sind die einzigen Elemente, die sich in einer kalten Biwaknacht ausdehnen können."
Tipps und Links zur Fotografie auf www.gletscherbruch.de
Das verstehe ich jetzt nicht, von welchen Problemen redest du hier?
Wir haben zwei relevante Leitungen, Daten und Clock. Eigentlich wird auf der fallenden Flanke der Clock der Pegel auf der Datenleitung (nicht) geändert und die steigenden Flanke signalisiert dem Slave er möge die Datenleitung bitte jetzt samplen. D.h. eigentlich ist der Inhalt der Datenleitung bei Clock low nicht wirklich definiert, wichtig ist der Pegel bei steigender Flanke. In der Praxis liegt der richtige Pegel der Datenleitung innerhalb von ein paar dutzend ns nach der fallenden Flanke der Clock an, wenn alles ok ist.. Nur weiß niemand, ob das wirklich alle Bodys in jeder Situation so handhaben, erst recht nicht wenn Bauelemente altern, sowieso eine Macke haben oder irgendwo Kontaktprobleme vorliegen. Letztlich leben wir ja in einer analogen Welt in der sich Pegel mit endlicher, u.U. variabler Geschwindigkeit ändern.
In meinem Code vom 31.12 reicht die PCINT ISR den Pegel der Datenleitung weiter wenn er sich ändert und unabhängig davon wird die Datenleitung erst nach 2+us nach der fallenden Flanke der Clock zur internen Auswertung gesampelt um (wenn auch unwahrscheinlichen) Timingproblemen aus dem Weg zu gehen. Wenn die Zeit da ist leg ich sie gerne an um auf der sicheren Seite zu sein.
Der neue Code sampelt ohne Rücksicht auf Verluste weniger als 1 us nach der fallenden Clock die Datenleitung zum weiterreichen. Ist schneller, könnte aber durchaus zu Problemen führen. 1 falsches Bit unter ein paar Millionen macht u.U. halt den Absturz alle paar Tage aus. Klingt paranoid, isses wahrscheinlich auch (Pullups, Kerko,...), aber auf diese Tour hab ich komplexere Dinge gebaut die über Monate am Stück fehlerfrei laufen.
Zitat:
Zitat von Nightshot
Ich hab das Delay nun rein rechnerisch auf 0,3µs runter gebracht, mit externem Quarz nochmal ein Faktor 2.
Auf Flanken warten ist natürlich auch eine Option.
Zitat:
Zitat von Nightshot
Für die 74kHz Clock Objektive ist das egal, aber die gibt es auch in 500kHz und da wird es schon kritisch.
Mir gehts halt nur um den möglichst störungsfreien Betrieb eines alten Sigmas.
Zitat:
Zitat von Nightshot
Was soll eigentlich die Zeile:
.org 0x0012
ohne dass ein Argument in den Interrupt geladen wird?
Der Code soll wirklich erst hinter der Sprungtabelle anfangen. Eigentlich könnte man die Sprungtabelle auch mit RETI vollschreiben, aber das halt ich für übertrieben
Es tut mir leid für mein Deutsch. Ich kann nicht mehr Deutsch sprechen, damit ich Google Translate Verwendung hatte. Ich hoffe, es macht Sinn
Ich fing an, Reverse Engineering der Canon-Protokoll vor einer Weile mit einem Logik-Analysator. Ich habe nur auf das Schreiben der Hex-Werte. Nach dem Auffinden und Lesen in diesem Forum heute bin ich froh, dass ich nicht versuchen, herauszufinden, was die Hex-Werte ment. Es ist viel komplizierter, als ich dachte, es wäre.
Herzlichen Glückwunsch an Sie alle für die Arbeit, die Sie getan haben, erstaunlich.
Mein Projekt.
Ich möchte meine 400D zu meinem Teleskop konzentrieren. Ich baute ein Auszug, dass vom PC gesteuert wird. Der Auszug wird ein PIC mit dem PC Befehle übersetzen und steuert die Bewegung der Okularauszug Motor.
Mein Gedanke ist, die dem PIC, um das Teleskop mit den Befehlen aus dem 400D Fokus Programm. Make my Teleskop einer einfachen Linse. (manuell Fokussieren eines Teleskops ist sehr mühsam).
Schwerpunkt in
Schwerpunkt aus
Unendlichkeit Endanschlag
Null Endanschlag
Würden die 400D müssen alle anderen Befehle, um die Scharfstellung des Teleskops oder könnte ich einfach beliebige Werte aus einem Standard-Objektiv, eine Menge der 400D die Fragen (zB Objektivtyp, Blende, etc.) zu beantworten?
Gibt es eine Liste mit allen Standard-Protokoll Canon Fragen und Antworten, was ich brauchen würde?
Do you seriously expect us to decipher that Google translate gibberish? I thought people understood by now that it can't be used to have conversations in German.
Leider funktioniert es zwischen meinem Vater und ich (ich bin in Australien, er ist in Deutschland). Also dachte ich, es ist einen Versuch wert.
Ich es auch geschafft, alle 33 Seiten gelesen Forum, übersetzt.
Versuch nicht schaden.
Entschuldigen für die Unannehmlichkeiten.
Markus
no problem, i understand
what you want, i think, better you use life view and scripting on a windows pc, with a usb/rs232 port you can command your focus on the telescope an with seen on pc screen you can see if in focus, wenn the green frame is comming, so i think, really untestet....
__________________
meine Bilder dürfen hier bearbeitet werden und im Thread wieder eingestellt werden
"There are 10 Types of People in the World; who understand B I N A R Y and those who don't"
gruss
jar
AW: Canon-EOS-Protokoll
Linear-Darstellung
