Tau Labs Software unterstützt vielfältige Hardware

[ernieift]

Zu 1: Wenn Du SUMD benutzt, kommen bei der MX-12 alle 6 (bzw. 8) Kanäle über K6 an. Über K5 läuft die Telemetrie. Du kannst immer noch an K1..4 Servos anschliessen. Es sind aber dadurch nicht mehr Kanäle, sondern die gleichen.
Zu 2: Was willst Du machen? ein 800KHz-Signal an einem PWM-Pin ausgeben? Wenn ich mir die pdf zum WS2812 ansehe, wird die RGB-Info über das Tastverhältnis bitweise übertragen. 1,25µs pro Bit, 24Bit pro LED, bei 20LEDs. Damit komme ich auf 600µs. Bei Arduino wird es über SPI realisiert und ohne! abschalten von Interrupts. Ich sehe da nur 2 Wege: a) eigenen SPI Treiber in Taulabs benutzen, was aufwendig wird und höchst wahrscheinlich nicht in den Hauptcode mangels Nachfrage übernommen wird. b) einen ProMicro über einen USART anschliessen und die Info zum Ausgeben über eigenes Protokoll übertragen - wo wir wieder bei PicoC sind.
Interrupts abzuschalten hat auf dem STM32 wenig Sinn. Anders als Multiwii läuft Taulabs im Multitasking. Wenn Du die Interrupts ausschaltest, bringst Du das ganze System durcheinander. Die Prozessorarchitektur ist nicht wie auf den Kleinen über direkten Registerzugriff gelöst, sondern es ist eine Art Embedded-CPU über ein Bussystem mit der Peripherie mit allen Latenzen und Prioritäten verbunden. Du kannst also nicht einfach alle Interrupts abschalten und mit einem Timerregister eine Prozessorschleife laufen lassen und dabei einen GPIO-Pin klingeln lassen (noch dazu im genauem Timing). Das musst Du schon der Peripherie überlassen. Das wäre so, als ob Du auf einem PC mit xGHz und yGFLOPs einen Pin am Parallelport dazu bringen wolltest einen Rechteck Deiner Wahl auszugeben. Funktioniert schon wegen der Cache nicht.

PS: Für Arduino gibt es dafür eine FastSPI. Wenn ich mich nicht irre...

 

[ernieift]

@flensburger: Wenn Du ein neues Target anlegst, musst Du es natürlich auch mit irgendwas füllen. Am einfachsten wäre eine Kopie des DiscoveryF4 unter neuem Namen. Dazu musst Du aber der gcs noch klarmachen, dass es ein neues Target gibt. Es reicht nicht, einfach eine XML mit Werten zu füllen und den target-Ordner leer zu lassen. Ich glaube ich habe da mal so etwas von Dir gesehen.
Wenn es Dir nur um den Prozessor geht, dann nimm doch einfach das FF4 als Grundlage und schliesse die Sensoren entsprechend an. Taulabs ist das reale Board schnuppe. Oder hast Du etwas komplexeres im Sinn?

 

[Flensburger]

@flensburger: Wenn Du ein neues Target anlegst, musst Du es natürlich auch mit irgendwas füllen. Am einfachsten wäre eine Kopie des DiscoveryF4 unter neuem Namen. Dazu musst Du aber der gcs noch klarmachen, dass es ein neues Target gibt. Es reicht nicht, einfach eine XML mit Werten zu füllen und den target-Ordner leer zu lassen. Ich glaube ich habe da mal so etwas von Dir gesehen.
Wenn es Dir nur um den Prozessor geht, dann nimm doch einfach das FF4 als Grundlage und schliesse die Sensoren entsprechend an. Taulabs ist das reale Board schnuppe. Oder hast Du etwas komplexeres im Sinn?

Hallo.
So wie Du es beschreiben hast, habe ich es gemacht. Ich habe überall eine Kopie vom FF4 gemacht und umbenannt. In der GCS natürlich auch, dort ist es in STM-Plugin. Ich kann kompilieren ohne Probleme. Ich habe tagelang nach "flyingF4" gesucht, finde aber jetzt keinen Ort im Code, wo ich nicht das neue Target eingefügt habe. Langsam bekomme ich das Gefühl, da ist noch ein Bug in dem GCS-Code, daher startete ich den Debugger. Das neue Target wird richtig erkannt, das konnte ich beim debuggen sehen in einem Task. Irgendwo später greift er dann vermutlich mit einem falschen Index in eine Struktur, die ich noch nicht kenne.

 

[cGiesen]

Es gibt jetzt für TauLabs ein eigenes Forum:
http://forum-test.taulabs.org/

Gestern habe ich QT5 ausprobiert.
Klappt jetzt soweit. Ich frage mich nur warum man den Aufwand betreibt.
Ich kann nicht erkennen, wo QT5 besser sein soll.
Der Creator ist genauso besch.....n wie der in QT4
Das Einrichten unter Windows nachwievor unmöglich.
Kompilieren kann ich inzwischen mit MAKE, aus dem Creator aber wieder mal noch nicht....

 

[markus1234]

Dankefür die Antworten. D.h. trotz Teletrie kann ich 2 Schalter belegen.
Mit FreeRTOS kenne ich mich aus und natürlich kann man die Interrupts da abschalten, aber für eine sooo lange Zeit würde ich mich das nicht ohne weiteres trauen. In den Arduino libs habe ich mir schon einige Ideen geholt. Das mit der FastSPI habe ich noch nicht gesehen. Bei den libs zum Teensy3.1 (cortex m4) mischen die 3 DMA Kanäle ... Ist mir für LEDs zu oversized... Das ist schade aber die Telemetrie wiegt das mehr als auf
Jetzt muss ich nur zusehen wie ich mit dieser riesigen F3 Platine klar komme.

 

[markus1234]

Das wird eher nix - obwohl in dem kleinen auch schon ein 96MHz M4 steckt.

 

[cGiesen]

Mit FreeRTOS kenne ich mich aus

Es gibt im TauLabs Forum gerade eine Diskussion auf ChibiOS zu wechseln.

Aber wenn Du Dich auskennst, kannst Du mir in kurzen Worten sagen, wovon die Rede ist?

 

[markus1234]

ChibiOS kenne ich nicht. Hauptargumente scheinen aber der HAL und die Speicherverwaltung zu sein.
Der HardwareAbstractionLayer für taulabs scheint komplett (?) sebstgemacht zu sein und schluckt eine Menge Resourcen - das wird meiner Meinung nach bei anderen Systemen ähnlich sein.
FreeRTOS unterstützt nur dynamische Speicherverwaltung. Das stimmt einfach nicht - in industriellen Anwendungen würde ich mit dynamischer Speicherverwaltung kein Sicherheits-Audit bestehen. Da wird es aber oft eingesetzt.
Aber wie gesagt an taulabs taste ich mich gerade ran - soll aber hobby und nicht arbeit sein.

 

[cGiesen]

Sorry, ich habe 60% von dem verstanden, was Du geschrieben hast.
Den Rest erahne ich nur

Was ist HardwareAbstractionLayer, bzw. was macht es?

 

[Haldir]

Ich bin mir nicht so sicher ob der Wechsel die wirklich beste Idee ist. ChibiOS wird von genau einer Person entwickelt und hat damit die klassischen Probleme eines Kleinprojekts, wenn er keine Lust o.Ä. hat, wird das ganze sterben und man hat dann eine totes RTOS im Hintergrund.

Ich sehe außerdem den Speicher und Geschwindigkeitsvorteil nicht so eng, aufm Cortex-M4 ists praktisch egal und die M3 Boards können eh aktuell nicht alles was die 4er können. Früher oder später werden sich noch stärker ausseinander entwickeln.

 

[cGiesen]

Aber über was im Kern reden wir hier?
Ich verstehe nicht worum es geht

Ich komme im prinzip aus der 6502 Schule.
Habe mich dann mit Arduino beschäftigt und Baseflight einigermassen verstanden.

Hier sehe ich vor lauter Bäumen den Wald nicht.
Wo ist die Lichtung?

Edit:
Ist das sowas wie eine Library?

 

[Haldir]

Die HAL wird bei Taulabs dafür verwendet um die Feinheiten der unterschiedlichen Boards zu kapseln, also z.B. welche UART nummer auf welche Pins geht, wie z.B. die AD konverter initialisiert werden müssen usw. Simpel gesagt, die HAL stellt einen Satz von unabhängigen Methoden und Strukturen bereit und die eigentlichen Implementierungen pro Board setzen dass dann um auf ihre eigenen Boards. Das funktioniert für simple Sachen wie IO Pin Mappings gut, ist aber um einiges komplizierter wenns dann um HighLevel Funktionalität wie Floating Point oder ähnliches geht. Im allgemeinen ist ein HA-Layer einfacher zu nutzen, aber normalerweise etwas langsamer, einfach weil es ggf. Strukturen konvertieren muss.

 

[cGiesen]

Klasse, begriffen.
Früher haben wir dazu einfach Lockup Tabelle gesagt

Dann müsste es doch ein leichtes sein, die fehlende UART vom RevoMini einzubinden.
Wenn ich das richtig verstehe, muss ich jetzt nur sagen, wo die ist..

 

[ernieift]

@Carsten: Jaja, ich komme auch noch von der Oldschool-Z8-Z80-6502-Schiene und bin dann über 68000er und FPGAs zurück zu den Einchipern gekommen.

Über die Unzulänglichkeiten vom derzeitigen OS bin ich auch schon gestolpert. Es gibt z.B. zwar ein alloc() aber kein funktionierendes free(). Von Vorteil ist jedenfalls, dass TL von Anfang an portierbar gehalten ist wurde.
Ich verstehe nur nicht, was an den originalen ST-Libs so verkehrt sein soll. Es müsste nur mal jemand eine Aktualisierung machen. Die Dinger sind schon etwas älter. Welches RT-OS dazwischen liegt, ist dann wieder Geschmacksache.
vg ernieift

 

[cGiesen]

So wie ich das inzwischen verstanden habe, kann uns das egal sein, was die in dieser Sache machen.
Es wird 'nur' der Kernel getauscht, der (hoffentlich) ein wenig Ressourcen spart.

Was mich nur ein wenig ärgert, dass an tausend Stellen gerödelt wird, aber viele Dinge einfach in der Pipe bleiben.
Ich will da nur PicoC nennen.
Auch meine HoTT Erweiterungen in der GUI warten, OK, erst seit ein paar Tagen.
Aber dieses Light Telemetrie war ein Monat in der Pipe und sind kurz vor mir gemerget worden, so dass meines wieder geändert werden musste.

Egal, ist ja alles nur Hobby. Ermutigt nur nicht gerade.

Auch diese Umstellung auf QT5 ist jetzt schon fast 9 Monate ein Thema.

Aber auch egal.
Ich gehe jetzt erstmal fliegen

 

[ernieift]

Wenn Du mehr über HAL wissen willst, dann schau Dir mal das ISO-(oder OSI)-Schichten-Modell an. Ist im Prinzip immer das gleiche. Die Module sind die Applikationsschicht (oben) und HAL (unten) stellt den Hardwaretreiber dar. Daher, und das ist auch gut so, kann ein Modul nicht auf einen GPIO-Pin zugreifen.
Zusammengehalten wird das Ganze über ein Betriebssystem (bei uns FreeRTOS). Dadurch ist es im Prinzip möglich TL auch auf einem völlig anderen Prozessor laufen zu lassen. Zu musst halt nur dafür sorgen, dass Du alle Hardwaretreiber (I2C,Timer,USART usw.) hast. Normalerweise kommen die heutzutage vom Chiphersteller. Man kann natürlich auch eigene bauen.

 

[markus1234]

Und dynamische Speicherverwaltung hat nach meiner Meinung im Kopter nichts zu suchen. Ich will nicht das im Receiver oder gps code ein malloc fehl schlägt - und das wird es, alles nur Statistik. Ohne MMU und Speicherauslagerung ist das einfach zu riskant und ausserdem unnötig.
Beim HAL finde ich es wichtig wieviel "Bürokratie" erledigt werden muss um einen kleinen Treiber einzubinden.

 

[lilvinz]

ChibiOS kenne ich nicht. Hauptargumente scheinen aber der HAL und die Speicherverwaltung zu sein.
Der HardwareAbstractionLayer für taulabs scheint komplett (?) sebstgemacht zu sein und schluckt eine Menge Resourcen - das wird meiner Meinung nach bei anderen Systemen ähnlich sein.
FreeRTOS unterstützt nur dynamische Speicherverwaltung. Das stimmt einfach nicht - in industriellen Anwendungen würde ich mit dynamischer Speicherverwaltung kein Sicherheits-Audit bestehen. Da wird es aber oft eingesetzt.
Aber wie gesagt an taulabs taste ich mich gerade ran - soll aber hobby und nicht arbeit sein.

Wie kannst du FreeRTOS mit statisch alloziiertem Speicher benutzen? Dafür gibt es meines Wissens nach keine API calls.
FreeRTOS benötigt zwinged einen Heap. Ob der jetzt auch free() implementiert oder nicht, spielt erstmal keine Rolle.
ChibiOS kann beides (auch gemischt).

 

[lilvinz]

Ich bin mir nicht so sicher ob der Wechsel die wirklich beste Idee ist. ChibiOS wird von genau einer Person entwickelt und hat damit die klassischen Probleme eines Kleinprojekts, wenn er keine Lust o.Ä. hat, wird das ganze sterben und man hat dann eine totes RTOS im Hintergrund.

Ich sehe außerdem den Speicher und Geschwindigkeitsvorteil nicht so eng, aufm Cortex-M4 ists praktisch egal und die M3 Boards können eh aktuell nicht alles was die 4er können. Früher oder später werden sich noch stärker ausseinander entwickeln.

FreeRTOS wird von wieviel Personen entwickelt? Mir ist nur eine bekannt.
Da beide Projekte unter GPL stehen, sehe ich da dennoch kein Problem.
Nur zur Info: FreeRTOS Kernel austgetauscht gegen ChibiOS Kernel hat auf einem discoveryf3 die CPU Last halbiert.
Das discoveryf3 Board hat eine M4 CPU, diese ist jedoch "nur" mit 72 MHz getaktet. Da hilft dann auch die FPU irgendwann nicht mehr.

 

[lilvinz]

@Carsten: Jaja, ich komme auch noch von der Oldschool-Z8-Z80-6502-Schiene und bin dann über 68000er und FPGAs zurück zu den Einchipern gekommen.

Über die Unzulänglichkeiten vom derzeitigen OS bin ich auch schon gestolpert. Es gibt z.B. zwar ein alloc() aber kein funktionierendes free(). Von Vorteil ist jedenfalls, dass TL von Anfang an portierbar gehalten ist wurde.
Ich verstehe nur nicht, was an den originalen ST-Libs so verkehrt sein soll. Es müsste nur mal jemand eine Aktualisierung machen. Die Dinger sind schon etwas älter. Welches RT-OS dazwischen liegt, ist dann wieder Geschmacksache.
vg ernieift

free() kannst du im embedded Bereich ohne MMU getrost vergessen. Du verlierst die Deterministik wenn du das machst und bekommst dann früher oder später Probleme mit Heap Fragmentation. Es gibt andere Lösungsansätze z.B. Memorypools (bei ChibiOS dabei)
Die ST-Libs sind eine Pest. Guck dir nur an, was im Tau Labs tree an patches nötig ist nach jedem Update der ST libs.
ST weiss z.B. nicht, was "const" ist. Die USB libs von ST sind bekanntermaßen ziemlich fehlerbehaftet, dazu empfehle ich einen Blick in STs eigenes Forum.