Hallo, ich habe verschiedene Anforderungen, was mein Controllersystem können muss und möchte dazu den passenden Microcontroller finden. Welchen Controller kann ich hier verwenden? - Taktfrequenz min. 40MHz - max. 200MHz - 8 GPIO, 100kHz sollen möglich sein - I2C (hi-speed) Slave möglich - FPU (mul/div) Gibts im Netz so eine Art Konfigurator den man einstellen kannwas man haben will der anzeigt welche Typen passen würden? Wisst ihr einen Controller der das alles kann? Danke, Alex P.S.: Er soll natürlich dann auch nicht zu viel können (Graphik, Ethernet usw. ist preislich nicht erwünscht)
> P.S.: Er soll natürlich dann auch nicht zu viel können (Graphik, > Ethernet usw. ist preislich nicht erwünscht) Und wozu dann 40MHz?
Google??? Datenblätter wälzen??? Oder bist du zu Faul??? Dann lass dein Projekt am besten gleich sein.
Im Programm muss ich ziemlich viele Berechnungen innerhalb kürzerster Zeit machen und die Ausgänge danach setzen. Bei der Aussage "er soll natürlich nicht zu viel könenn" habe ich die peripheren Schnittstellen gemeint.
Hallo, ich habe mit DSPs noch nie was gemacht und weiss auch ehrlich gesagt nicht zu was die in der Lage sind. Ich habe auch schon an FPGAs gedacht, aber ich kann VHDL nicht und das soll ziemlich umfangreich sein. Auf was sollte man beim DSP achten, um den richtigen zu bekommen und gibt es gute Gratistools zum Programmieren? Danke für diesen ersten ergebnisorientierten Post. Alex
Die heutige Auswahl an Prozessoren und Controller ist riesig, ich würde noch weitere Faktoren berüksichtigen. 8, 16 oder 32 Bit Prozessor? Wieviel RAM und ROM schätzt Du zu benötigen? Mit internem oder externem ROM/RAM? Preis für den Controller SW-Entwicklungsumgebung (Kentnisse? Preislage? Vorhandenes?) Vermutlich wären die ARMs etwas für Dich, aber ich denke nicht, dass diese eine FPU haben. http://www.mikrocontroller.net/articles/ARM Wenn Due wirklich eine FPU wegen der Rechenlestung brauchst, solltest Du auch einen Blick auf DSP's werfen. MfG Peter
Controller mit integrierter FPU?! Oftmals lassen sich FP-Berechnungen durch sinnvolle Betrachtung der zu erwartenden Werte auf Fixkomma-Berechnungen umstellen, und die wiederum sind auch mit integer-Arithmetik in den Griff zu bekommen.
Alexander Födinger wrote: > Im Programm muss ich ziemlich viele Berechnungen innerhalb kürzerster > Zeit machen und die Ausgänge danach setzen. > Bei der Aussage "er soll natürlich nicht zu viel könenn" habe ich die > peripheren Schnittstellen gemeint. In welcher Sprache willst Du den Programmieren? Assembler ? C ? Mußt Du Analogwerte auswerten? Kennst Du Dich überhaupt in Richtung Controller Technik und Programmierung aus? Wenn Du Assembler nimmst, reicht ein schneller 8051, bei C nimm lieber ne Pentium DUO Core, mit DSP Einsteckkarte :-)
In meinem Fall ist der Wertebereich zu hoch sodass eine Aufspreizung der Werte auf 32 bit zu kompliziert werden würde. Ok, fangen wir mal so an: Ziel meines Projektes ist es, eine Bahnsteuerung für 3 Achsen mit Schrittmotoren zu bauen. Dabei muss ich jeden Schrittmotor mit 100kHz takten können. Dazwischewn muss ich im worst case Ellipsen fahren können. Das heißt Berechnung von Winkelfunktionen, Quadratwureln und ein paar Multiplikationien und Additionen innerhalb der Taktzeit bei eben diesen 100kHz-Takten. Da die Berechnungen für mindestens 3 Achsen auf meinen aktuellen Controllern (Coldfire MCF5206e 40MHz und MCF5270 86MHz) zu langsam sind will ich die Achsen auslagern. Jede Achse soll also ihren eigenen Controller haben der evtl. sogar schneller ist als ein Prozessor der jetztigen Hardware. Alex
RAM: Ca. 8MB ROM: Ca. 2MB int. RAM am besten ca. mindestens 8k für Stack. Das Programm ist bis jetzt in C geschrieben, das will ich wenn geht auch nicht ändern da ich da schon eine Zeit lang gesessen bin. SW-Entwicklung bis jetzt Codewarrior, AVRC, AvrAsm, Linux. Ich wills aber wegen Performance unbedingt ohne Betriebssystem bauen!
8K für Stack ? Dann brauchst Dich nicht wundern, daß Coldfire nicht ausreicht. Das sind doch nur einfache Geometrische Berechnungen. Wechsle die Programmiersprache und Du wirst erstaunliches feststellen.
Also ich habe beim 5206e die gesamten 8k für den Stack verwendet. Wie viel ich wirklich brauche weiss ich nicht, da ich den Stackverbrauch ohne os nicht so einfach bestimmen kann. Wahrscheinlich brauche ich nicht annähernd so viel!
@Dirk Hofmann >Dann brauchst Dich nicht wundern, daß Coldfire nicht ausreicht. >Das sind doch nur einfache Geometrische Berechnungen. >Wechsle die Programmiersprache und Du wirst erstaunliches feststellen. Auf was sollte er denn wechseln? Vielleicht ASM. Na dan mal viel Spass bei dem ganze Floating Point Gerechne. 10 us ist schon heftig, da hat ein 100 MHz Prozessor gerade mal 1000 Takte. Da sollte man erstmal überlegen ob a) Festkomma mit 32 bzw 64 nicht nicht schneller ist b) ob es Optimierungspotential durch Tabellen anstatt Winkelfunktionen gibt c) ob generell ein guter Algorithmus vorliegt MfG Falk
Gute Idee, hab ich schon gemacht: 64 Bit ist beim MFC5206e genau so schnell wie Floating Point (da ja beides umgerechnet werden muss). Beim 5270 ist sowiso fp schneller (wegen FPU). Die Winkelfunktionen habe ich schon in Tabellen hinterlegt - da lässt sich einiges herausholen, das stimmt. Gewisse Wurzelwerte habe ich auch schon in Tabellen gelegt und meine eigene Wurzelberechnung programmiert. Da fängt man an zu schwitzen beim Wertebereich von float. Durch die Tabellen habe ich auch den großen RAM-Bedarf. Ein Teil davon wird bei der Initialisierung berechnet, ein Tei davon nach der Parametrisierung und ein Tei ist als Konstante hinterlegt. Trotzdem - nach aller Performanceverbesserung stehe ich vor dem großen Problem dass ich mit meinen Controllern nicht auskomme.
@Alexander Födinger >64 Bit ist beim MFC5206e genau so schnell wie Floating Point (da ja >beides umgerechnet werden muss). Was muss bei 64 Bit Festkomma umgerechnet werden? MfG Falk
Ein FPGA würde sich dann auf jeden Fall eignen, wenn du noch weitere Logikbausteine damit ersetzen kannst. Mit ein bisschen Werte berechnen bei 100 kHz langweilt sich die Kiste. Das hängt natürlich ganz von dem Projekt ab. Bei einem kommerziellen Produkt wäre wohl Preis/Leistung das wichtigste, wenns ein (wohl sehr anspruchsvolles) Bastlerprojekt ist kannst du den "Lernfaktor" für FPGA zählen lassen. Und ein FPGA lässt sich universeller einsetzen als ein DSP.
Ja, ich glaube mittlerweile auch dass ein FPGA die vernünftigste Lösung wäre. Und dass ihm nicht so fad wird könnte ich die Bahnsteuerung ja auf 5 Achsen erweitern...
1 | Danke für die konstruktiven Vorschläge! |
P.S.: Was muss bei 64 Bit Festkomma umgerechnet werden? beantworte ich hier sicher nicht. @see math.c
> Auf was sollte er denn wechseln? Vielleicht ASM. Na dan mal viel Spass > bei dem ganze Floating Point Gerechne. Hast Du dich schon mal mit Assembler beschäftigt ??? Jedes C Programm besteht im Grunde genommen aus Assembler Befehlen. Floating Point spielt im Binären Raum von ASM sowieso keine Rolle. Wie man die Werte nachher behandelt ist eigene Sache. Ich habe schon mehrfach C-Programme disassembliert. Wenns Dumm läuft sinkt die Effizienz so ab, daß man gleich einen Controller mit nem 10-30tel der Taktrate verwenden kann. Außerdem ein reproduzierbares Timingverhalten herzustellen, naja, oder bezweifelt das jemand. Man kann auch mit Kanonen nach Spatzen schiessen.
Ein bisschen Achsen drehen sollte noch keine FPU bedingen. Der Werteberich ist nicht vorhanden. Allenfalls kann man sich mit Quaternionen behelfen. Auch wenn die Schrittmotoren mit 100kHz getaktet sind, kann ich mit kein System vorstellen, das physikalisch derart schnell waere, dass die neuen Werte mit 100kHz berechnet werden muessten. Das wuerde reichen um ein mechanisches System mit einer Grenzfrequenz (Tiefpass) von 10kHz zu kontrollieren. Da wird massiv Rechenpower verschleudert. Z
Mir ist schon klar dass ich meine 2 MB Source-Code auf Assembler übersetzen kann. Aber ist dieser Rieseige Brocken Software dann noch gut lesbar? Ein paar Funktionen habe ich eh schon in asm geschrieben, andere habe ich mit dem compiler und optimierer auf höchster Strufe disassemblieren lassen und festgestellt dass nicht recht viel Unterschied besteht - im Gegenteil, ich denke bei der Vielfalt an möglichen Assemblerbefehlen beim 68k ist der integrierte Optimierer sicher besser als ein durchschnittlicher bis guter Programmierer. Da muss man sich schon für 400 asm-Befehle ein paar Stundn hinsetzen um die beste Performance heraus zu holen. Der Optimierer schaffts in einer 10tel Sekunde.
Auch ich kann nicht nachvollziehen, wieso in welchem mechanisches System 100.000 mal pro Sekunde ein Richtungsupdate notwendig sein sollte. Bei einer angenommenen Genauigkeit von 1mm pro Update würde das einer Bewegungsgeschwindigkeit von 100 m/s entsprechen, d.h. 1/3 Schallgeschwindigkeit. Allein aufgrund der auftretenden Trägheitskräfte dürfte jedes mechanische System damit überfordert sein, es sei dem du programmierst eine Steuerung für einen Transrapid, doch der fährt nicht auf komplexen Ellipsenbahnen. Bei Roboterarmen wird im Allgemeinen eine mehrstufige Positionierung verwendet: Schnelle, möglichst geradlinige Bewegung bis nahe an die Endposition und anschliessend langsam, aber präzise an die Endposition. In beiden Fällen dürften ca. 1000 Update pro Sekunde ausreichen. Die eigentliche Ansteuerung der Schrittmotoren würde ich einer intelligenten Peripherie (Timer mit PWM) oder einem externen IC überlassen. Gruss Mike
@Dirk Hofmann >Hast Du dich schon mal mit Assembler beschäftigt ??? Jedes C Programm Durchaus. >besteht im Grunde genommen aus Assembler Befehlen. Was du nicht sagst! Und Apfelmus ist Mus aus Äpfeln. >Ich habe schon mehrfach C-Programme disassembliert. >Wenns Dumm läuft sinkt die Effizienz so ab, daß man gleich einen >Controller >mit nem 10-30tel der Taktrate verwenden kann. Und ASM kann mit einem Befehl sämtliche Operationen ausführen, wo C 10..30 braucht?!? Aha. >Außerdem ein reproduzierbares Timingverhalten herzustellen, naja, oder >bezweifelt das jemand. C ist auch ganz gut reproiduzierbar, wenn gleich nicht auf den Takt genau wie Assembler. >Man kann auch mit Kanonen nach Spatzen schiessen. Ja eben, und komplexere Berechnungen "per Hand" in Assembler zu programmieren ist so eine Kanone. MfG Falk
@ Zacc warum weiss du denn dass der Wertebereich nicht vorhanden ist? Kennst du mein Projekt im Detail?
Dirk Hofmann wrote: > Ich habe schon mehrfach C-Programme disassembliert. > Wenns Dumm läuft sinkt die Effizienz so ab, daß man gleich einen > Controller > mit nem 10-30tel der Taktrate verwenden kann. Also 1/30 ist total übertrieben, max 1/2 ist real. Wenn man C programmieren kann, d.h. nur die nötigen Datentypen verwendet, lokale Variablen (d.h. in Registern) bevorzugt und nicht alle Schleifenzähler als double float definiert, dann ist C vielleicht 20% langsamer, im äußersten Fall auch mal 50% (also max 1/2). Peter
Naja, mal ein Einwurf aus der Praxis: Delta Tau benutzt in der PMAC-Serie (Motioncontroller bis 8 Achsen) einen DSP aus der 56K-Serie mit anfangs 40MHz, inzwischen 80..240MHz. 256k RAM/ROM, eigener ASIC für das Achs-Interface. Die Teile sind zwar Sch.. zu programmieren (eigene Sprache), aber schon potent. Ahoi, Martin
Alexander Födinger wrote: > Mir ist schon klar dass ich meine 2 MB Source-Code auf Assembler > übersetzen kann. > Aber ist dieser Rieseige Brocken Software dann noch gut lesbar? > > Ein paar Funktionen habe ich eh schon in asm geschrieben, andere habe > ich mit dem compiler und optimierer auf höchster Strufe disassemblieren > lassen und festgestellt dass nicht recht viel Unterschied besteht - im > Gegenteil, ich denke bei der Vielfalt an möglichen Assemblerbefehlen > beim 68k ist der integrierte Optimierer sicher besser als ein > durchschnittlicher bis guter Programmierer. > Da muss man sich schon für 400 asm-Befehle ein paar Stundn hinsetzen um > die beste Performance heraus zu holen. Der Optimierer schaffts in einer > 10tel Sekunde. Hallo Alexander, wir können ja mal ein einfaches Example statuieren (und übrigens, die meisten Programmierer in C verstehen von Assembler soviel wie eine Kuh vom Eierlegen). Einfache Aufgabe: Nimm einen 8 Bit Port. An dem hängen 8 Tasten. Erzeuge 2 Byte: Das eine Byte zeigt welche Tasten gerade gedrückt wurden (aber nur in dem Moment, nicht permanent) und in dem anderen welche losgelassen wurden. Wer Lust hat kann mitmachen Lösung in Assembler und in C und disassemblierten C. Zeig mir ein Assemblerprogramm für so eine Anwendung, welches 2MB braucht. Wieso hat man früher in 32KB ROM ein komplettes Betriebssystem gebracht? Man sollte nur von etwas reden, was man versteht. Ich programmiere seit 20 Jahren in Assembler und weiß wovon ich rede.
Hallo Peter, den Beweis würde ich gern antreten. Es ist garnicht möglich, in einer Programmiersprache, die jetzt bald 40 Jahre alt ist und vom Syntax auf eine ganz andere Anwendung ausgelegt war was gescheites zu programmieren. Warum werden heute Prozessoren mit 3-4 GHz gebaut, Duo, Quadcore usw. und die effektive Leistung nimmt kaum zu. Und wenn dann macht es zum großen Teil die Hardware, DMA, Grafikchips, Chipsets. Als Beispiel: Ich mußte für einen Kunden ein Handbediengerät für Maschinen nachbauen, weil die es abgekündigt haben. Darin sitzt ein 16/32 Biter von Hitachi mit 128KB Flash. Die habe sogar noch Timingprobleme mit der Verarbeitung der Daten über die RS232 bei NUR!!! 9600 Baud. Das neue Gerät hat einen AT89S52 für 1€ und erfüllt die gleiche Funktionalität??? Und ??? Noch Fragen???
also mal aus der Praxis. Ich programmiere seit 10 Jahren in Assembler und C. Mein Entwicklungsleiter seit 20Jahren immer nur in Assembler. Letztens kamm es dann auch mal zum Streit. Er hat dann das Programm in Assembler gemacht und ich in C. Codeumfang in C war ca. 20% größer, Geschwindigkeit eigentlich nicht zu unterscheiden. Nur... Er hat 20Stunden gebraucht und ich nur 4. Ausserdem ist mein C Programm leicht lesbar, das Assemblerprog. ehr nicht. Fazit, wenn ich nochmal was in Assebler mache muss ich schon sehr wichtige Gründe anbringen. Ach ja war nen PIC Controller.
tom wrote: > also mal aus der Praxis. Ich programmiere seit 10 Jahren in Assembler > und C. > Mein Entwicklungsleiter seit 20Jahren immer nur in Assembler. Letztens > kamm es dann auch mal zum Streit. Er hat dann das Programm in Assembler > gemacht und ich in C. Codeumfang in C war ca. 20% größer, > Geschwindigkeit eigentlich nicht zu unterscheiden. Nur... Er hat > 20Stunden gebraucht und ich nur 4. Ausserdem ist mein C Programm leicht > lesbar, das Assemblerprog. ehr nicht. > Fazit, wenn ich nochmal was in Assebler mache muss ich schon sehr > wichtige Gründe anbringen. Ach ja war nen PIC Controller. ahja, naja, verstehe dann bloss nicht, warum überall im Forum steht: Ich brauche eine Ansteuerroutine für dies und für das. Für ein Textdisplay, für eine I2C-Peripherie, sogar für die Bausteininitialisierung. Seit wann braucht man für sowas Treiber? Eh, die gefunden sind, bin ich fertig mit der Programmierung. Übrigensm das Handterminal hatte 120KB verbraucht, ich nur 5. Warum ???
du bist halt der größte Assembler-GOTT hier am Platz. Werde glücklich damit,...
Dirk Hofmann wrote: > Seit wann braucht man für sowas Treiber? Es ist halt schön, wenn man Sachen, die man öfters braucht, etwas universeller schreibt, damit man sie nicht jedesmal neu schreiben muß. Ich hab da auch einige, die ich ohne groß nachdenken zu müssen einfach mit dazu linke. Man kann sowas Treiber nennen, muß es aber nicht. > Übrigensm das Handterminal hatte 120KB verbraucht, ich nur 5. Warum ??? Na dann könnte ich es in C vielleicht in 4,5kB schaffen. Es ist ne altbekannte Tatsache, daß man Programmieren nicht in der Schule lernen kann, sondern nur durch programmieren, programmieren und programmieren. Es kann daher nicht verwundern, daß es da Effizienzunterschiede von 100:1 und mehr gibt. Diese Unterschiede haben aber überhaupt nichts mit C oder Assembler zu tun. Peter
Sorry Tom, so redet jemand, dem die Argumente ausgehen. Mit Gott hat das nix zu tun. Ich bin in der Industrie tätig. Und da zählt, was unter dem Strich rauskommt. Und wenn ich ständig mitbekomme, daß Maschinensteuerungen sich aufhängen, abstürzen etc. und das heute im Industrie und Privatbereich eigentlich schon zum guten Ton gehört, dann weiß ichs auch nicht mehr. Bei Autos ist mittlerweise die größte Ausfallstatistik auf Software zurückzuführen. Es wurde ein Ausdruck geprägt: KISS Keep It and Short and Simple Das heißt soviel wie, orientiere Dich an dem was gebraucht wird. Und man wird es Dir danken. Ich spreche aus Erfahrung. Natürlich stecken hier ganz andere Interessen der Hard und Softwareindustrie dahinter, um zu verkaufen. Aber auch bei der Programmierung ist es so. Um ein Verständniss für Abläufe und Problemlösungsstrategien zu bekommem, sollte man beim Grundwissen anfangen. Ich kam auch nicht als Erwachsener zur Welt.
Hallo Peter, da hast Du schon recht. Das bedingt aber eigentlich, wie in jedem Bereich, daß ,man in seinem Bereich gut sein muß. Das heißt, wenn man (wie es heute gang und gebe ist) Leute auf Projekte mit Verantwortung loslässt, kann das bös enden. Wie Du weisst, kann man sich in ASM genauso eine Bibliothek aufbauen. Kommt ein neues Bauteil wie Display dazu, wie lange soll ich dann warten und Suchen, ob mal jemand nen Treiber schreibt. Ich hatte mal nen Bekannten der hat behauptet C wäre viel schneller als Assembler und wusste nicht mal, daß Assembler die Ursprache ist. Ich will garnichts gegen C sagen. Aber jeder der dies Programmiert sollte auch Assembler können. Warum soll man sich sonst was disassembleieren lassen. Warum hat eigentlich noch niemand auf meine kleine Aufgabenstellung oben reagiert ?
@Dirk Hofmann Hör doch endlich auf, mit Deinen an den Haaren herbeigezogenen Beispielen hier im Forum herum zu miespetern! Ich denke Du bist einfach nur frustriert, weil Du zu doof bist, richtig C zu lernen und zu verstehen! Ok, es komm sicher mal vor, dass ein erfahrener ASM-Freak ein C-Neuling recht alt ausehen lassen kann! Aber Fakt ist: Gut geschriebene C-Programme mit vernünftigem Compiler übersetzt sind nur ca. 10..30% grösser bzw. langsamer, als man es mit Assembler hinkriegen würde. Dafür ist der C-Programmierer 10 x schneller fertig, der Code ist viel besser lesbar und einfacher auf andere uC zu protieren. Klar gibt es auch schlechte Beispiele, in C wie auch in ASM. Und es gibt vermutlich 100 mal mehr C-Programmierer als ASM-Freaks, logisch dass es im Forum auch 10..100 mal mehr C spezifische Fragen und Problemchen gibt!
Hallo Alexander, >Ok, fangen wir mal so an: >Ziel meines Projektes ist es, eine Bahnsteuerung für 3 Achsen mit >Schrittmotoren zu bauen. Dabei muss ich jeden Schrittmotor mit 100kHz >takten können. Dazwischewn muss ich im worst case Ellipsen fahren >können. Das heißt Berechnung von Winkelfunktionen, Quadratwureln und ein >paar Multiplikationien und Additionen innerhalb der Taktzeit bei eben >diesen 100kHz-Takten. ich habe so etwas mit 4 synchronen Achsen bei einem Takt von max. 20kHz/Achse auf einem C167/20MHz implementiert. Genauigkeit der Berechnungen 0,5µm! Alle Rechnungen werden im Long (4Byte) Integerformat ausgeführt. Winkelfunktionen sind in einer Lookup-Table hinterlegt! Alles in C, mit ein bischen ASM-Optimierung an zeitkritischen Stellen. Wo liegt das Problem? Schnelligkeit (Takt, Busbreite) von Controllern ist nicht alles. Peripherie und richtige Programmierung sind nicht zu unterschätzen! Ich weis nicht was Du für Schrittmotoren hast, die 100kHz unter Last folgen können? Oder bist Du in der Nanotechnik zuhause?
Sabine wrote: > @Dirk Hofmann > > Hör doch endlich auf, mit Deinen an den Haaren herbeigezogenen > Beispielen hier im Forum herum zu miespetern! Ich denke Du bist einfach > nur frustriert, weil Du zu doof bist, richtig C zu lernen und zu > verstehen! Tja Sabine, wie gesagt, wenn die Argumente fehlen. Aber leider geht es um die Realität. Wer sagt, daß ich kein C kann. Schau Dir mal den Beitrag von G-Code an. Ich denke, dort steht was gemeint ist. Mit Kanonen nach Spatzen geschossen. Es werden Sachen aufgeblasen, wo es eine ganz einfache Lösung gibt. Warum redest Du gegen Mich und gibst nicht dem Author dieses Artikels fundamentierte Unterstützung?
Google nach LPC3180; würde den Anforderungen genügen ist aber als Microcontroller mit I/O Funktionen eher mittelprächtig und entspricht somit wiederum den Anforderungen, hat vieles nicht.
>@ Zacc warum weiss du denn dass der Wertebereich nicht vorhanden ist?
Kennst du mein Projekt im Detail?
Drehen ist 0..2Pi, die wenigsten Amwendungen benoetigen einen
dynamischen Bereich groesser als 10^9, Das kann man mit 32 bit abdecken.
Strom und Spannung ist selten genauer als 10^-3, die anderen
physikalischen Groessen
sind auch im Bereich 10^-3. Statische Skalierungen zieht man raus.
Nein ?
Z
Ah, die leidige Diskussion C oder ASM... In den Anfängen der Computergeschichte hätten die Programmierer für assembler getötet (ja die haben noch ihren eigenen Machinencode mit DIP Schaltern eingegeben), heutzutage kaufen sich faule HLL (High Level Language) Programmierer lieber einen schnelleren Controller als nochmal auf ASM zurück zu greifen. Ans Ziel kommt man heutzutage sicherlich mit beiden Methoden, Fakt ist jedoch: Assembler ist die Machinen-nächste Sprache. In ASM schreibt sich der schnellste und knappste code. Allerdings dauert das schreiben in Assembler auch recht lange (insbesondere wenn man einen komplexen Controller wählt). C ist die schnellste und grundlegenste der HLL's. Schneller und kurzer code lässt sich mit C entwickeln, die aufgewendete Zeit diesen zu schreiben ist gegenüber assembler auch viel geringer. Da C eine High Level Language ist, lässt sich derselbe C code auch viel leichter auf verschiedene Controller anwenden. Für komplexere Projekte ist C durchaus vorzuziehen. Jetzt wird fertiger C code natürlich compiliert, also in Machinensprache überführt. Dabei verwendet der compiler aber standard Wege. Standard Wege sind nicht immer die schnellst möglichen. Hinzu kommt der Syntax unterschied zwischen C und Machinencode, der vom compiler verarbeitet werden muss. Das alles geht zu Lasten der Effizienz(Bequemlichkeit geht immer zu Lasten der Effizienz)...
Mr. G-Code wrote: > ich habe so etwas mit 4 synchronen Achsen bei einem Takt von max. > 20kHz/Achse auf einem C167/20MHz implementiert. Genauigkeit der > Berechnungen 0,5µm! Alle Rechnungen werden im Long (4Byte) Integerformat > ausgeführt. Winkelfunktionen sind in einer Lookup-Table hinterlegt! > Alles in C, mit ein bischen ASM-Optimierung an zeitkritischen Stellen. > Wo liegt das Problem? O.K. vielleicht sollte ich meine Berechnungen kontrollieren und nachsehen ob ich wirklich auf 32Bit int umsteigen kann - wird sich mit gewissem Aufwand auch machen lassen. > Ich weis nicht was Du für Schrittmotoren hast, die 100kHz unter Last > folgen können? Oder bist Du in der Nanotechnik zuhause? Nein, aber wenn ich 1 Schritt auf 1/100 mm habe und v=s/t dann ist vMax bei 10 us 1000mm/s und diese Geschwindigkeit brauche ich schon. Was hat das mit Nanotechnologie zu tun? Danke dass sich endlich wieder jemand dem beabsichtigten Thema widmet... Ewig dieses geplänkel was die ultimative Programmiersprache ist... Natürlich Perl, oder ;-)
NaYthan wrote: > Jetzt wird fertiger C code natürlich compiliert, also in Machinensprache > überführt. Dabei verwendet der compiler aber standard Wege. Standard > Wege sind nicht immer die schnellst möglichen. Das klingt ein wenig nach Binsenweisheit. Auch der Assembler-Programmierer verwendet Standardwege um eine Iteration oder ein select-case-Konstrukt in Assembler abzubilden. Um diesen Standardweg zu verbessern wird optimiert. Der Assembler-Programmierer kann das sehr gut, aber er braucht dafür sehr viel Zeit und opfert Lesbarkeit des Codes, deshalb wird er es nur in wenigen Fällen tun. Der C-Compiler kann das (noch!) nicht ganz so gut, dafür kostet es ihn praktisch nichts.
Hi! >Nein, aber wenn ich 1 Schritt auf 1/100 mm habe und v=s/t dann ist vMax >bei 10 us 1000mm/s und diese Geschwindigkeit brauche ich schon. Nun deine Überlegung mag stimmen, nur mit den 60m/min und deiner Auflösung komme ich auch noch nicht ganz klar. Ich kenne auch keine Schrittmotoren die diese Geschwindigkeit mitmachen oder deine Def. von 1 Schritt ist eine andere als wir denken.Ich kenne Dynamikantriebe aus der Industrie, aber das sind Synchronmotoren die über das Drehfeld gesteuert werden. Da könnte ich mir sogar vorstellen das die PWM für jede Phase mit 100kHz neu berechnet wird, aber Schrittmotoren???... ne ne die reagieren nicht auf 100kHz, die lachen dich aus. Kannst du das mal mit den Schrittmotoren etwas genauer erklären. Viel Erfolg, Uwe
@ Alex Tricktronic
Da verwechselst Du Äpfel mit Birnen. An der Steuerung kann die
Schrittzahl von 200 ... 10000 pro Umdrehung einstellen. Und die
Steuerungseingänge können bis max. 200 kHz betrieben werden.
Beim Schrittmotor handelt es sich um einen 3-Phasen Schrittmotor, besser
3 Phasen Synchronmotor, also eigentlich um keinen Schrittmotor. Die
Ansteuerung produziert modifizierte Sinuskurven (je nach Schrittzahl)
und erlaubt so die Ansteuerung ähnlich eines Schrittmotors.
Mich würde mal interessieren, ob die Steuerung + Motor diese
rechnerischen Genauigkeiten wirklich ereichen, oder nur bei Motoren mit
Untersetzungen?
Kurz gesagt:
Motor 3-Phasen Synchronmotor.
Ansteuerung Schrittmotor like.
Dies macht die ganze Sache noch leichter. Wo liegt das Problem ;-)
>Was hat das mit Nanotechnologie zu tun?
Schon mal was von Massenträgheitsmoment gehört?
Was glaubst Du, warum ein Modellbau Verbrennungsmotor Drehzahlen von
18000 1/min mühelos erreicht, und Dein Auto gerade mal ca. 6000 1/min.
"Der unbelastete Motor startet und stoppt mit der Start-Stopp-Frequenz. Wenn externe Trägheitsmomente auf den Motor wirken, müssen Sie für die Start-Stopp-Phase eine niedrigere Frequenz wählen." MfG Falk
Hi! Deine Motoren sind also im gehobenen Speilzeugbereich angesiedelt. Habe gerade mal die Datenblätter studiert und ich glaube das solltest du auch mal machen. Deine Eingänge vertragen zwar 200 kHz aber selbst der kleinste Motor hat bei 50kHz fast kein Drehmoment mehr. Beim grössten ist bei 10kHz Feierabend. Das wäre dann schonmal wenigstens Faktor 5-12 wenn du noch etwas Drehmoment haben willst. Des weiteren würde ich sagen du solltest für jede Achse einen eigenen Controller einsetzen der kurze (1/10mm)Achsbewegungen selbstständig verarbeitet. Willst du eigentlich mit 60m/min irgendwas bearbeiten oder nur Positionieren. Wenn nur Positionieren gefragt ist, werden im Industriebereich 3 Bereich realisiert: Anfahren, Eilgang, Bremsen. Beim Eilgang wir dann nicht mehr auf 1/100 geschaut. Vorschub, also Bearbeitung, kenne ich aber auch blos bis 10m/min was natürlich Rechenzeit schafft. Du solltest dein ganzes Projekt also nochmal gut überdenken und realistische Grenzen festlegen. Solltest du tatsächlich solche hohen und präziesen Anforderungen haben wirst du um ein Multiprozessorsystem nicht rumkommen. Viel Erfolg, Uwe
Hallo Uwe, ich steuere schon solche Motoren mit 100kHz in einem 2-Achs-System an - mit gleichmäßiger Beschleunigung auf Maximalgeschwindigkeit. Wenn ich aber keine geraden sondern Kurven fahren will ist die Beschleunigung nicht mehr konstant und die Berechnungen dauern viel länger. Ich bewege kein bearbeitendes Werkzeug sondern spezielle Laserentfernungsmessgeräte die Objekt vermessen sollen. Ich brauche also - vereinfacht gesagt - eine rückfreie Bewegung bei der ich zu jedem Lasermesswert die aktuelle 5-Achsen-Position habe. Und das im besten Fall mit einer Auflösung von 1/100 mm damit ich keine unnötige Messwertabweichung erhalte. Die Motoren bzw. deren Interface kann ich mit 100kHz ansteuern, die Entfernungswerte nach z.B. 15 Schritten (=0.15mm) stimmen lt. Laderdistanzmessung dann auch! - Also das funktioniert bestimmt. Die Maximalgeschwindigkeit brauche ich nur zum Positionieren, aber die Messgeschwindigkeit ist nicht allzu weit von dieser Geschwindigkeit entfernt. Meine Überlegungen haben mich auch schon zum Multiprozessorsystem geführt. Oder eben zu einem FPGA oder DSP, wobei ein FPGA sicherlich mehr arbeit abnehmen könnte als nur die Achsansteuerung. MFG Alex
Hi! Aja, jetzt lichtet sich der Nebel langsam. Du brauchst also fast kein Drehmoment. Du willst also recht genau messen hmmm... würde ich mit Multiprozessor machen weil du ja auch noch messen willst. Die Achsprozessoren bekommen ihre kleinen Wegwerte und mit dem Fahrtakt wird gleichzeitig ein Timer von Extern getaktet. Dein Lasersignal kommt an den entsprechenden IC-Pin und bei Signal hast du den genauen Wert der Impulse im ICP-Register. Dann noch eine schnelle Unterhaltung zwischen Proz. und du hast eine recht genaue und schnelle Regelung + Messung. Ist aber jetzt glatt aus dem Ärmel geschüttelt und bedarf noch etlicher Überlegungen, aber ein Mega macht bis zu 20MHz, da wird einiges fertig. Viel Erfolg, Uwe
Hallo, da der mega nur 8 bit hat und auch keine fpu wirds mit denen wohl kaum funktionieren. Auf die Wurzelberechnung kann ich nicht verzichten (zumindest wüsste ich nicht wie) und die dauert in einem AVR ewig (0.1-300ms, je nach Wert). Aber ich bin mir sicher dass ich die geeigneten Controller bzw. Hardware finde! Danke, Alex
>Auf die Wurzelberechnung kann ich nicht verzichten (zumindest wüsste ich >nicht wie) und die dauert in einem AVR ewig (0.1-300ms, je nach Wert). Versuchs mal damit:
1 | //***************************************************************************
|
2 | //ADG:! Integer Wurzelfunktion: Routine to do a fast square root of a 16 bit integer
|
3 | unsigned int uiMyMath_SquareRoot(unsigned long Square) |
4 | {
|
5 | unsigned char i; |
6 | unsigned long int root = 0; /* 16 bit answer */ |
7 | unsigned long int square1 = 0; /* 32 bit storage */ |
8 | unsigned long int try = 0; /* 32 bit storage */ |
9 | |
10 | for (i=1; i <= 16; i++) /* 16 = #bits / 2 */ |
11 | {
|
12 | square1 = (square1 << 2) + (Square >> 30); /* 30 = #bits - 2 */ |
13 | Square = (Square << 2); |
14 | root = (root << 1); |
15 | try = (root << 1); |
16 | |
17 | try++; |
18 | if (try <= square1) |
19 | {
|
20 | square1 -= try; |
21 | root++; |
22 | }
|
23 | }
|
24 | return((unsigned int) root); |
25 | }
|
Das einzig Wahre und die hohe Schule es Programmierens IST UND BLEIBT einzig Assembler. Es gibt keinen Grund, darauf zu verzichten, wenn es um kompakte & schnelle Programme geht. Der ganze Hochsprachenmüll hat letztlich dazu geführt, daß ein beispielsweise Windows Vista heute GB in RAM und auf HDD benötigt. Aber es ist ja so schön bequem...
Das sag nicht nur ich, Andreas. Wollte mich nur dem Dirk Hofmann in diesem Thread anschließen. Nun ja, möge jeder mit dem Werkzeug glücklich werden, das er beherrscht. Allerdings sollte man sich auch mal bewußt darüber werden, welche Unmengen an Ressourcen wie Speicherplatz und Prozessorleistung durch ineffiziente Hochsprachenprogrammierung auf diesem Planeten verschleudert werden! Da ließen sich viel Geld und auch so einige Kraftwerke einsparen- um mal den Bogen zur aktuellen Klimadebatte zu schlagen.
ich kann meinem Vorredner da nur noch was zufügen, Ist ist heutzutage schon normal geworden, bessser gesagt, man nimmt es in Kauf wenn Programme regelmäßig zum Absturz führen. Wenn mir jemand erklären kann, warum Maustreiber aus MEGABYTE (nicht KILOBYTE) bestehen, so möge er sprechen oder schweigen. Na klar, kann man auch in Assembler Fehler machen. Dewegen hatte ich auch geschrieben nicht auf vielen Hochzeiten tanzen, sondern das was man macht gut machen. Da wird doch niemand dagegensprechen. Natürlich muß man folgendes mit einbeziehen. Es wird nie im Interesse der Halbleiterindustrie oder Softwarehersteller sein, daß zu unterstützen. Stellt euch vor, viele Programmierer würden effizient mit dieser Sprache arbeiten, Microsoft Intel blabla wären tot, weil wir immmer noch beim Pentium I wären. Soviel mal dazu
@another Assembler Freak >werden, das er beherrscht. Allerdings sollte man sich auch mal bewußt >darüber werden, welche Unmengen an Ressourcen wie Speicherplatz und >Prozessorleistung durch ineffiziente Hochsprachenprogrammierung auf Ineffiziente Programmierung? JA. Viele programmierende sind keine guten Programmierer. Aber Hochsprachen an sich müssen nicht ineffizient sein, und gerade die C-Complier für uCs sind da VERDAMMT nah am Assembler (in Geschwindigkeit und Speicherplatzverbrauch) MfG Falk
@Falk: Die "ineffizienten" Programmierer sind sicher ein anderes Thema. Ineffizient programmieren kann man jedenfalls auch in Assembler :-) Was aber die Programmiersprache an sich betrifft, ist "verdammt nah" sicher relativ. Das mag im Einzelfall und vor allem bei den ganz kleinen Mikros durchaus einmal zutreffen. Wird Programm & Prozessor größer, relativiert sich das ganz ganz schnell. Gib ruhig zu, daß Du in Hochsprache aus purer Bequemlichkeit und Gewohnheit programmierst :-))
Falk wrote: > Aber Hochsprachen an sich müssen nicht ineffizient sein, und gerade die > C-Complier für uCs sind da VERDAMMT nah am Assembler (in Geschwindigkeit > und Speicherplatzverbrauch) Zustimm ! Der für Ineffizienz eines Programms verantwortliche Teil sitzt zu 99% vor dem Bildschirm. Ich hab früher mal 10 Jahre Assembler gemacht und kann die Assemblerverfechter verstehen. Ich mache aber schon einige Jahre C und kann ihnen daher jetzt nicht mehr zustimmen. Es sind nur extrem wenige Fälle, wo sich einige Zyklen Zeiteinsparung auch signifikant auf die gesamte Programmausführungszeit auswirken. Peter P.S.: Ich hab mal den C51 Compiler gegen meine in vielen Wochen mühsam optimierte Divisionsroutine antreten lassen, um dann enttäuscht festzustellen, daß er mehr als doppelt so schnell war. Und bei der Multiplikation war er nur leicht besser.
@another Assembler Freak >durchaus einmal zutreffen. Wird Programm & Prozessor größer, relativiert >sich das ganz ganz schnell. Das sagte ich doch, oder? >Gib ruhig zu, daß Du in Hochsprache aus purer Bequemlichkeit und >Gewohnheit programmierst :-)) Der Herr irrt gewaltig! ;-) Ich bin Hardwerker, und als solcher ein "niederes Wesen" was sich vonehmlich in Assembler und VHDL austobt. Ich hab keine Ahnung von Java, C++ und weissdergeierwasgeradetrendyist. Was aber nicht heisst, dass ich vollkommen ignorant, starrköpfig und lernresistent bin und meine kleine Betätigungswelt als das Universum ansehe. Ich habe viele Jahre AVRs (im Hobbybereich und Studium) in Assembler programmiert. Vor eingen Wochen hab ich mir mal den WinAVR angeschaut und war sehr positiv überrascht! MfG Falk
@Peter Dannegger >Es sind nur extrem wenige Fälle, wo sich einige Zyklen Zeiteinsparung >auch signifikant auf die gesamte Programmausführungszeit auswirken. Alte Programmiererregel. 90% der Rechenzeit werden in 10% des Programms verbraucht. Diese 10% müssen optimiert werden, der Rest muss "nur" solide gemacht sein. >Ich hab mal den C51 Compiler gegen meine in vielen Wochen mühsam >optimierte Divisionsroutine antreten lassen, um dann enttäuscht >festzustellen, daß er mehr als doppelt so schnell war. Und bei der "Der für Ineffizienz eines Programms verantwortliche Teil sitzt zu 99% vor dem Bildschirm." ;-) MfG Falk
> Wenn mir jemand erklären kann, warum Maustreiber aus MEGABYTE > (nicht KILOBYTE) bestehen, so möge er sprechen oder schweigen. Wenn du denkst dass diese x Megabyte zu einem nennenswerten Teil aus Programmcode bestehen, dann irrst du dich ganz gewaltig.
another Assembler Freak wrote: > @Falk: Die "ineffizienten" Programmierer sind sicher ein anderes Thema. > Ineffizient programmieren kann man jedenfalls auch in Assembler :-) Was > aber die Programmiersprache an sich betrifft, ist "verdammt nah" sicher > relativ. Das mag im Einzelfall und vor allem bei den ganz kleinen Mikros > durchaus einmal zutreffen. Wird Programm & Prozessor größer, relativiert > sich das ganz ganz schnell. Genau umgekehrt. Je kleiner das Programm und je einfacher der Prozessor, desto mehr lässt sich mit Assembler rausholen; je größer das Programm und je komplexer der Prozessor, desto weniger macht es Sinn sich mit Assembler zu beschäftigen, weil der Programmierer bei Dingen wie Instruction Scheduling einfach nicht mehr mit vertretbarem Zeitaufwand mit einem Compiler mithalten kann. > Gib ruhig zu, daß Du in Hochsprache aus purer Bequemlichkeit und > Gewohnheit programmierst :-)) Was du Bequemlichkeit nennst nennen andere Entwicklungskosten.
Falk wrote: > 90% der Rechenzeit werden in 10% des Programms verbraucht. > > Diese 10% müssen optimiert werden, der Rest muss "nur" solide gemacht > sein. Wenn es denn bloß so einfach wäre. Leider bestehen MC-Programme oftmals zu 90% aus Delayschleifen und diese 90% verbrauchen dann 99% der CPU-Zeit. Und Delayschleifen sind definitv nicht optimierbar. Man muß sie konsequent rauswerfen, was ein Wegschmeißen dieses Programmierstils und aller damit erstellten Anwendungen bedeutet. Ich bin mir sicher, ich könnte viele Projekte aus meiner Assembler-Anfangszeit mit einem 10* kleineren Quarztakt unter C realisieren, die Erfahrung machts. Man weiß einfach besser, wie lange was dauert und kann besser abschätzen, wie oft muß ich eigentlich was machen. Peter
>Auf die Wurzelberechnung kann ich nicht verzichten (zumindest wüsste ich >nicht wie) @Alex Tricktronic: Versuchst du wirklich von Punkt zu Punkt während der Bewegung deine Kurve zu berechnen? Dann kann ich mir gut vorstellen das dein Mikrocontroller das nicht schafft. Ich denke auch sehr "potente" Mikrocontroller werden da ins Schwitzen kommen. Hast du eigentlich schon mal eine Fehlerbetrachtung gemacht wo du dich im Bezug auf die Maschinengenauigkeit befindest? Warum zerlegst du deine Kurve nicht in eine Aneinanderreihung von Geraden, wie fein die Untergliederung sein muss, kannst du ja dynamisch festlegen. (Je nach Kurvenradius). Dann sinkt die benötigte Rechenleistung beträchtlich, da jeweils nur die Verbindungspunkte der Geraden berechnet werden müssen, dazwischen wird ein Bresenhamalgorithmus gemacht. Das dürfte dein derzeitiger Mikrocontroller locker schaffen.
> Versuchst du wirklich von Punkt zu Punkt während der Bewegung deine > Kurve zu berechnen? > Dann kann ich mir gut vorstellen das dein Mikrocontroller das nicht > schafft. > Ich denke auch sehr "potente" Mikrocontroller werden da ins Schwitzen > kommen. > Hast du eigentlich schon mal eine Fehlerbetrachtung gemacht wo du dich > im Bezug auf die Maschinengenauigkeit befindest? > Warum zerlegst du deine Kurve nicht in eine Aneinanderreihung von > Geraden, wie fein die Untergliederung sein muss, kannst du ja dynamisch > festlegen. (Je nach Kurvenradius). Das haben wir hier schon genug durchgekaut - ich brauche diese rechnerische Genauigkeit wegen Messabweichung. > dazwischen wird ein > Bresenhamalgorithmus gemacht. Der Breseham-Algorithmus bei Ellipsen kann beim Schrittmotorfahren nicht gemacht werden, da er die einzelnen Quadranten in Sektoren aufteilt die von verschiedenen Richtungen gezeichnet werden. Der Schrittmotor fährt logischerweise eine Linie durch. Dieser Algorithmus lebt aber davon den Error zu kummulieren, den kann man leider nicht in einer Richtung betreiben - eben so, wie ein Motor fährt.
>Das haben wir hier schon genug durchgekaut - ich brauche diese >rechnerische Genauigkeit wegen Messabweichung das haben "wir" noch überhaupt nicht "durchgekaut", weil du keine Angaben zur geforderten Genauigkeit gemacht hast. Du sprichst von "besten Fall 10um" getestet hast du mit 0.15mm und da stimmt die Genauigkeit. Lege dich doch mal auf eine hinreichende Genauigkeit fest! Betrachte dabei die mechanischen Ungenauigkeiten, die durch deine Wellen mit reinspielen. Ich kenne Linearaktuatoren die haben 10um pro Vollschritt und die Welle ist mit 20-30um möglichen Fehler angegeben. Wenn du die Kurve in Geraden zerlegst, das solltest du das unter dem Aspekt machen, daß deine noch festzulegende Genauigkeit erreicht wird, das war mit dynamische Zerlegung gemeint. Im 2-ten Schritt wird für jeden Verbindungspunkt der Geraden die Geschwindigkeit der einzelnen Achsen berechnet. Die Geraden werden an eine drunter liegende Schicht gegeben, die für jede Achse entscheidet ob sie die angegeben Geschwindigkeit in Voll/Halb oder xtel Schritt löst. Kriterium ist dabei die Schrittzeit, denn du hast ja nur beschränkt Rechenkapazität. Ich denke ich erzähle dir nichts neues, wenn ich dich darauf hinweise das bei xtel Schritt beim Anfahren nicht unbedingt ein Schritt garantiert ist, wenn das Drehmoment nicht ausreicht. Wenn man erstmal fährt kann man auch die Schrittfrequenz über die Start/Stopfrequenz steigern. Für hohe Geschwindigkeiten mußt du sowieso in den Vollschrittmodus gehen. Das funktioniert sehr gut für den beschriebenen Weg mit moderatem Rechenaufwand. Das einzige was festzulegen ist, ist die hinreichende Genauigkeit.
Mein Text: Entfernungswerte nach z.B. 15 Schritten (=0.15mm) stimmen lt. Laderdistanzmessung dann auch! z.B. heißt dann aber nicht dass ich NUR 0.15 getestet habe - lesen und denken. Meine Frage war aber auch nicht wie ich das berechnen kann und ob das eurer Meinung nach überhaupt Sinn macht sondern welchen Microcontroller ich verwenden könnte - vielleicht gibts ja welche an die ich noch gar nicht gedacht habe. Die hinreichende Genauigkeit ist in meinem Fall - oh welch Überraschung 10um. Außerdem reicht das Drehmoment aus. Und den algorithmus hab ich auch schon geschrieben - getestet & funktioniert einwandfrei. Sicher könnte ich die Auflösung der Achsen runterstellen aber das war nicht meine Frage!
Ok. Beantwortung deiner Frage: Auch wenn du deinen Algorithmus nicht vorgestellt hast, ich schätze als Mikrocontroller ist sowas von der Klasse Pentium 4 ab 1,8 GHz nötig. Vielleicht wirst du auch bei Renesas fündig, die haben da gerade was neues. Optimierungen hast du schon im jetzigen System probiert, die haben aber nicht zu der notwendigen Leistungssteigerung geführt. Du könntest ja mal angeben (in Bewegungsgeschwindigkeit) wo du dich derzeit befindest. Das dein Algorithmus funktioniert, bezweifle ich nicht, ich denke nur du verbrennst für die Aufgabe (die du nicht sehr genau spezifizierst) mehr Rechenleistung als nötig ist. Das du eine Abneigung dagegen hast, jetzt den Algorithmus zu wechseln, kann ich nachvollziehen, es wird aber höhere Hardwarekosten nötig machen. Ob die gerechtfertigt sind mußt du entscheiden. Da ich auch schon einen Meßtisch mit 10 um Vollschrittraster gemacht habe stellt sich für mich die Frage warum du von Punkt zu Punkt arbeitest und dabei rechnest. Ich habe Probleme mir vorzustellen, daß das sehr schnell geht und daß sich beim resultierenden Algorithmus die mechanischen Probleme von Wellen und Schrittmotoren lösen lassen. Bis 200 um kann man sowas machen ohne sich mit den mechanischen Gegebenheiten auseinandersetzen zu müssen. Bei 10 um geht das nicht, zumindest nicht bei der Dynamik die du vorgibst. Hauptproblem dürfte die ruckfreie Bewegung sein, da ein Ruck zu Schwingungen führt. Das läßt sich mit dem vorgeschlagenen Algorithmus wesentlich übersichtlicher kontrollieren. Die andere Frage die sich mir stellst ist, ob du bei float überhaupt eine hinreichende Genauigkeit erreichst. Da sagtest das du mit 64bit Int Probleme hattest. Bei float sind nur 23bit mantisse.
Wolfram wrote: > Ok. Beantwortung deiner Frage: > Auch wenn du deinen Algorithmus nicht vorgestellt hast, ich schätze als > Mikrocontroller ist sowas von der Klasse Pentium 4 ab 1,8 GHz nötig. Deshalb habe ich mir auch gedacht dass ich eine Zentral-CPU und für jede Achse eine eigene HW verwenden könnt. > Vielleicht wirst du auch bei Renesas fündig, die haben da gerade was > neues. kannte ich bis jetzt noch nicht . guter Tip! > Das dein Algorithmus funktioniert, bezweifle ich nicht, ich denke nur du > verbrennst für die Aufgabe (die du nicht sehr genau spezifizierst) mehr > Rechenleistung als nötig ist. Das du eine Abneigung dagegen hast, jetzt > den Algorithmus zu wechseln, kann ich nachvollziehen, es wird aber > höhere Hardwarekosten nötig machen. Ob die gerechtfertigt sind mußt du > entscheiden. Höhere Hardwarekosten sind nicht ganz so das Problem - ein Motor kostet sowiso mehr wie die gesamte Elektronik (Materialpreis) > Die andere Frage die sich mir stellst ist, ob du bei float überhaupt > eine hinreichende Genauigkeit erreichst. Da sagtest das du mit 64bit Int > Probleme hattest. Bei float sind nur 23bit mantisse. Ich habe nicht geschrieben dass ich mit int64 Probleme hätte - aber 23bit mantisse reicht mir bei der range von float. Wenn der Controller eine FPU hat dann spielt es zeitlich keine Rolle ob man 64Bit oder float rechnet. DANKE
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.