"QUANTON FLIGHT CONTRO rev. 1" , ein interessantes Teil?
- Themenstarter JUERGEN_
- Beginndatum
Als Brain für Taulabs ist wohl eher das gemeint, denke ich: http://brainfpv.com/
Also prinzipiell scheint Taulabs ja unter der GPLv3 zu stehen. Damit steht die Software ja unter recht strengen Verwertungsbedingungen. Da die Hardware in Zukunft aber geöffnet werden soll vom Brain gehe ich davon aus, dass das bei der Software auch der Fall sein wird.
Wie das beim Micro Brain aussieht weiß ich nicht. Hat das eine angepasste Taulabs Software oder nur eine eigene Firmware für das Board?
Sieht für mich so aus, als würde Taulabs mit dem µBrain nur durch einen Dritten aber nicht offiziell unterstützt werden.
Wie das beim Micro Brain aussieht weiß ich nicht. Hat das eine angepasste Taulabs Software oder nur eine eigene Firmware für das Board?
Sieht für mich so aus, als würde Taulabs mit dem µBrain nur durch einen Dritten aber nicht offiziell unterstützt werden.
Zuletzt bearbeitet:
Ich bin kein Rechtsverdreher, aber wenn ich die Softwarelizenz richtig verstehe steht es jedem frei diese zu modifizieren und auf eigener Hardware zu nutzen. Wenn ein kommerzielles Produkt daraus wird, ist das auch erlaubt. Die einzige Einschränkung ist die Offenlegung des Quellendes für das Produkt.
Beim BrainFPV hier: https://github.com/BrainFPV. Für das Pflegen der Software ist dann
der Hersteller verantwortlich. Soll die Hardware bei TauLabs direkt eingebunden werden, erfordert das die
zusätzliche Offenlegung der Hardware (Schematic, Gerber etc.). Ich denke, dass es nur eine Frage der Zeit ist,
bis Shred von BrainFPV den Schritt macht.
Für das µBrain habe ich übrigens noch keinen Quellcode gesehen.
Beim BrainFPV hier: https://github.com/BrainFPV. Für das Pflegen der Software ist dann
der Hersteller verantwortlich. Soll die Hardware bei TauLabs direkt eingebunden werden, erfordert das die
zusätzliche Offenlegung der Hardware (Schematic, Gerber etc.). Ich denke, dass es nur eine Frage der Zeit ist,
bis Shred von BrainFPV den Schritt macht.
Für das µBrain habe ich übrigens noch keinen Quellcode gesehen.
Das sehe ich auch so, bei den Router Herstellern z.B. ist das ja auch mittlerweise gang und gäbe den Source nach Modifizierung wieder zu Veröffentlichen - nachdem es Druck gab.
Der ist hier zu finden: https://github.com/scenkov/TauLabs und dürfte kein offizieller VR Code sein.
Der ist hier zu finden: https://github.com/scenkov/TauLabs und dürfte kein offizieller VR Code sein.
Hat schon mal jemand die Buzzer Pins vom Quanton genutzt?
Auf dem PDB was ich einsetzen werde ist ein Buzzer drauf, und wenn ich mir das Schematic vom Quanton anschaue ist die Beschaltung der Buzzer Ausgägne mehr der weniger gleich denen von der Naze32 (das PDB ist eigentlich dafür ausgelegt).
Daher sollte es prinzipiell gehen, denke ich.
Aber in Taulabs habe ich bisher nichts gefunden wie ich den Ausgang ansprechen kann.
So wie ich es im source code gesehen habe wird der Pin als GP(I)O initialisiert, aber sonst nicht weiter benutzt.
Mit PicoC würde ich ansonsten gerne eine Skript schreiben für Lipo Alarm über den Buzzer. Aber soweit ich sehe, kann man da nur die Timer Pins der normalen PWM Outputs ansprechen.
Oder gehen auch GPIO`s ?
In Taulabs ansich scheinen ja funktionen wie Set/Reset/Toggle drinne zu sein.
Auf dem PDB was ich einsetzen werde ist ein Buzzer drauf, und wenn ich mir das Schematic vom Quanton anschaue ist die Beschaltung der Buzzer Ausgägne mehr der weniger gleich denen von der Naze32 (das PDB ist eigentlich dafür ausgelegt).
Daher sollte es prinzipiell gehen, denke ich.
Aber in Taulabs habe ich bisher nichts gefunden wie ich den Ausgang ansprechen kann.
So wie ich es im source code gesehen habe wird der Pin als GP(I)O initialisiert, aber sonst nicht weiter benutzt.
Mit PicoC würde ich ansonsten gerne eine Skript schreiben für Lipo Alarm über den Buzzer. Aber soweit ich sehe, kann man da nur die Timer Pins der normalen PWM Outputs ansprechen.
Oder gehen auch GPIO`s ?
In Taulabs ansich scheinen ja funktionen wie Set/Reset/Toggle drinne zu sein.
Der buzzer pin funktioniert bei der Quanton leider nicht.
Der ist falsch beschalten (siehe Handbuch)
Buzzer würde an einem anderen pwm pin und picoC funktionieren.
Ich hab den buzzer über einen zwischengeschalteten Atiny laufen. Der Controller steuert meine Beleuchtung und den buzzer und wird von der Quanton mittels pwm mit info versorgt.
Der ist falsch beschalten (siehe Handbuch)
Buzzer würde an einem anderen pwm pin und picoC funktionieren.
Ich hab den buzzer über einen zwischengeschalteten Atiny laufen. Der Controller steuert meine Beleuchtung und den buzzer und wird von der Quanton mittels pwm mit info versorgt.
Außer der Initialisierung des Pins (der an den Buzzer geht) als GPIO Output (ab Zeile 1457 https://github.com/TauLabs/TauLabs/blob/next/flight/targets/quanton/fw/pios_board.c) habe ich bisher keine weiteren sourcen / Verwendung gesehen.
Daher meine Frage, ob nicht ich evtl. was übersehen habe (ich habe noch nicht so den 100% Einblick in Taulabs).
Aber wenn in Taulabs selber keine Verwendung ist, dachte ich PicoC wäre dann optimal geeignet, den Buzzer für einen Alarm etc. zu nutzen.
Würde er an einem PWM Output Pin hängen, wäre das wohl kein Problem.
Aber da ich in PicoC bisher keine Funktionfür einen Zugriff für GPIO Pins gefunden habe, geht das wohl leider auch nicht so einfach.
Und bisher bin ich auch noch nicht dazu gekommen, eine Entwicklungsumgebung für Taulabs aufzusetzen, um evtl. GPIO Funktionen für PicoC zu schreiben.
Die I2C Implementierung von ernieift würde ich als Beispiel nehmen, die sieht recht übersichtlich aus. Zusätzlich müßte man für eine generelle GPIO Funktion in der Library wohl noch nen Sicherheitscheck machen, dass man nicht irgendeinen Pin ansprechen kann, sondern nur für GPIO freigegebene.
Gibt es evtl. irgendwo ne aktuelle VM mit Linux, wo soweit schon alles drinne ist?
Unter Windows scheint es mit dem aktuellen next Probleme zu geben, und mit Linux kenn ich mich nicht wirklich gut aus.
Daher meine Frage, ob nicht ich evtl. was übersehen habe (ich habe noch nicht so den 100% Einblick in Taulabs).
Aber wenn in Taulabs selber keine Verwendung ist, dachte ich PicoC wäre dann optimal geeignet, den Buzzer für einen Alarm etc. zu nutzen.
Würde er an einem PWM Output Pin hängen, wäre das wohl kein Problem.
Aber da ich in PicoC bisher keine Funktionfür einen Zugriff für GPIO Pins gefunden habe, geht das wohl leider auch nicht so einfach.
Und bisher bin ich auch noch nicht dazu gekommen, eine Entwicklungsumgebung für Taulabs aufzusetzen, um evtl. GPIO Funktionen für PicoC zu schreiben.
Die I2C Implementierung von ernieift würde ich als Beispiel nehmen, die sieht recht übersichtlich aus. Zusätzlich müßte man für eine generelle GPIO Funktion in der Library wohl noch nen Sicherheitscheck machen, dass man nicht irgendeinen Pin ansprechen kann, sondern nur für GPIO freigegebene.
Gibt es evtl. irgendwo ne aktuelle VM mit Linux, wo soweit schon alles drinne ist?
Unter Windows scheint es mit dem aktuellen next Probleme zu geben, und mit Linux kenn ich mich nicht wirklich gut aus.
Ups, ich brauche Rat. Ich habe eben beim Flashen eines Updates geschlafen und bu_quanton.tlfw geschrieben (statt fw_quanton.tlfw). Mglw. ist noch zusätzlich was schiefgelaufen, jedenfalls mag der Quanton nicht mehr. Es leuchtet nur die grüne Power-LED und bei 'Rescue' meldet sich kein Bootloader. Ideen?
Moin,
Du benötigst einen StLink, am einfachsten in der Form eines Discovery oder Nucleo Boards.
Darauf StLink und Prozessor durch ziehen der Jumper trennen und die SWD Anschlüße ( + / - / SWDIO / SWCLK ) mit der SWD-Schnittstelle auf dem Quanton verbinden.
Per STM32 ST-Link Utility - auf der st.com Seite zu finden - den Bootloader laden und dann per Rescue die Firmware. Analog wie man ein Discovery-F3 in ein FlyingF3 verwandelt.
Du benötigst einen StLink, am einfachsten in der Form eines Discovery oder Nucleo Boards.
Darauf StLink und Prozessor durch ziehen der Jumper trennen und die SWD Anschlüße ( + / - / SWDIO / SWCLK ) mit der SWD-Schnittstelle auf dem Quanton verbinden.
Per STM32 ST-Link Utility - auf der st.com Seite zu finden - den Bootloader laden und dann per Rescue die Firmware. Analog wie man ein Discovery-F3 in ein FlyingF3 verwandelt.
