STM32 -> A53

Das Problem mit Cortex-A ist, daß sie für Applikationen vorgesehen sind. 
Soweit mir bekannt, sind sie daher bare metal praktisch nicht nutzbar, 
wenn Du nicht extremen Aufwand treiben willst. Das ist zum Betrieb mit 
Linux gedacht. Das ist aber nicht echtzeitfähig, und eine variable 
Totzeit wäre für einen Regler fatal. Also müßte man schauen, wie man 
eine RT-Erweiterung von Linux auf dem Board zum Laufen bekommt.

Die A Serie sind keine Mikrocontroller. Da bist du eher in dem Umfeld 
von Linux oder Raspberry Pi. Ohne Betriebssystem kannst du damit nur 
sehr mühsam arbeiten. Und mit Betriebssystem wird das Timing 
kompliziert.

Hast du mal erwägt einen Raspberry Pi Zero mit einem kleinen STM32 zu 
kombinieren?

>PID loop mit 32kHz
Ein normaler PID Regler braucht auf dem STM32F4 etwa 1µs.

Ist das so viel mehr?

snapdragon flight nutzt einen Quadcore:
https://www.intrinsyc.com/vertical-development-platforms/qualcomm-snapdragon-flight/

Schlechten Code  mit mit Hardware kompensieren:
Nimm einen STM32H7.. mit 400 MHz
Oder einen Cortex R

Und ja, es gibt Profiler ;-)

Wie schnell fliegt denn diese Drohne, dass da eine zeitliche Auflösung 
mit 32 kHz nötig ist?

Und die zweite Frage wäre, wie schon einige Leute hier angesprochen 
haben, was ist denn mit Codeoptimierung? Ich habe grad vor ein paar 
Monaten mit den STM32 angefangen und musste erst mal feststellen, dass 
die Libraries enorm schlecht sind. Das ist von Leuten programmiert 
worden die Angst vor Microcontrollern haben und die darum mehrere 
unnütze Abstraktionsebenen eingebaut haben wo bestenfalls eine 
ausreichend wäre.

Guido Körber schrieb:
> Das ist von Leuten programmiert worden die Angst vor Microcontrollern
> haben und die darum mehrere unnütze Abstraktionsebenen eingebaut
> haben

Es gibt halt kein Problem, das nicht mit einer weiteren 
Abstraktionsschicht zu lösen wäre. Mit Ausnahme des Problems "zuviele 
Schichten" natürlich. ;-)

Ich habe mal einen fahrenden Modell-Roboter mit 100Hz Regelschleife 
gesteuert. Ich erwähne das, damit klar wird wie extrem die 32kHz sind.

und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren?
Wie ihr hier schon wieder drauf seid, glaubt ihr in der Szene gibts nur 
Stümper?
Schaut euch mal nur als Beispiel 
https://github.com/betaflight/betaflight an,
>10k commits, >260 contributors. Ich habe letztes Jahr zwei ESC mit SimonK 
Software gekauft und noch wollte noch zwei nachordern. Gibts nicht mehr, kalter 
Kaffee. SingleShot, ProShot, DShot, jeden Monat ein neues schnelleres Protokoll um 
den ESC schneller mit Steuerbefehlen zu versorgen. Mit 100 Hz wirst du da herzlich 
ausgelacht, die sind bei wenigen µs für die Ansteuerung.

Felix F. schrieb:
> ndere Leute schaffen das mit einem 16 MHz AVR (Wobei man das jetzt auch
> nicht direkt vergleichen kann).

und die machen nebenbei noch ein OSD, Datenlogging mit 8 kHz, AutoPID, 
die ganzen Berechnungen mit dem IMU? Nicht mal die STM32F1 möchte man 
dafür noch haben.

> Welcher Motor schafft innerhalb 1ms eine
> nennenswerte Drehzahländerung?

Dazu kommt die Massenträgheit des ganzen Gerätes. Ich möchte mal eine 
Drohne sehen, die 30 tausend mal (oder lass es mal nur ein zehntel davon 
sein) pro Sekunde ihre Flugrichtung ändern kann.

> und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren?
Gegenfrage: Muss deiner bei 100km/h in einer 30tel Millisekunde 
reagieren? Vermutlich denkst du das, aber warum?

> Mit 100 Hz wirst du da herzlich ausgelacht
Von Leuten die auf große Mhz Zahlen stehen und keine Ahnung haben.

Kleine Anekdote: Die Navigation einer bemannten Raumfähre wurde mit 
einem C64 gemacht, da hatte etwa 1Mhz Taktfrequenz!

Wenn man für solche Sachen hunderte Mhz bräuchte, dann frage ich mich, 
wie die Menschen denn in den 70er Jahren ihre digitalen Regelungen 
konstruiert haben.

Bei den 32 kHz gehe ich mal davon aus das die Summenrate gemeint ist, 
damit verteilt sich das beim Quad auf 8 kHz oder Octo auf 4 kHz. Ich bin 
zu langsam für solche Extrem Racer aber guckt euch die höher schneller 
weiter Videos auf YT an wie die richtigen Cracks fliegen.
Mich stört es nur wie hier alle anderen wieder für blöd gehalten werden.

Einen F4/F7 wird man nicht mal eben durch einen Quadcore A53 ersetzen, 
da bin ich auch skeptisch aber es gibt eben schon z.B. einen Snapdragon 
Controller. Das Bessere ist des Guten Feind in dem Markt und wenn morgen 
so ein Controller am Markt ist stürzen sich alle drauf. Ein halbwegs 
aktueller Controller mit F4 kostet 35-40€, das ist spottbillig wenn man 
bedenkt was da alles drauf ist auf einer Multilayer Platine mit 
teilweise dicken Layern und >90 Keramik Cs für die >150 A die da 
kurzzeitig fliessen. Das reicht schon für viel Spass aber die 
Entwicklung wird da von den richtigen Freaks getrieben.

>Kennt jemanden einen einfachen A53, bei welchem Betafligh
>die SW) auch relativ einfach portabel wäre?

download DS5 Community Edition, unterstützte CPUs auswählen, Bare Metal 
programmieren

https://developer.arm.com/products/software-development-tools/ds-5-development-studio/editions/community-edition

STM32 schrieb im Beitrag #5281067:
> Obs der F7 bringt ist auch fraglich.

Der ist deutlich schneller als die F4, u.A. dank superskalarer 
Architektur und Instruction RAM. Kann man also mal drüber nachdenken.

PS: 8 kHz Daten Logging ist ein Witz selbst für den F4 ;-)

Die Seite von Oscar Liang ist Top und bringt alles auf den Punkt:

https://oscarliang.com/best-looptime-flight-controller/
https://oscarliang.com/f1-f3-f4-flight-controller/

Danach gibt es durchaus F4 Controller die eine 32 kHz PID looptime 
schaffen. Aber wie gesagt, meine Reaktionszeit liegt deutlich über 125µs 
und ich selber  brauche es nicht :-)

> meine Reaktionszeit liegt deutlich über 125µs

Meine liegt laut Doktrin der Fahrschule bei 1s. Meine bescheidenen 
Erfolge in Videospielen scheinen das zu untermauern.

Felix F. schrieb:
> man hat dir sogar noch Tipps
> gegeben um deine absurden 32Khz zu erreichen.

nö, der TO wollte das und mit seinem Controller gehts nicht, not me.
Und es wird trotzdem Freaks geben die sagen das man mit 32 kHz viel 
besser fliegen kann...

> es wird trotzdem Freaks geben die sagen das man mit 32 kHz viel
> besser fliegen kann...

Ja, so wie Akkuschrauber mit mehr Volt grundsätzlich stärker sind und 
Staubsauger mit mehr Watt besser saugen und USB Sticks mit mehr GB öfter 
gefälscht sind ... upps

Der Code wird wohl unheimlich verfrimelt sein... aber soll mir nix 
angehen...

Wenn ich ein CortexA einsetzen würde wollen, würde ich wohl bei FreeRTOS 
vorbei gucken und mir einen mit passendem FreeRTOS-Port als Grundlage 
raussuchen. Mit viel Glück gibts vom Hersteller noch ne passende HAL, 
sonst wirds "lustig".

STM32 könnte einer unserer Kunden sein.
Dem war unser F4 auch viel zu langsam, weil "die PWM ja mit 20kHz laufen 
muss". Er hat wegen der hohen Frequenz auch Litzendraht für die Spule 
vorgeschlagen... Aber immerhin wurde ich so nach ein paar Konferenzen 
zum Bullshi-Bingo-Meister...

Zum Thread: was genau ist zu machen?
Ich vermute deshalb etwas Skepsis, weil es so klingt als ob MEMS 
(Beschleunigung, Gyro), die üblicherweise Grenzfrequenzen von wenigen 
kHz haben, mit 32kHz abgetastet werden. 4 Brushless-Motoren zu regeln 
wäre schon plausibler.

Je nach Anforderung: wie wäre es mit einem Mehrkerner? Evtl. auch ein 
asymmetrischer Aufbau?

Höher, schneller, weiter…

Die Diskussion kenne ich nur zu gut von Input-Devices (mein Business). 
Den Chip für die RTR-720 Mk I haben wir damals gemacht, eine Gaming 
Mouse, noch mechanisch. Da wurde mir auch erst erzählt man brauche für 
eine Gaming-Mouse auf jeden Fall Full Speed USB, weil dann 1000 Reports 
pro Sekunde durch gehen, die 125 bei Low Speed gingen garnicht.

Wir haben dann einfach 16 Bit pro Achse statt der üblichen 8 Bit 
genommen und die Routinen zum Auslesen der Drehgeber optimiert bis zum 
Anschlag. Auf diese Weise ging die Maus bei schnellen Bewegungen nicht 
an den Anschlag und im direkten Vergleich kam sie bei den Gamern besser 
weg als die Full Speed Teile, es wollte keiner glauben, dass die nur mit 
125 Hz Datenpaketrate läuft.

Vielleicht gibt es kein zu schnell, aber ist gibt ein schneller als 
sinnvoll. Das erreicht man in dem Moment wo die Regelschleife deutlich 
schneller als das ist was sie regeln soll. Falls ein Mensch in der 
Schleife drin ist, dann ist alles über 100 Hz reine Esoterik.

Wir haben grad einen neuen Beschleunigungs-/Drehratensensor fertig, der 
läuft bei maximal 6,6 kHz Abtastrate. Da mag man dann aber schon noch 
einen Tiefpass dahinter haben, denn das Rauschen wächst mit der 
Abtastfrequenz deutlich an.

egal obs noch wichtig ist:

M4 hat aus dem flash waitstates ... also aufpasse!!
ebenso der RAM hat diverse busse .. ( DTCM ... )
hier gibts auch performanceunterschiede

zum M7 jedenfalls :
bei solchen aktionen immer den ITCM RAM nutzen
Fuktionen im RAM benötiogen keine waitstates und werden durch den cache 
unterstützt.

Das erfordert jedoch etwas aufmerksamkeit beim programmieren.
also nur wirklich zeitkritische funktionen in den ITCM legen und schon 
rennt der µC
Ich konnte so einen SW JPEG decoder von 5-7fps auf über 25fps 
beschleunigen

Johannes S. schrieb:
> und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren?

Bei 1Hz sind das 27,78m/s = 27,78mm/ms = 2,7cm/ms.
Bei 32kHz sind das dann <1mm Bewegung.

Macht das Sinn??

rgds

Als Einsteiger mit noch halbfertigem Copter weiss ich das ich keine 32 
kHz Loopfrequenz brauche. In der Messtechnik ist Oversampling aber nicht 
ungewöhnlich und man kann die 'überflüssigen' Messwerte mit schlauen 
Filtern bearbeiten oder die Zukunft vorhersagen.
In den Copterforen wird das Feature jedenfalls auch kontrovers 
diskutiert und in vielen FC sind sowieso noch IMU mit max. 8 kHz drin. 
Es gibt mittlerweile sehr viele FC und da sind die 32 kHz natürlich ein 
zugkräftiges Schlagwort für das  Marketing. Die meisten die so Dinger 
kaufen sind sicher mehr Flieger als Techniker und da zählen die PS :-)

Markus H. schrieb:
> da bedeutet 0,868 mm/ Cycle - wenn du mit 1cm an nem Aobjekt

Bei 100km/h an einem Objekt mit 1cm Abstand vorbeifliegen?
Ich sehe ich bin noch lernfähig :)

rgds

Danke erstmal für die vielen Beiträge.

Stefan U. schrieb:
>> und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren?
> Gegenfrage: Muss deiner bei 100km/h in einer 30tel Millisekunde
> reagieren? Vermutlich denkst du das, aber warum?

Es geht hier nicht direkt um die menschliche Interaktion. Ein Quad ist 
ein hochdynamisches mechatronisches system welches unteranderem über den 
MEMS Gyro (>> schneller als Mensch) geregelt wird.

Anyway die Mechanik ist klar der Tiefpass. Das bestreben ist daher 
diesen Pol irgendwie zu Kompensieren und der PID mit möglichst grossem D 
Anteil zu betreiben. Wichtig ist eine möglichst geringe Latenz im 
Regelkreis. Hierfür ist einerseits ein schnellerere Flight controller 
aber auch insbesondere bessere ESCs von möten. Weiter ist das Protokoll 
zum ESC eine eigentlich unnötige verzögerung. Dshot1200 generiert 
mindestens 1.3e-5 s delay. Weiter sind die PWM frequenzen der ESC oft 
recht tief (40-50kHz) und die ESC selbst nicht über die nichtliniarität 
des Moments bezüglich der aktuellen Motorposition kompensiert. Deadtime 
hoch etc...
Grob gesagt sind die aktuell verfügbaren ESCs nicht besonders 
befriedigend und eigentlich eine grosse Baustelle.
Um das Delay der kommunikation zum ESC zu eliminieren, wäre es am 
besten, die ESC steuerung in den Flight controller zu integrieren und 
direkt die 6 Gatesignale pro ESC auszugeben.
Somit sind wir am ursprünglichen Problem, dass es der STM32F4 mit 240 
MHz nicht bringt...

>> Mit 100 Hz wirst du da herzlich ausgelacht
> Von Leuten die auf große Mhz Zahlen stehen und keine Ahnung haben.

Nun evtl. würde man den Quad auch mit einem 4004 irgendiwie zum Fliegen 
kriegen :-).

Arc N. schrieb:
> NXP den i.MX RT1050 Cortex-M7 mit bis zu 600 MHz
> oder Renesas die RZ/T1 Cortex-R4 mit bis zu 600 MHz

Danke

Christopher J. schrieb:
>> Gyro running a 32KHz sampling rate can be susceptible to noise,
>> a good example would be flight controllers like the Raceflight Revolt
>> which requires soft-mounting.

Noise der Gyros ist ein Problem. Glücklicherweise scheinen die MEMS 
entwickler einige Fortschritte zu machen :-). Mit 8 ICM20602 kann der 
SNR um gut 10dB zu erhöht werden. Vibrationen kriegt man mit dem 
Auswuchten der Propeller eigentlich relativ gut in den Griff.