MCU speed vs. memory, was brauche ich genau?

caddyRangeOSD

hängen, moment lass laufen
#1
hallo,
ich beobachte in letzten Monaten immer mehr unterschiedliche CPUs die auf den diversen Stacks, AIO verbaut werden und möchte mich mal informieren, was ich als Endnutzer davon habe bzw. wie ich aus der Datenflut profitieren kann.

Ich habe schon die Seite von Oscar Liang —Aufbau und Funktion von Flugkontroller — angeschaut und bemerkt, dass die F1 und F3 heutzutage nicht mehr verwendet werden. Zudem habe ich festgestellt, die F4 und F7 haben sich weiter differenziert zum Beispiel gibt es die F460 (die jedoch mit F405 bestückt ist), oder den F405 (mit F405RGT6 bestückt) oder ganz was neues von Diatone die G Serie der CPUs zB G4aio (mit G473).

Vom Prinzip her habe ich verstanden, dass es um die Prozessorgeschwindigkeit und der Speicherkapazität meines FCs bzw. der IMU geht... die KHz Rate und MB storage. Wird dann beim Bau und der Herstellung von den neuesten Chips versucht neue Kanalgänge oder Leitungen zu lasern oder ätzen (Schicht pro Schicht) oder sind das die Designs die vom "Reisbrett" auch fertigungstechnisch validiiert und umgesetzt werden konnten? Warum ist klar (speed und memory) aber kann mir zum Beispiel jemand sagen für freestyle nimmste den, für cinematic den für race den usw. etc.
Der CPU ist es ja egal ob ich jetzt in 0,2 sek um 45° drehen möchte oder ich lieber 4sek floaty um 3° pitch erhöhe damit ich am nächsten spot super in den Einflug komme (Beispiel Feedforward). Je mehr Rechenwege bzw. feedbackloops im Prinzip immer die bessere Variante, damit das mit dem Setpoint passt. Die CPU arbeitet ja nur ab Stickbewegung bis kurz nach (zumindest hier im Beispiel blackbox), also auch viel damit zusammenhängt wie geflogen wird bzw. welcher Stil.

Also wer hat noch Durchblick zu MCU F,G oder H Empfehlung für Coptertyp?
Und wer weiß warum sich die Werte differenzieren, sind das herstellerseitig unüberwindbare Hindernisse?

Weil ich habe, glaube mich erinnern zu können, mitbekommen und gelesen gelesen die Leitungsbahnen können vom Medium "übersprungen werden" ich glaube für unsere immer kleiner werdenden Chipanwendung nehmen zB immer neuere Steuersignale breiten Raum ein, dass knapp gelegte Bahnen unweigerlich zu einem error führen. Weiß jemand hier mit sicherheit, dass in einer CPU immer mehrere Signale durchlaufen? Oder was ist die Grenze, zB die Schwingungsfreqenz ist ja niemals mit unserem Stickinput abdeckbar, das kann nur von einem Gyro geleistet werden...?!
 

KM|fpv

creator & mentor
Mitarbeiter
#2
Nur die Hälfte gelesen, aber wichtig für betaflight und inav ist nicht die MHz oder der RAM, vielmehr der Speicherplatz für die entsprechende Firmware!
Bisher war es quasi egal, ob man F411, F405 oder F7xx (usw) hat. Doch mit mehr Funktionen und besseren aber umfangreicheren Filtern, wird der Speicher auf F411 & F722 mit nur 512kB zu knapp.

Du hast evtl auch schon gesehen, dass jetzt viele AIO Boards und einige flight controller mit F722 geradezu verramscht werden!? Auch die Hersteller haben gelesen, dass der Speicher dieser (F411 & F722) nicht ausreicht um alle Funktionen zu nutzen.
 

caddyRangeOSD

hängen, moment lass laufen
#3
Nein, aber das erweitert meine Perspektive.
Die Software vom ganzen Copter ist zu groß für den FC oder der Teil der momentan verarbeitet werden muss? Ich verstehe nicht warum das ganze firmware Paket etwas mit den Einzelfunktionen zB FF oder Setpoint smoothie🥤zu tun hat, und nicht über "Zusatzoptionen" wie GPS, Baro, Led (das was halt mittels Uarts noch zusätzlich gemacht werden kann) belastet wird?

Verarbeitungsprozesse können ja partitioniert werden was in der Architektur vorab gelöst ist, und dann eben Werten nach wichtigkeit etc.

Stimmst du mir dann zu, dass ich je weniger Uarts ich verwende ich entsprechend nie zur Vollauslastung der CPU komme? Denn die Filter brauche ich fürs fliegen und controller tuning auf alle Fälle!
 

KM|fpv

creator & mentor
Mitarbeiter
#4
Ist wie jedes Betriebssystem:
Mehr Funktionen = mehr Speicherplatz auf der Festplatte
Deine mcu des flight controllers kann schon alles verarbeiten, es gibt keine Probleme mit der Auslastung wenn du Hardware uarts nutzt, das wird erst mit SOFTSERIAL anders.
Die Funktionen rund um GPS sind zB größer geworden, was mehr Platz braucht und die Verarbeitung braucht dann etwas mehr CPU time, aber noch im grünen Bereich. Und wenn zB mit GPS die Last größer wird, kannst du zB das GPS zu langsameren baudraten konfigurieren.
 

caddyRangeOSD

hängen, moment lass laufen
#5
zB habe ich gemäẞ BF eine CPU Auslastung von 25% ....jedoch bei herabgesetzter KHz des Gyros bin bei 1:2 odergar 1:4.

Ich kann also problemlos den Ramsch "raus mich kauf" nehmen, nur wenn ich die Firmware ausführlicher aufsetze, dann sollte ich zu den neuen CPUs greifen. Das macht mehr Sinn, denn ich habe zuvor meist neben der für mich guten/schlechten Erfahrung mit einem Hersteller auch auf den Preis geschaut und F7 oder F4 war für mich belanglos. Trotzdem habe ich momentan mehr F7 eingebaut als F4. Die F4 sind hauptsächlich in den nanowhoopsen.

Zumindest verstehe ich jetzt, dass ein mitziehen mit zB BF neuer software auch irgendwann eine bessere CPU benötigt. Danke mal hiersoweit.

Bei Oscar Liang — flight controller explained — schreibt er von firmware codes & complex calculations aber immer auf das was den Prozessor angeht (Stand 13.9.23). Ich werde mal schauen was bei den Kommentaren noch brauchbares steckt.

G4 ist das neueste, und auch eine andere software (Alpha). Mal schauen was das ist.
 

caddyRangeOSD

hängen, moment lass laufen
#7
Öhm das wurde auch überarbeitet!
Es wird nur noch die CPU Auslastung der User Parameter gezeigt, nicht das was noch läuft.
Ich persönlich fand die Entscheidung nicht so gut, da man jetzt nicht mehr die gesamte Auslastung sieht.
dann bleib ich erstmal bei den f722 für mein wenig freestylen und probiere mich mehr am filter setting um etwas mehr in die richtung zu kommen die ich mir so vorstelle. An einem guten Sbang setting mühe ich mich schon länger ab, also weiter mit den f7
 

QuadCrash

Erfahrener Benutzer
#8
Zu den FCs mit F411 oder F722 Prozessor:

Betaflight:
4.4 has a new Cloud Building System. This is design to extend the life of smaller flash sized MCUs (F411 and F722) based boards. You need to enable the various options in the build, before selecting "Load Firmware Online" within the configurator. It is super simple, but just be aware that unless you have selected the option for your firmware it will not be available once you flash the board. Don't stress, if you miss an option, just request a new build! :)
INAV:
INAV 7 is the last INAV official release available for F411 based flight controllers. The next milestone, INAV 8 will not be available for F411 boards.
F722 wird nach INAV 8 entfernt

ArduPilot:
F411/F722 wurden nicht unterstützt.
 
#11
dann bleib ich erstmal bei den f722 für mein wenig freestylen und probiere mich mehr am filter setting um etwas mehr in die richtung zu kommen die ich mir so vorstelle.
Ich fliege zum Teil noch flight controller mit F3, ist kein Problem. Man muss auch nicht immer das Neuste haben, so lange ein system gut funktioniert. Wenn dann ein neues FPVgerät ansteht kaufe ich was passendes und eher aktuelles. F411, F722 oder gar F3 würde ich da eher meiden.
Heute zb. mit dem Mobula7 Spaß gehabt und ich sehe grade nicht welche Vorteile ein F405 bei dem Teil haben sollte... der Matek F405-STD in meinem SourceOne erfüllt wunderbar seinen Zweck obwohl der ja schon älter ist... in mein neues Flugzeug soll ein alter Matek F405-crt, muss kein H7 sein... kommt halt immer auf die Anwendung an würde ich sagen.
 

caddyRangeOSD

hängen, moment lass laufen
#12
weil es hier auch um die software zu den verschiedenen Prozessoren der FC gegangen ist. Zum Beispiel bin ich bei BF Configurator 10.8 eingestiegen und alles was zuvor war kenne ich nicht. Aber zB der Artikel hier feedforward, setpoint und transition error=1 measurement=0 smooth vs. spiky von OL ist ja mit heutiger Software nicht mehr nachzubauen. Zudem gibt es jetzt auch mehr tabs im Menüpunkt PID und Filter und Antigravity etc. viel mehr zum einstellen.

Welches Baujahr haben den die F3, bzw. wann waren die am Markt aktuell?
 
Zuletzt bearbeitet:

caddyRangeOSD

hängen, moment lass laufen
#15
Dass du naze32 nicht erwähnt hast ist ja gemein!
Berühmte flight controller je mcu:
F1 - naze32 & CC3D
F3 - omnibus & spracingf3xxx
F4 - OMNIBUSF4xxx & mamba
F7 - aocoda & blitz ???
H7 - mamba & t-motor ???
haben all die oben genannten... 1 kern? steht die zahl für die Kerne?
 

caddyRangeOSD

hängen, moment lass laufen
#18
die signale werden sicher gesplittet in der mcu, die größe der firmware ist gleich.
 

caddyRangeOSD

hängen, moment lass laufen
#19
moin besinnliches...

ein Befehlssatz wird aus der firmware und dem steuersignal+der gyro selbst-awarness dem Prozessor zur Verarbeitung gegeben. w/o runtime error folgt das Nachregeln aller Motoren. Ohne alle Erweiturungsmöglichkeiten der UARTs ist das die Aufgabe eines FC der Tx/Rx Protokolle und Gyroinformationen verarbeitet.

Das ist extrem verdichtet und vereinfacht ausgedrückt für das was ich herausgefunden habe. Die Komplexität der MCU chips ist nur dann sinnvoll, wenn auch die firmware genug Ressourcen (mögliche Befehlssätze) generieren kann.


Hat jemand Erfahrung mit FCs die ihr Betriebssystem auf ner SD-Karte haben? Ist das zu Empfehlen und auszuprobieren??
 
#20
Hat jemand Erfahrung mit FCs die ihr Betriebssystem auf ner SD-Karte haben? Ist das zu Empfehlen und auszuprobieren??
Sehe ich in unserem Anwendungsbereich aktuell eigentlich keine Vorteile. Bei den ganzen Vibrationen, Crashes, hard Landings, flips und Rolls würde ich ein Betriebssystem auf einer externen SD Karte als Nachteil und eher als eine, wenn nicht zwei weiteren Fehlerquelle/n empfinden.
 
FPV1

Banggood

Oben Unten