Hallo,
ich bin ein Codefritze bei MultiWii und habe gerade daran gearbeitet, die PilotLamp anzusteuern, dabei handelt es sich um eine schaltung mit 3 LEDs und einem Buzzer. diese werden üebr einen Mikrocontroller gesteuert.
Man muss dem Gerät verschiedene Frequenzen senden damit es tut was es soll:
Grün an: Freuquenz A
Grün aus: Frequenz B
Blau an: Frequenz C
Blau aus: Frequenz D
usw...
Man muss mindestens 3 perioden lang diese Frequenzen senden, damit das klappt.
Jetzt habe ich das wie folgt gemacht:
void gen_pl_freq(uint16_t device)
{
uint8_t i;
for (i=0;i<3;i++) { // Four waveforms are required. maybe three??
PL_PIN_ON;
delayMicroseconds(device);
PL_PIN_OFF;
delayMicroseconds(device);
}
return;
}
es wird 3 mal der pin ein und wieder ausgeschaltet. Es ensteht also ein Rechteckimpuls mit einem Puls Pause Verhältnis von 1.
Leider habe ich anschließend festgestellt, dass beim Buzzer der eine Frequenz von 650Hz benötigt, die Zykluszeit des Hauptzyklus extrem verletzt wird, das hat zu folge, dass der Hubschrauber sich seltsam verhält.
Ich müsste also diese Operation auslagern, wäre ich jetzt auf einem PC würde ich einen Hintergrundthread draus machen, hierzu fallen wir nur die Timer ein.
Ich bin leider recht unerfahren in Processing und Arduino.
Ich nutze einen MEGA2560. Kann mir vielleicht jemand helfen wie ich diese Operation so hin bekomme, dass der Zyklus nicht beeinträchtigt wird?
uwefed:
Ich sehne mich nach einen Kristallkugel!!
Grüße Uwe
Ich verstehe Deinen Kommentar nicht!
Die Frage ist doch ziemlich gut formuliert!
Ich habe sie so verstanden:
Ausgangs Situation:
A) Es gibt eine Hauptschleife, die für den Helikopter die aktuelle Lage korrigiert. Diese Hauptschleife läuft ca. alle 3ms, diese Zeit sollte darf nicht zu stark verzögert werden, da sonst die Regelung nicht klappt!
B) Gibt es ein Produkt, welches nicht über ein Protokoll sondern via Frequenzen angesprochen wird. Diese Frequenzen müssen erzeugt werden.
Ist:
Diese Frequenzen werden zur Zeit innerhalb des Hauptzyklus als Unterfunktion entsprechend der Anforderung erzeugt. Wie, steht ja schon oben.
Will man nun den Summer einschalten muss mal 3x eine Frequenz von 650Hz erzeugen.
Wird dieses in der Unterfunktion erledigt, dauert das so lange, dass der Hauptzyklus aus dem Ruder läuft!
Und jetzt nochmal die Frage:
Wie schafft man es, an einem Pin eine Frequenz vom Wert X auszugeben, ohne dass der Prozessor damit belastet wird.
Oder anders gefragt:
Gibt es so etwas wie ein Frequenz Generator den ich nutzen kann!
ich habe jetzt keine Idee ob es weiter hilft. Aber schau dir doch mal die Sache mit den Timern an.
Die ESC's werden ja auch so angesprochen!
Die Frage ist nur, ob überhaupt noch welche frei sind.
danke für Dein erstes Posting,
ich verstehe manche Leute in den Foren nicht, immer den erhobenen Zeigefinger griffbereit aber prinzipiell nie etwas wichtiges zu sagen...
Seis drum.
Du hast das relativ gut zusammeng efasst (besser als ich ) Ich hatte allerdings vergessen, dass diese Probleme nur auftreten wenn ich ein GPS über den serial port Anschliesse
Da unser Multicopter projekt von Pro Micro bis Mega2560 von Singlecopter bis Octocopter so ziemlich alles unterstützt ist das mit den Timern eine Sache: Auf dem Mega isnd meines Wissens nach noch welche frei, alos würde eine Timerlösung für den Mega in betracht kommen. Leider ist aber die Priorität dieses "Piepse" im Projektumfeld so gering, dass ich wohl kaum einen Timer zur Verfügung bestellt kriege :-/.
Ich bin mittlerweile der Meinung, dass dieses Ding eine Sackgasse ist und schlichtweg nicht geeignet für unseren FC ist.
Ich würde noch die Möglichkeit sehen, das teil über einen eigenen Controller über I²C anzusteuern.
Aber zusammen gefasst: Ein solches teil derart kompliziert anzusteuern für 3 LED und einen Buzzer, da kann ich die auch direkt an freie Pins auf den Boards anklemmen.
Ich habe gestern Abend ziemlich lange daran gesessen und viele Möglichkeiten ausprobiert das Teil anzusprechen, unter anderem auch tone() und noTone(), auch das hat zu Versatz geführt, das spricht offenbar dafür, dass der Hauptzyklus schon ziemliche Fluktuationen beim Gebrauch von GPS via Serial aufweist.
uwefed:
Ich sehne mich nach einen Kristallkugel!!
Grüße Uwe
Ich verstehe Deinen Kommentar nicht!
Die Frage ist doch ziemlich gut formuliert!
Ich habe sie so verstanden:
Ausgangs Situation:
A) Es gibt eine Hauptschleife, die für den Helikopter die aktuelle Lage korrigiert. Diese Hauptschleife läuft ca. alle 3ms, diese Zeit sollte darf nicht zu stark verzögert werden, da sonst die Regelung nicht klappt!
B) Gibt es ein Produkt, welches nicht über ein Protokoll sondern via Frequenzen angesprochen wird. Diese Frequenzen müssen erzeugt werden.
Daß es um einen Modelhelikopter ging war mir aus der Beschreibung nicht klar. Auch nicht die Zusammenstellung der Steuerung ( RC-Arduino- Helicopterelektronik?)
Im Prinzip geht das darum, so was wie eine Hauptschleife zu haben.
Die absolute Priorität hat und schön schnell ist.
Und dann drum rum ein paar Funktionen, die teuer, sprich Zeit intensiv.
In Visual Studio mache ich eine Hintergrund Prozess auf, gebe dem einen Job, und frag ab und zu mal was so los ist.
Sowas würde ich gerne mit dem Arduino auch machen.
Und dabei ist es egal, wenn der Nebenprozess ein wenig hakt!
Oder ein anderes Beispiel:
Ich habe eine Kommunikation mit einer Maschine.
Die darf nicht unterbrochen werden!
Jetzt möchte ich aber das mein Board noch was anderes macht! Zum Beispiel eine Website aktualisieren.
Das kann ich aus Timing Gründen nicht in meiner Maschinen Schleife machen.
Das soll nebenher laufen! Und da ist es dann egal, wenn ich nicht in Echtzeit bin!
In unserem Fall, ist es halt die Aufgabe, dafür zu sorgen, das ein Port eine Frequenz ausgibt.
Ein Port-Pin kein Timer, den gibt es leider nicht mehr!
Danke für die sehr gute Zusammenfassung.
Die kommunikation zwischen Arduino und Pilotlamp basiert auf bösem Reverseengineering per Frequenzgenerator und trial and error.
Die Pilotlamp hat einen STC11F01 MCU (8051 core) und ist an INT1 mit dem Arduino verbunden, zusätzlich noch 5V und GND.
Wie bereits erwähnt bin ich eher Programmierer, also Java, ST etc. Ich bin relativ neu auf Mikroprozessorebende, darum mach ich ja auch nur diesen periphären Kram.
Aslo hätte ich auch überhaupt keinen Ansatzpunkt wie ich dieses Teil mal anders ansprechen kann. Ich denke das beste wäre es, die FC Platine von X-Aircraft zu haben und zu messen was da raus kommt. bzw den Quellcode zu haben.
Wenn Du aber mit dem PRozessortyp was anfangen kannst nur zu.
Nils
ps.: Solange Du keine GPS funktionen oder das GUI dran hast geht das Pilotlamp mit Multiwii ganz gut.
jevermeister:
Solange Du keine GPS funktionen oder das GUI dran hast geht das Pilotlamp mit Multiwii ganz gut.
Wer gibt sich denn mit sowas zufrieden?
Ich will alles auch 12 Kanäle
Gruß
Carsten
PS: Der Prozessor sagt mir nichts. Aber ich kann mir nicht vorstellen, dass die eine so dämlich Anbindung nutzen.
Die nutzen das doch auch an ihrer FC?!?!?
Hi,
Ja, aber Xaircraft ist n superteueres Riesending, da wird alles modular zusammen gebaut, ich glaube sogar, dass alle Lageberechnungen auf einem separaten CPU durchgeführt werden, der per I²C angebunden ist, die FC ist da wohl nur Manager. Aber es ist alles geschlossen, Quellcode und Hardware sind nicht offen.
Ich werden buzzer auf dem PilotLamp weiterhin nutzen aber die LEDs sind mir den jetztigen aufwand irgendwie nicht wert...
Leider habe ich gestern den Buzzer getötet,
ich hatte einen dauerimpuls auf den Ausgang gelegt und da fing der Buzzer an zus tinken und ist seitdem nur noch ganz leise.
Wundert mich aber, da ja der Chip den Buzzer ansteuert und nicht mein MEGA.
Hi,
ja Ersatz ist da aber diese Ansteuerung ist offenbar eine Sackgasse.
Momentan gibt es eine debatte, die Cycletime einzufrieren. DAs schein ebsser für die sensoren zu sein. Ist seltsam, ich bind avon ausgegangen, dass die Sensorauswertung streng zyklisch erfolgt.
Naja, sollte die Zykluszeit festgelegt werden, dann ist es das aus für die Pilotlamp.
Ich habe diese Zykluszeitverlutzsprobleme bei jeglicher Kombination, egal ob ich die Lampe oft nutze oder selten, die Auswertung ergibt ausreisser in der Zykluszeit.