Hallo zusammen, mein Ziel ist es das ich mit dem MC ein Servo ansteuern kann. I h habe nur dazu den Artikel zum Servo angeschaut hier in Board. http://www.mikrocontroller.net/articles/Modellbauservo_Ansteuerung Ein paar fragen sind zwar noch offen, aber die antworten dazu kann ich mir selber heraussuchen. Gehe ich richtig der Annahme das dieses Tut nur für analoge Servos ist??? Wenn ja, wie Steuer ich denn dann ein digitales Servo an??? Was bedeutet denn das standard Band von 1520 Mikrosekunden??? Ich habe halt noch ein paar davon: http://www.freakware.de/p/ds610-digital-servo-bulk-version-align-hsd61001-bulk-a55664.htm Hoffe Uhr könnt mir weiterhelfen!!! Beste Grüße Patrick
Patrick89 schrieb: > Wenn ja, wie Steuer ich denn dann ein digitales Servo an??? Im allgemeinen werden digitale Servos genau so wie ein analoges Modellbauservo gesteuert. Falls du was Spezielles wissen möchtest oder Probleme hast, Modellbezeichnung des Servos angeben oder gleich verlinken.
Patrick89 schrieb: > Was bedeutet denn das standard Band von 1520 Mikrosekunden??? Das ist die Bandmitte https://de.wikipedia.org/wiki/Servo#Ansteuerung
Der Vorteil digitaler Servos ist (aus eigener Erfahrung), dass sie ihre Position auch halten, wenn die PWM-Signale nicht regelmäßig kommen, weil sie ihre Position offenbar speichern. Ich habe ein "pick by laserponter"- Projekt mit zwei Digitalservos gemacht, die wunderbar funktionieren, auch wenn sie im Arduino-Loop ihre Positionsdaten nur hin und wieder mal aus einer Funktion mit variablem ms-delay bekommen ... Zusammengefasst: Das Impulpaket in sich muss nat. stimmen, aber es darf gerne auch längere Zeit ausfallen.
Patrick89 schrieb: > Gehe ich richtig der Annahme das dieses Tut nur für analoge Servos > ist??? > Wenn ja, wie Steuer ich denn dann ein digitales Servo an??? Genau gleich. Schliesslich muss man ja ein digitales Servo anstelle eines analogen Servos in jeder bereits verbauten Fernsteuerungsanlage im Modellbaubereich einfach austauschen können. Kein Hersteller kann es sich leisten, ausschliesslich digitale Servos auf den Markt zu bringen, für die man die komplette Empfangsanlage austauschen müsste. Die Begriffe 'analog' bzw. 'digital' beziehen sich auf die interne Regelung des Servos. Die Ansteuerung ist identisch. > Was bedeutet denn das standard Band von 1520 Mikrosekunden 1520 Mikrosekunden sind ~ 1.5 Millisekunden. Na, klingelts?
:
Bearbeitet durch User
Ein Digitalservo kann oft mehr Stellimpulse pro Sekunde verarbeiten als ein Analogservo. Manche Digitalservo funktionieren auch nicht an Analogempfängern, weil sie einen anderen Mittenimpuls haben. Futaba BLS 251 z.B. ist so eines.
Frank E. schrieb: > Der Vorteil digitaler Servos ist (aus eigener Erfahrung), dass sie > ihre > Position auch halten, wenn die PWM-Signale nicht regelmäßig kommen, weil > sie ihre Position offenbar speichern. Und der Nachteil ist, dass der Servo mit aller Kraft versucht die ihm zugeteilte Position zu erreichen. Ist dies mechanisch nicht möglich, so drückt der Servo bis zur Selbstzerstörung (Überhitzung). Also aufpassen dass nichts blockiert! Die Impulspause darf sowohl länger als auch kürzer als bei einem Analogservo sein. Ulli-B
Karl H. schrieb: > 1520 Mikrosekunden sind ~ 1.5 Millisekunden. Na, klingelts? Dein Taschenrechner ist kaputt.
Frickelfritze schrieb: > Karl H. schrieb: >> 1520 Mikrosekunden sind ~ 1.5 Millisekunden. Na, klingelts? > > Dein Taschenrechner ist kaputt. Sehe ich nicht ganz so. 1520 dividiert durch Tausend (Komme um 3 Stellen nach links verschieben) ergibt ca. 1.5 (oder störst du dich daran, dass ich grundsätzlich einen Kommapunkt schreibe, wie es in Programmiersprachen üblich ist?)
Vielen Dank für eure Antworten. Ich denke das ihr mir damit gut weiter geholfen habt!!! Da wir ja gerade bei den Servos sind, hätte ich zusätzlich noch ein paar Fragen. Mein Projekt soll eine Flugsteuerung werden. Wenn ich mich nicht verzählt habe, dann brauche 5 Eingänge und 9 Ausgänge. Ich habe einen 6 Kanal Empfänger. Diesen wurde ich gerne an einen MC anschließen. Der Empfänger wird vermutlich auch nur ein Servo signal senden. Meine Vermutung ist nun, das ich, um es korrekt zu machen, mit Interrupts arbeiten muss. Richtig??? Ich glaube ich habe aber nur 2-3 Eingänge die mit Interrupts arbeiten können. Richtig??? Sprich wenn das so ist, dann kann keinen atmega8 nehmen oder einen 32er. Habt ihr eine Idee wie ich nein Problem lösen kann???
Patrick89 schrieb: > Habt ihr eine Idee wie ich nein Problem lösen kann??? Sieh zu, dass du an das Summensignal deines Empfängers ran kommst oder besorg dir einen, der das frei Haus liefert. Im Summensignal sind die 'Pulse' aller Servos enthalten.
Patrick89 schrieb: > Und wenn das nicht möglich ist??? Dann hast du wohl ein Problem, so wie das aussieht.
Patrick89 schrieb: > Und wenn das nicht möglich ist??? Dann ver-odere mit ein paar Gattern alle Servo Ausgänge des Empfängers zu einem und speise damit deinen Controller.
Summensignal scheint mir dann doch das beste zu sein. Ich werde mal schauen ob ich einen Empfaenger auftreiben kann der Spektrum unterstuetzt bzw. wo man Spektrum Satelliten anschliessen kann...
Frickelfritze schrieb: > Patrick89 schrieb: >> Und wenn das nicht möglich ist??? > > Dann ver-odere mit ein paar Gattern alle Servo Ausgänge des Empfängers > zu einem und speise damit deinen Controller. Das kann funktionieren, muss aber nicht.
Frickelfritze schrieb: > Warum sollte es nicht? Ein moderner Empfänger könnte durchaus alle Servosignale gleichzeitig erzeugen anstatt nacheinander. Beim VerODERn käme dann nur Müll raus.
Frickelfritze schrieb: > Karl H. schrieb: >> Das kann funktionieren, muss aber nicht. > > Warum sollte es nicht? Weil gerade bei 2.4Ghz Fernsteuerungen, die auf WLAN Technik beruhen, noch lange nicht gesagt ist, dass sie ihre Servopulse tatsächlich nacheinander oder überlappend generieren. Gerade im Sinne von einer Erhöhung der Pulsrate an die Servos ist davon auszugehen, dass sie genau das nicht tun.
:
Bearbeitet durch User
chris schrieb: > Ein moderner Empfänger könnte durchaus alle Servosignale gleichzeitig > erzeugen anstatt nacheinander. Das lässt sich ja relativ leicht feststellen indem man zwei Sevosignale gleichzeitig mit einem Oszilloskop anschaut und beurteilt ob sie zeitmultiplex vom Sender kommen (also nacheinander) oder nicht (also ihre Startflanke gleichzeitig kommt).
Im Prinzip: ja Ich glaube allerdings nicht, dass er ein Oszi hat.
Doch ein altes auf dem Dachboden.... aber ob das noch geht ;) Ich gehe mal nicht davon aus! Kann ich denn nicht einfach nur den Satelliten nehmen von Spektrum?
Oder mal anders gedacht. Der Empfaenger gibt mir ja ein Servo Signal aus. Dieses kann mein uC ja Auswerten. Wenn ich jetzt fuer jeden Kanal oder fuer 2 Kanaele einen uC nehme, die Daten auswerte diese dann per USART an einen Controller sende, der dann meine Servos steuert. Das waere doch machbar oder??? Dann bliebe nur noch die Frage wie verdrahte ich mehrere uC's so miteinander....
Wenn 6 Kanäle CPPM reichen, sollte der Spectrum R615X oder der Klon Orange R615X gehen (hab kein Spectrum). Gruß
Vorerst sollte der reichen, aber nicht auf dauer.... Ich bin zur Zeit dabei mich einzulesen wie man ein Bussystem aufbaut.
USART ist keine gute Idee. Wenn ich genug Pins habe, dann würde ich SPI nehmen. MISO, MOSI und CLK kommen an jeden Client und für jeden Client wird noch eine Select Leitung spendiert. Das macht dann bei 6 Eingängen 9 Pins für die Eingangsstufen am zentralen µC. Achte darauf, dass deine Client-µC über einen Timer mit Input Capture verfügen. Sonst kriegst du Ärger beim Ausmessen der Pulse. Wenn du kein Summensignal auftreiben kannst, dann würde ich hier ausnahmsweise zustimmen, auch wenn es meistens keine gute Idee ist, mehrere µC einzusetzen, wenn einer alleine auch reichen würde. Aber für den einen brauchst du nun mal das Summensignal. Probieren könnte man es, ob man es aus den Servoausgängen erzeugen kann.
Kann man kaufen: http://www.hobbyking.com/hobbyking/store/__54896__RMILEC_High_Precision_PWM_PPM_SBus_Signal_Converter_V2.html oder bauen: http://www.rcgroups.com/forums/showpost.php?p=12410349&postcount=10
Patrick W schrieb: > Und das soll funktionieren mit den paar dioden??? Es kann funktionieren. Es ist ein wired-OR. Es hängt alles davon ab, wie dein Empfänger die Servosignale generiert. Nacheinander oder parallel zueinander. Bei den alten Fernsteuerungen war es nacheinander, weil sich das ganz einfach aus dem PPM Signal ergeben hat, das über die Funkstrecke gegangen ist. Aber bei 2.4GHz Anlagen ist die Übertragung per Funk völlig anders. Bei alten Fernsteuerungen hat der Sender einfach das Funk-PPM Signal auf ein Schieberegister gelegt und an den Ausgängen sind die Servo Signale ganz von alleine richtig herausgefallen. Bei den GHz Anlagen geht das aber nicht mehr, hier muss der Empfänger die Servopulse selbst generieren. Die Frage ist nur: wie macht er das? Generiert er sie für n Ausgänge nacheinander oder generiert er alle Pulse auf den n Ausgängen parallel. Im ersten Fall funktionert die Dioden Lösung immer noch, sofern er eine winzige zeitliche Lücke zwischen den Pulsen auf den Leitungen lässt, die reicht um für die Input Capture Unit eine Flanke zu erzeugen.
:
Bearbeitet durch User
Karl H. schrieb: > Es hängt alles davon ab, wie dein Empfänger die Servosignale generiert. > Nacheinander oder parallel zueinander. Tja, gute Frage. Bei den Fernsteuerungen aus dem oberen Preissegment und Empfängern mit relativ vielen Kanälen wechselt das je nach Programmierung, möglichst zeitliche versetzt, um nicht alle Servos gleichzeitig anzusteueren und damit die Stromversorgung zum Einknicken zu bringen, bei bestimmten Konstellationen gleichzeitig (für große Segler mehrere Querruder- oder Wölbklappenservos, bei Motormaschinen/ Jets 2 Höhenruderservos, die synchron laufen müssen). Kann man nur testen oder den Empfänger kennen.
> Im ersten Fall > funktionert die Dioden Lösung immer noch, sofern er eine winzige > zeitliche Lücke zwischen den Pulsen auf den Leitungen lässt, die reicht > um für die Input Capture Unit eine Flanke zu erzeugen. Bei den "analogen" Empfängern gab es keine Lücke zwischen den einzelnen Kanalimpulsen. Man konnte sich behelfen, indem jeder zweite Kanal verodert wurde. Dann entsprach die Lücke der Impulslänge des 2. .. 4. .. usw. Kanals. Das Dumme ist nur, dass dies nur für eine ungerade Anzahl von Kanälen funktioniert. Doch einen solchen Empfänger gibt es von Spektrum nicht. Also ist es ein digitaler Empfänger. Jetzt gilt es heraus zu finden, ob die die Kanäle nacheinander oder gleichzeitig ausgegeben werden. Ulli-B
Da ich leider kein Ozi habe, kann ich nur raten.... Besser gefallen wuerde mir da die Methoe mit TWI. Ich habe mich auch schon ein bisschen eingelesen. Klingt erst einmal recht simpel diese Loesung. Ich muss mich natuerlich noch genauer einlesen aber ich denke damit sollte es dann gehen... Eine weitere Sache ist, das ich verschiedene Empfaenger anschliessen koennen will... Ein paar freunde hatten auch schon interesse gezeigt. Aber wenn ich dann immer nur auf einen Empfaenger einschraenke, dann ist das nicht so toll ;)
Patrick W schrieb: > Da ich leider kein Ozi habe, kann ich nur raten.... > > Besser gefallen wuerde mir da die Methoe mit TWI. TWI ist Overkill. Du stellst dir das jetzt alles ein bischen zu einfach vor. Du wärst nicht der erste, der draufkommt, dass die Inter-µC Kommunikation dann doch nicht so einfach ist, wie ursprünglich gedacht. Was brauchst du den wirklich von deinen Clients. Du willst die Pulslängen wissen. Dazu brauchst du keine 30 verschiedene Kommandos und aufwändiges Protokoll, sonder der Client soll seinen gemessenen Wert rausrücken. Und das so einfach und schnell wie möglich. Client selektieren 1. Byte holen -> High Byte 2. Byte holen -> Low Byte Client deselektieren Einfacher und schneller als mit SPI und ein paar Select-Leitung geht das nicht.
:
Bearbeitet durch User
Hi, nee Leute, ich glaube hier haben noch nicht so viele damit gearbeitet. Das Summensignal ist schön aber wenn man nicht rankommt bringt es einem nichts. Das Summensignal hat übrigens normalerweise eine Pause von 300µs und das Servosignal wird von Flanke zu Flanke gezählt. Also neutral ist 300µs Pause und 1200µs high. Das machen die meisten Funken immer noch intern, wenn sie Modulbasiert sind also das Summensignal ist immer noch der Standard zwischen dem µC des Senders und dem HF-Teil. Da allerdings invertiert. Aus dem Empfänger (von 40MHz Multiplex, Simprop bis hin zu aktuellen 2,4GHz Chinesen) kommen dann die Servosignale nacheinander und in der richtigen Reihenfolge heraus. Hier habe ich gerade einen FrSKY Empfänger, der macht zwischen den Signalen sogar noch netterweise 60µs Pause. So ein Frame kommt alle 17,5ms. Da müsste man nichtmal Ints bemühen und könnte pollen. Verarbeitung dann nach dem letzten Signal. Ich will gerade sowas ähnliches machen und ich glaube damit mache ich mich einfach vom Acker. Das geht natürlich auch eleganter mit PCINTs aber eben nicht mit einem Mega8 oder 16, die haben das noch nicht. Die Krücke Verodern würde mit der 60µs Pause auch gehen, wäre aber ja gar nicht nötig. ----- Schleife: Warten bis Kanal 1 low (falls schon angefangen) Warten bis Kanal 1 high Timer nullen Warten bis Kanal 1 low Kanal_1_Zeit = Timer Warten bis Kanal 2 high Timer nullen Warten bis Kanal 2 low Kanal_2_Zeit = Timer . . . Warten bis Kanal n low Kanal_n_Zeit = Timer Dann Werte verhackstücken und wieder nacheinander ausgeben, ähnlich wie oben. Das ist grausiger Stil und man lässt bei mehr als 3-4 Kanälen jeden zweiten Frame aus. Die Servos interessiert das aber nicht und wenn man das per PWM wieder ausgeben will, also mehr in Richtung Echtzeit, hat man nicht zuviele Ressourcen oder fängt sich Probleme mit Überschneidungen der Signale ein, wenn man die Signale per OCR manuell ausgeben will. Bei 8 Kanälen ist der Frame einfach irgendwann voll. Als Fehlerkompensation kann man bei jedem Kanal noch aus der Warterei aussteigen wenn die Zeit nicht mehr realistisch ist. Für mich geht das jedenfalls wunderbar so wie beschrieben, da ich mit der Reaktionszeit überhaupt kein Problem habe und genau weiß, was der Empfänger macht. Bei bestimmten Anwendungen kann so ein Delay von 50-100ms aber schon eine Rolle spielen. Bei Heckservos für Helis oder der Lenkung für Glattbahner ist es schon ein Unterschied, ob das Servo schnell oder superschnell ist und das liegt in dieser Grössenordnung. Flugregelung geht in diese Richtung aber bei der Fragestellung mache ich mir da wenig Sorgen, das wird sowieso nichts. Schön, daß wir mal drüber gesprochen haben. Ich wollte das eigentlich jetzt mit den PCINTs machen und hatte mich schon auf das herumgeprokel mit den Registern "gefreut" aber nun mache ich das so banal und schmutzig per Polling und warten. Unelegant aber das verstehe ich auch in ein paar Monaten wieder auf Anhieb und für die meisten Zwecke reicht es locker. Gruß, Norbert
Norbert S. schrieb: > Flugregelung geht in diese Richtung aber bei der Fragestellung mache ich > mir da wenig Sorgen, das wird sowieso nichts. Was meinst du damit??? Ich habe mir jetzt SPI genauer angeschaut. Ich denke das ich das verwenden werde. So als grobe Zusammenfassung was meine verstanden zu haben: Master MOSI auf die Slaves MOSI Master MISO auf die Slaves MISO Master SCK auf die Slaves SCK Master irgend ein Port auf die Slaves SS Im Master und in den Slaves die ISR aktivieren und die entsprechenden Routinen dafuer schreiben. Der Master selektiert dann einen Slave indem er Portx (der mit dem Port SS vom Slave verbunden ist) von High auf Low zieht. Danach sendet der Master ein Byte an den Slave. Der Slave arbeitet dann seine ISR ab und sendet noch in dieser Methode ein Byte an den Master. Danach kommt dann der naechste Slave an die Reihe. Was passiert eigentlich, wenn sich ein Slave mal aufhaengt oder einfach laenger braucht als angenommen? Kann man die Transaktion dann auch vorzeitig beenden?
Sorry hatte vergessen zu schreiben, das nachdem der Slave das Byte an den Master gesendet hat, springt der Master in seine ISR und macht da was. Danach kann dann ein anderer Slave bedient werden.
Patrick W schrieb: > Norbert S. schrieb: >> Flugregelung geht in diese Richtung aber bei der Fragestellung mache ich >> mir da wenig Sorgen, das wird sowieso nichts. > > Was meinst du damit??? Hi, Damit meine ich, daß Du eine Flugregelung wenn es z.B. um einen Multicopter geht, vermutlich nicht hinbekommen wirst. Das ist nicht böse gemeint aber das lese ich an der Fragestellung ab. Patrick W schrieb: > Was passiert eigentlich, wenn sich ein Slave mal aufhaengt oder einfach > laenger braucht als angenommen? > Kann man die Transaktion dann auch vorzeitig beenden? Natürlich kann man, muß man sogar. Daß Dir der Begriff "Timeout" scheinbar nicht geläufig ist, ist so ein Indiz. Das ist simples Handwerkszeug um sowas auf die Beine zu stellen. Wenn Du Dir das jetzt erst noch alles erarbeiten musst, ist eine "Flugsteuerung" noch in ganz weiter Ferne. Wie gesagt, ist nicht böse gemeint. Ich hab mich auch schon oft mit Projekten übernommen aber auf dem Weg dahin eine Menge gelernt. Auch das kann Spaß machen und ein Erfolgserlebnis sein. Gruß, Norbert
Nun ich bin mir sicher das ich mich nicht uebernehmen werde. Und selbst wenn doch, ich stelle hier nur ganz normale Fragen auf die ich eine Antwort erhalten moechte. Nicht boese gemeint ist schoen und gut, nur leider liegt es nur im Ermessen desjenigen der gemeint ist ;) Ich steh da drueber, weil ich solche Aussagen schon des oefteren gehoert habe und immer mit dem gleichen Resultat... Am Ende habe ich es doch geschafft ;) Nun gut ich moechte an dieser Stelle jeden bitten nicht mehr mit solchen Aussagen zu kommen. Auf diese kann ich verzichten und sie helfen auch keinen Weiter.... Sorry Norbert, ist halt nicht boese gemeint ;)
Hi, Vielleicht schreibst Du mal, was Du denn da bauen willst. Mehrere µC hernehmen und sich dafür die Kommunikation antun ist jedenfalls erstmal nicht das Mittel der Wahl, nur weil man die normalen Mittel nicht beherrscht. Und natürlich bist Du Dir sicher, daß Du Dich nicht übernimmst. Das ist man immer solange, bis man es selber merkt (oder auch nicht). Lass Dich nicht aufhalten. Die Servogeschichte per SPI oder was auch immer auf mehrere Controller zu verteilen ist jedenfalls eine üble Krücke, die mehr Probleme schafft als sie löst. Was spräche denn dagegen, es so banal zu machen, wie ich vorgeschlagen habe? Und nochwas: Wenn ich hier schon lange Texte schreibe, dann nehme ich mir auch heraus, Deine Ansätze zu kritisieren. Oft ist der Ansatz schon Quatsch und das muß man sagen dürfen. Du hast ja leider nicht erzählt, was Du da vor hast. Wenn Du aber keine Kritik hören willt und nur noch Tipps, wie Du die unsinnige Kommunikation hingefrickelt bekommst, dann kannst Du Deine Zeit gerne alleine in diesen Schwachsinn versenken. Ich wundere mich, daß ich der Erste bin, der hier mal etwas deutlicher wird. Gruß, Norbert
Patrick W schrieb: > Da ich leider kein Ozi habe, kann ich nur raten.... Ein kleine Logikanalysator, wie es ihn bei Ebay schon für 7€ gibt, würde völlig reichen. (z.B. 141803548716)
Nun ich will einen Flugkontroller entwickeln. Dieser Controller hat mehrere Modis in denen er bspw. die Motoren und die Winkel steuert in der die Motoren zeigen. Ein anderer Modi waere eine ganz normal Flaeche. Das jetzt genau zu beschreiben wie was wann und wo funktioniert waere zu viel. Gut, daher habe ich 5 Kanaele die von dem Empfaenger kommen. Diese Kanaele sind dann auf entsprechende uC's verteilt die mit das Signal holen, zwischenspeichern und an den Master weiterleiten wenn diese dazu aufgefordert werden. Die Aufgabe des Masters ist einfach die Servos und die Motoren zu steuern und zwar genau so wie ich es brauche. Es ist aber nicht nur die Weiterleitung der Servosignals etc. es werden auch noch einige Entscheidungen getroffen die fuer das Flugverhalten wichtig sind. Diese sind aber hier nicht relevant. Warum will es nicht so wie du machen? Ganz einfach, es klingt fuer mich verwirrend. Das einzige was ich noch behalten habe ist, "Die Kruecke verdrehen" glaube ich. Ich moechte das so haben, das ich eigentlich jeden stinknormalen Empfaenger anschliessen kann und es geht. Deswegen will ich mir die ganzen Servosignale holen, diese dann zu meinem eigentlichen Flightcontroller senden, dieser wertet diese Daten dann aus und macht was immer er damit machen soll... Die Sachen die ich mache, will ich immer so machen, das Teile der breiten Masse sie verwenden koennen. Erst wenn ich das geschafft habe, bin zih zu frieden. Ich sehe jetzt auch keinen Grund warum das nicht klappen sollte mit den mehreren uC's.
Hi, Wenn meine simple Methode (primitiver geht es nicht) für Dich schon verwirrend ist dann viel Spaß. Berichte mal wie das dann fliegt. Gruß, Norbert
Ich vermute einfach mal das du einen schlechten Tag gehabt hast heute... Wie gesagt auf solche Antworten kann ich gerne verzichten!!!! Ich moechte dich deswegen auch bitten mir nicht mehr zu "helfen"... Bitte hab Verstaendnis dafuer. Danke.
Patrick W schrieb: > Danke. Wenn sich die Dankbarkeit dermaßen in Grenzen hält, kannst du dir diese Art von "Danke" auch gerne sparen.
Koennte man sich vielleicht mal wieder auf das Thema konzentrieren??? Zusammenfassung: - Summensignal ist erstmal aussen vor. Spaeter vielleicht als zusatz. - SPI klingt fuer mich jetzt erstmal am besten da es sich "recht einfach" entwickeln laesst. Zudem gefaellt mir die Logik ganz gut. Ein Master, mehrere Slaves. Die Slaves capturen die Signale vom Empfaenger und geben diese dann an den Master weiter der dann entscheidet was er mit den Signalen anfangen soll... Ich werde erstmal diesen Ansatz weiter verfolgen.
Patrick W schrieb: > Die Slaves capturen die Signale vom Empfaenger und > geben diese dann an den Master weiter der dann entscheidet was er mit den > Signalen anfangen soll... So funktioniert SPI nicht. Nicht ohne Grund wird zwischen Master und Slave unterschieden. Richtig müssten die Slaves die Pulsdauern messen und der Master holt die Messergebnisse bei den Slaves ab.
Patrick W schrieb: > So als grobe Zusammenfassung was meine verstanden zu haben: > > Master MOSI auf die Slaves MOSI > > Master MISO auf die Slaves MISO > > Master SCK auf die Slaves SCK > > Master irgend ein Port auf die Slaves SS > > Im Master und in den Slaves die ISR aktivieren und die entsprechenden > Routinen dafuer schreiben. > > Der Master selektiert dann einen Slave indem er Portx (der mit dem Port > SS vom Slave verbunden ist) von High auf Low zieht. Ja > Danach sendet der Master ein Byte an den Slave. Der Slave arbeitet dann > seine ISR ab und sendet noch in dieser Methode ein Byte an den Master. Ein Slave kann bei SPI nicht von sich aus senden. DIe Begriffe Senden und Empfangen sind bei SPI etwas missverständlich. SPI ist ein Byteaustausch. Beide, Master und Slave sind gleichzeitig Sender und Empfänger. Ein Slave kann von sich aus überhaupt nichts tun. SPI > Was passiert eigentlich, wenn sich ein Slave mal aufhaengt oder einfach > laenger braucht als angenommen? > Kann man die Transaktion dann auch vorzeitig beenden? Du brauchst nichts vorzeitig beenden. Der Master zieht sein Ding durch, egal ob der Slave bereit ist oder nicht.
Stimmt, das mit dem Senden und Empfangen ist wirklich ein wenig missvertstaendlich. Wie darf ich mir den Ablauf grob vorstellen? Master legt SS Leitung auf Low -> Master sendet Byte an den Slave -> Slave fuehrt seine ISR aus -> Slave sendet Byte an den Master -> Master fuehrt seine ISR aus -> Master legt SS Leitung auf High -> Fortfahren mit dem naechsten Slave. So wuerde ich mir das jetzt vorstellen wie die Kommunikation ablaeuft. Oder werden die Bytes gleichzeitig vom Master und Slave uebertragen?
Patrick W schrieb: > Koennte man sich vielleicht mal wieder auf das Thema > konzentrieren??? > > Zusammenfassung: > > - Summensignal ist erstmal aussen vor. Spaeter vielleicht als zusatz. > - SPI klingt fuer mich jetzt erstmal am besten da es sich "recht > einfach" > entwickeln laesst. Zudem gefaellt mir die Logik ganz gut. Ein Master, > mehrere Slaves. Die Slaves capturen die Signale vom Empfaenger und > geben > diese dann an den Master weiter der dann entscheidet was er mit den > Signalen anfangen soll... > > Ich werde erstmal diesen Ansatz weiter verfolgen. Ich würde Dir folgenden Ansatz empfehlen: Such dir einen Mikrocontroller aus, schliesse eine LED an und lasse diese im Sekundentakt blinken. Dann weisst du, dass die Quarzfrequenz mit der im Programm verwendeten Frequenz überein stimmt. Dann verbinde den MC mit einem Empfängerausgang (zB Kanal 1) sowie einem Servo. Werte die Impulse aus und gebe sie 1:1an den Servo weiter. Schliesse noch einen zweiten Kanal vom Empfænger und einen zweiten Servo an. Werte jetzt beide Kanäle aus und gebe sie weiter an die Servos. Die Servosignale müssen ohne merkliche Verzögerung und ruckelfrei an den Servos an kommen. Wenn du das dann hin bekommen hast, dann kannst du dir die meisten deiner Fragen selbst beantworten. Und dann kannst du dir auch überlegen, ob es Sinn macht, mehrere MC zu verwenden. Ulli-B
Patrick W schrieb: > Oder werden die Bytes gleichzeitig vom Master und Slave uebertragen? Während 1 Byte vom Master zum Slave geht, geht 1 Byte vom Slave zum Master Stell dir vor, du und dein Kumpel sitzen sich gegenüber. Jeder hat einen Zettel vor sich, auf dem jeder einen Bytewert aufschreiben kann. Auf dein Kommando hin (du bist der Master) nimmt jeder seinen Zettel mit der rechten Hand und schiebt ihn zum Gegenüber rüber, der ihn mit der linken Hand entgegen nimmt. Wichtig dabei: dein Kumpel kann sich nicht wehren! Wenn du das Kommando gibst, dann werden die Zettel ausgetauscht. Egal ob dein Kumpel fertig ist oder nicht. Deshalb kann es hier auch kein Timeout geben. Denn wenn der Master seinen Bytetransfer anstösst, dann kommt von der Gegenstelle 1 Byte rein. Ob du die weitere Bearbeitung im Master mittels Interrupt machen willst oder nicht, ist Ansichtssache. Wenn du SPI full speed fährst, dann dauert die Übertragung von 8 Bit gerade einmal 16 Prozessor Taktzyklen. Das kann man mittels Polling erwarten. Wenn dir die Pulsinformation als ein Wert zwischen 0 und 255 reicht (256 mögliche Positionen) dann braucht es da überhaupt keine Sonderbehandlung oder Interrupts. Der Slave stellt seinen ermittelten Wert, sobald er ihn hat, einfach in sein SPDR Register und der Master holt sich diesen vom Slave bei seiner nächsten Abfragerunde, ohne dass sich der Slave weiter darum kümmern muss. Vergleichbar damit, dass dein Kumpel sofort nach Erhalt deines Zettels seinen Messwert auf den Zettel schreibt damit du den Wert sofort kriegst wenn du den nächsten Zetteltausch anleierst. Lediglich wenn da für ein Datenpaket mehr als 1 Byte ausgetauscht werden muss (High Byte / Low Byte bei 16 Bit Werten) ist eine Behandlung mittels Interrupt durch den Slave vernünftig. Vergleichbar damit, dass dein Kumpel erst mal auf den Zettel schauen muss um zu wissen, welches Byte du jetzt eigentlich von ihm wissen willst. Aus dem Bauch raus würde ich sagen, dass wenn man die Knüppelbewegung an einem Fernsteuersender in 256 Abstufungen auflöst (auf Trimmweg nicht vergessen!) dann sollte das eigentlich reichen. So fein kann kein Mensch seine Hand führen. Aber das ist nur IMHO und man müsste es ausprobieren.
:
Bearbeitet durch User
Ulli-B schrieb: > Ich würde Dir folgenden Ansatz empfehlen: Ich unterstütze diesen Vorschlag, auch wenn er bei der Auswertung von im Endeffekt 5 Empfänger Ausgängen dann in Schwierigkeiten kommen kann. Aber erst mal ein wenig Erfahrung sammeln schadet nie. Im Moment sieht es auch für mich danach aus, dass sich der TO hier etwas vorgenommen hat, was noch ein paar Nummern zu gross für ihn ist. Und der Einsatz mehrerer Prozessoren verkompliziert die Dinge insofern, weil dann eben noch eine Kommunikationsebene mit dazu kommt, die man nicht hat, wenn alles auf einem Prozessor läuft. Auch wenn es hier das Problem lösen würde, dass er nicht genügend Input Capture Einheiten auf seinem zentralen µC für alle 5 Kanäle hat.
Hi, ich glaube PCINT wurde schonmal erwähnt. Anbei das woran ich gerade frickel. Die Kanäle werden mit PCINTs eingelesen in Pc_int1 und 2. Dazu nutze ich den freilaufenden Timer2 weil mir das reicht. Die Auflösung ist mit 16µs nicht prickelnd aber +/-31 Schritte reichen mir locker. Das geht natürlich viel besser mit nem 16bit Timer wenn man will. Die Ausgabe für das Servo ist noch schlimmer mit dem Overflow von Timer1 aber auch das reicht mir, da das Servo nur 3 feste Positionen anfahren soll. Da kommt noch einiges dazu aber das werden einfache Schaltfunkionen oder Motorregelungen per PWM, wo mir die Auflösung der eingelesenen Kanäle wiederum reicht. Der Teil mit den PCINTS dürfte aber erstmal erklären, wie man die Signale bulletproof mit einem µC einliest. Hätte ich mir das per Hardware nicht verbaut, könnte man das mit Timer1 nahezu jitterfrei einlesen. Ausgabe jitterfrei geht dann aber eigentlich nur per PWM und da ist bei der M88-Familie schnell Feierabend oder man trickst extrem herum. Wollte ich sowas für ein Bastelprojekt machen müssen, würde ich das Problem mit Hardware bewerfen. Bei einem Mega640 hat man 16bit PWM mehr als genug. Gruß, Norbert
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.