Und noch einmal Begriffsverwirrung: Bit-Zahl Auflösung

[Prof. Dr. YoMan]

@Oliver:

Also das bisschen, was da in aktuellen Sendern passiert macht ein ATxmega oder ähnliches (die Größenklasse wird minimal eingesetzt) auf einer Arschbacke. Da ist genug Luft für float.

Ich entwickele auf ähnlich gelagerter Hardware Messsysteme, welche garantiert mehr Rechenleistung brauchen als das bisschen Mischerrechnerei.

 

[Steffen]

Sorry, aber für ein zeitkritisches Mess- und Steuersystem mit Latenzwünschen im msec Bereich halte ich Floats auch für unvernünftig.

Zudem bieten sie keinerlei Vorteile gegenüber eine Ganzzahlrechnung mit entsprechender überhöhung, was dann wiederum einem fixkommawert entspricht.

Gehen kann das, keine Frage, aber sinnvoll ist es nicht.

Gruss, Steffen

 

[Prof. Dr. YoMan]

Dann mache ich wohl andauernd auf der Arbeit was falsch.

Es hat entscheidende Vorteile NICHT darüber nachdenken zu müssen ob ein Zahlenraum überläuft oder wie ich den Fixkommakram normiere.

Bei 16MHz Prozessortakt (langsam) hast du in 1ms 16000 Prozessortakte Zeit. Selbst wenn float ca. 40-mal (Erfahrungswert) langsamer ist als 32bit-Integer kannst du noch 400 Float Operationen durchziehen. Das sind wenn ich es noch durch 16 Kanäle teile immer noch 25 pro Kanal. Und ja, ich weiß, da muss noch anderes nebenher laufen.

Aber das ist eine konservative Abschätzung und aktuelle uC im Billigsegment (<<5€) rennen eher mit 40MHz++ und sind intern 32-bittig.

Wer sich aktuell noch den Kopf über Fixpointrechnung mit Normierung zerbricht hat bei der Systemauswahl was falsch gemacht.

Für "Altsysteme" glaube ich sehr wohl das da noch Fix gerechnet wird, aber neu muss sich das eigentlich kein Entwickler antun.

 

[MarkusN]

Wer sich aktuell noch den Kopf über Fixpointrechnung mit Normierung zerbricht hat bei der Systemauswahl was falsch gemacht.

Bloss haben die System life cycles die eher in Jahrzehnten als in Jahren gerechnet werden. (Ist, wo Zuverlässigkeit verlangt ist, auch sinvoll.) Du kannst also keineswegs immer vom Modernsten ausgehen. Vielmehr hält man normalerweise mit Zähnen und Klauen am bewährten System fest, bis man von der Ersatzteilversorgung zum Umschwenken gezwungen wird.

 

[Prof. Dr. YoMan]

Nochmal, ich entwickele solche Systeme und glücklicherweise kann man auf leistungsfähige Systeme zurückgreifen.

Selbst ein System welches 1998 das erste mal an Kunden ging konnte mit einem Prozessor für 30DM in 100er Losgrößen fast alles was nötig war in float rechnen und das war nicht wenig.

Aber egal. Off topic.

 

[stopfohr]

Es hat entscheidende Vorteile NICHT darüber nachdenken zu müssen ob ein Zahlenraum überläuft oder wie ich den Fixkommakram normiere.

Wenn du so vom Fach bist, dann sach doch mal, was in aktuellen Sender für so für Prozessoren verwendet werden.

Und dann, was für entscheidende Vorteile es hat, einen (maximal) 10 bit breiten Integer-Wert aus einem ADC, der am Ende der Berechnung als 10-12 bit Integer ausgegeben wird, in double statt in 16-bit-Integern weiterzuverarbeiten. Wenns ganz dolle kommt, nimm halt 32 bit Integer.

Oliver

 

[Prof. Dr. YoMan]

Ich sagte nicht das ich weiß was in "aktuellen" Sendern alles verbaut ist.

Ich sagte das aktuelle uCs (in den letzten fünf Jahren) float locker auf einer Arschbacke mitmachen.

In ner MPX EVO (die ist von ca. 2000!) ist ein M430F-irgendwas drin. 8MHz und 2kB RAM. Da krankt es natürlich an RAM, da zählen deine Argumente. Ebenso wird es wahrscheinlich bei allem von Graupner aktuell am Markt sein, sowie allen Futaba Anlagen kleiner T8FG sein.

Bei allem ab T8FG sowie allem was neue auf den Markt kommt, wird (sollte) genug Bums an Board sein.

Wenn ich aber einfach in der billigen und stromsparenden und einfach Klasse herum schaue gibt es z.B.
Renesa M16C/M32C/... 32MHz+, 16kb+ RAM
ATxmega, 32MHz, 16kb+ RAM (Verbaut Jeti in vielen Dingen, oft auch noch die kleineren ATmega)
STM32F, 48MHz+, 32kb+ RAM
...

Niemand will double (64 bit), float (32bit) reicht ja wohl locker. Teilweise haben die Kisten nen INT-Hardwaremultiplier, der beschleunigt natürlich auch das komplexere float-Gerechne.

Die entscheidenden Vorteile sind, das man in der Entwicklung weder über mögliche Überläufe nachdenken muss, noch eine sinnvolle Normierung vornehmen muss, damit man nicht künstlich Auflösung verschenkt. Softwareentwicklung kostet auch Geld. Über alles was ich nicht nachdenken muss bin ich froh.

Es gibt keinen Grund es nicht zu tun, wenn die Resourcen ausreichen, was bei neuen Designs definitiv der Fall sein wird.

Ich widerspreche dir nicht, das es bis jetzt der Fall gewesen sein kann.

Langts? Ich denke. Bringt keinem was.

 

[haschenk]

Hallo,

immer nur in Auflösung zu denken ist das Eine. Genauso wichtig -wenn nicht noch wichtiger- ist die Reproduzierbarkeit einer Servostellung, und hierbei natürlich vor allem der Neutralstellung.

Die Signalverarbeitungs-Kette beginnt bekanntlich bei den Steuerknüppeln.
Wer die Möglichkeit dazu hat (genaue Messung von Impulslängen oder Digitalwerten), sollte sich mal ansehen, wie genau (besser wie ungenau !) hier die Neutrallage reproduzierbar ist. Wenn dabei dann eine Reproduzierbarkeit von 1µs (entsprechend rd. 10 Bit Auflösung) rauskommt, hat man es schon mit einem ausgesuchten Gerät der Spitzenklasse zu tun. Bei den meisten Sendern ist die Reproduzierbarkeit schlechter, von den 10 Bit bleiben dann oft nur noch 9 oder gar 8 - das ist die Realität.

Ursache sind winzigste Verformungen der (üblicherweise) Kunstoffteile der Knüppelaggregate, Reibungseinflüsse, winzige Verformungen innerhalb der Potis usw. Das kommt man einfach an die Grenze des mit bezahlbarem Aufwand Erreichbaren.

Also auch aus dieser Sicht nochmal: 10 Bit (1024 Schritte) sind in etwa das bestmöglich praktisch Machbare. Alles, was darüber hinausgeht, ist Dummenfang der Marketing-Strategen.


Gruß,
Helmut

 

[onki]

Hallo Helmut

Das wollte ich ja mit der Aussage, das die Ein- bzw. Ausgabeeinheiten die Sache begrenzen, hervorheben.

Gruß
Onki

 

[The Hun]

Du benutzt sicherlich Mikroservos. Die haben oft eine ganz bescheidene Auflösung. Man kann ja mit einfachen Mitteln selbst durchzählen, wie viel. Siehe Rudi.

Oft wird auch einfach nur Auflösung verschenkt, wenn nämlich der Endausschlag, sagen wir, auf 40% reduziert wird. Gerade bei Flächenservos wird ja gern das äußere Loch im Hebel genommen, am Querruder aber das an einem winzigen Ruderhorn das zur Drehachse am nächsten liegende. So kann man dann mit billigen Servo quasi runter auf 30 oder 40 Schritte kommen, obwohl die Anlagen, wie eine mc-20, 512 kann.

 

[onki]

Oft wird auch einfach nur Auflösung verschenkt, wenn nämlich der Endausschlag, sagen wir, auf 40% reduziert wird. Gerade bei Flächenservos wird ja gern das äußere Loch im Hebel genommen, am Querruder aber das an einem winzigen Ruderhorn das zur Drehachse am nächsten liegende. So kann man dann mit billigen Servo quasi runter auf 30 oder 40 Schritte kommen, obwohl die Anlagen, wie eine mc-20, 512 kann.

Hi

Na ja, mit den Hebelgesetzen sollte man, wenn man sich mit Ruderanlenkungen beschäftigt, schon vertraut sein.
Unsere Kids haben das mitunter besser drauf als so mancher alte Hase. Trotz Pisa-Studie

Gruß

Onki

 

[rkopka]

Wenn ich aber einfach in der billigen und stromsparenden und einfach Klasse herum schaue gibt es z.B.
Renesa M16C/M32C/... 32MHz+, 16kb+ RAM
ATxmega, 32MHz, 16kb+ RAM (Verbaut Jeti in vielen Dingen, oft auch noch die kleineren ATmega)
STM32F, 48MHz+, 32kb+ RAM
...

Niemand will double (64 bit), float (32bit) reicht ja wohl locker. Teilweise haben die Kisten nen INT-Hardwaremultiplier, der beschleunigt natürlich auch das komplexere float-Gerechne.

Die entscheidenden Vorteile sind, das man in der Entwicklung weder über mögliche Überläufe nachdenken muss, noch eine sinnvolle Normierung vornehmen muss, damit man nicht künstlich Auflösung verschenkt. Softwareentwicklung kostet auch Geld. Über alles was ich nicht nachdenken muss bin ich froh.

Das sehe ich anders.

FLOAT ist etwas, das man im Embedded Bereich tunlichst vermeidet. So schnell sind die obigen Prozessoren auch nicht und ohne richtige HW Unterstützung, die es in dem Bereich normalerweise nicht gibt, kostet das ne Menge Zeit und vor allem Speicherplatz. Wir sind hier bei harter Echtzeit, d.h. wenn da mehrere Mischer sind, muß ich spätestens in 20/10ms mit allen Berechnungen fertig sein.

Da wird viel eher mit Integer und Fixkomma gerechnet. Bei Floats und Umwandlungen bekomme ich immer leichten Jitter. Floats zu nehmen, weil ich mir keine Gedanken machen will über Wertebereiche, klingt mehr nach Windows Programmierung, wo man Resourcen en masse hat und auch entsprechend verschwendet. Und irgendwann komme ich ja wieder auf begrenzte Werte bei den Servosignalen zurück.

RK

 

[stopfohr]

Floats zu nehmen, weil ich mir keine Gedanken machen will über Wertebereiche, klingt mehr nach Windows Programmierung,

So ist es. Dazu kommt, daß man sich gerade mit 32-bit floats ganz böse auf die Schnauze legen kann. Denn ein 32-bit float hat nunmal die selbe Anzahl Werte wie ein 32-bit Int, die sind nur anders im Zahlenraum verteilt. Über die Effekte, die das nach sich zieht, muß man ganz genauso nachdenken, wie über Skalierungen und Überläfe bei der Integerberechnung.

Oliver

 

[Prof. Dr. YoMan]

Na dann sind ja alle Meinungen ausgetauscht.

 

[The Hun]

Hi

Na ja, mit den Hebelgesetzen sollte man, wenn man sich mit Ruderanlenkungen beschäftigt, schon vertraut sein.
Unsere Kids haben das mitunter besser drauf als so mancher alte Hase. Trotz Pisa-Studie

Gruß

Onki

Im geschilderten Fall muss meist der Endausschlag am Sender stark reduziert werden, womit dann auch die Auflösung leidet. Ausprobieren!

 

[Hägar]

Na dann sind ja alle Meinungen ausgetauscht.

Äh, ja, das sehe ich eigentlich auch so. Zumal dieser Teil der Diskussion zunehmend an der eigentlichen Fragestellung vorbei geht.

Um wenigstens ein bißchen zum Thema zurückzukehren: Hab gerade in der Mittagspause einen Conrad-Servotester-Bausatz und allerhand anderen Kleinkram besorgt. Will damit in den nächsten Tagen ein Testsetup aufbauen nach dem Fiala-Vorbild.

Geplante Vorgehensweise:
1. Schritt: Mit dem Servotester die Servoauflösung eingrenzen.
2. Schritt: Das ganze mit MPX3030 + Empfänger widerholen. Ohne Mischer. Schauen, welche Auflösung am Servo erzielbar ist.
3. Schritt: Wie 2., jedoch mit verschiedenen Mischer-Konfigurationen zur Prüfung, ob der Mischer fühlbare Einflüsse auf die tatsächlich am Servo feststellbare Auflösung hat.

Sobald ich da Ergebnisse vorliegen habe, werde ich sie hier einstellen.

Gruß,
Stefan.

 

[Prof. Dr. YoMan]

Wenn du meinst.

Ich weiß was ich und andere hier in unseren Messsystemen für Software bauen und das trotz harter Echtzeit und knappen Zeiten sehr viel float darin vorkommt. Scheinbar machen wir was falsch.

Wenn jemand anderer Ansicht ist, ok. Ich hab doch abgebrochen.

 

[stopfohr]

Ich weiß was ich und andere hier in unseren Messsystemen für Software bauen

Das ist ja auch gut so, ist aber völlig OT. Denn die Frage ist nicht, was du in "deine" Messysteme baust, sondern was die Senderhersteller in ihren Sendern verbauen. Das hat irgendwie nichts miteinander zu tun, oder?

Also schraub deine Funke auf, und schau nach. Dann haben wir wenigstens Fakten zu diesem Thema.

Oliver

 

[Prof. Dr. YoMan]

Ich schrieb oben schon, bei welchen Serien wohl noch lahme Enten verbaut sind.

In Zukunft und für manche Sender schon jetzt, sollte das kein Thema mehr sein.

Aber nun wieder zur eigentlichen Fragestellung.

 

[Steffen]

.................

Ich weiß was ich und andere hier in unseren Messsystemen für Software bauen und das trotz harter Echtzeit und knappen Zeiten sehr viel float darin vorkommt. Scheinbar machen wir was falsch.

Hat keiner behauptet, aber Deine Aussage macht es sich dennoch erheblich zu einfach.

Wenn Du in dem Fach arbeitest, weisst Du das auch selbst...
oder Du hast nicht unbedingt mit Sicherheitskritischem zu tun, da sind die Anforderungen manchmal anders. Bis mindestens vor sehr kurzer Zeit waren die Motorsteuerungen eines bekannten deutschen Motorsteuergeräteherstellers jedenfalls noch fixed. Vermutlich versteht der sein Geschäft nicht

Gruss, Steffen