Hallo, im Rahmen eines Projektes möchte ich eine Zustandsrückführung auf einem Mikrocontroller implementieren. Neben dieser Regelung soll es möglich sein noch weitere Tasks zu bearbeiten. Entschieden habe ich mich, auch wegen floating point unit, für einen 32bit Mikrocontroller. Programmieren möchte ich die Software in C++. Evtl. mit zusätzlichem Betriebssystem. Kennt jemand eine Seite die 32bit Mikrocontroller mit ihren techn. Daten gegenüberstellt? Kommt man bei 32bit Mikrocontrollern bei C++ und Betriebssystem mit internem Speicher (Flash/SRAM) aus? Mir fällt es am Anfang recht schwer einzuschätzen wieviel Speicher so ein Programm wohl brauchen wird. Viele Grüße Stefan
tja, und uns fällt es schwer einzuschätzen welche art von betriebssystem und welche applikationen du laufen haben willst...
Erkläre mal "Zustandsrückführung" genauer. Was genau soll der uC machen?
Das ist alles eine ganz schlechte idee. Man gewinnt nichts mit floating point. Denn den dynamischen Bereich von 10^-308..10^308 von single precision benoetigt man sicher nicht. Dafuer hat 32bit integer 9 signifikante stellen, waehrend singlpe precision float nur 5-6 stellen hat. C++ bringt gar nichts. Willste dynamisch klassen vererben ? Und ein betriebssystem bringt auch gar nichts. Das macht's nur viel schwieriger eine vernuenftige Echtzeit performance zu erreichen. Willste einen Garbage collector haben, der irgendwann findet er muesse mal rueber ? Oder einen Beagle, der findet, er muesse mal mit Indexieren beginnen ? Zustandsrueckfuehrung bedeutet nur, dass man ein paar Matrizen multipliziert, das kann man immer. Allerdings waere wichtiger mit welcher sample frequenz man arbeiten moechte. Moeglicherweise kommt auch ein 8bitter hin.
Stefan schrieb: > im Rahmen eines Projektes möchte ich eine Zustandsrückführung auf einem > Mikrocontroller implementieren. Dann erklär erstmal, welche Rechnungen diese Aufgabe ausführen muß und in welcher Zeit. > Entschieden habe ich mich, auch wegen floating point unit, für einen > 32bit Mikrocontroller. Float geht auch prima auf nem 8Bitter. Wieviel tausende float-Rechnungen pro Sekunde brauchst Du denn? Peter
Hallo erstmal herzlichen Dank für die vielen Antworten. Ich bin noch ganz am Anfang meiner Überlegungen und habe dank diesen gemerkt, dass ich mich erst noch einmal intensiv mit den Anforderungen beschäftigen muss. Viele Grüße Stefan
Anmerkung: Oft ist es sinnvoller das Problem erstmal auf dem PC zu lösen. Wenn es um eine Regelung geht vielleicht auch über Matlab/Simulink nachdenken. Dann daraus einen möglichs portablen C-Code erstellen (oder durch Matlab erstellen lassen) und auf dem PC simulieren. Dann kannst du auch die Anforderungen an den Controller besser abschätzen Denn auf einer Embedded HW hast du mehrere Baustellen gleichzeitig offen.
ich würde mal die Idee mit dem OS nicht sofort verwerfen. Es muss ja nicht gleich Vista drauf. Es gibt sehrwohl Echtzeitbetriebssysteme, die mehrere Prozesse erlauben - was ja eine der Anforderungen zu sein scheint und vielleicht händisch viel zu viel Arbeit bedeutet. http://de.wikipedia.org/wiki/Liste_der_Betriebssysteme#Eingebettete_und_Echtzeit-Betriebssysteme aber das scheint hier ja nur ein kleiner Teil des Problems zu sein
Hallo nochmals, vielen Dank auch für die weiteren Anregungen. Matthias Keller schrieb: > Oft ist es sinnvoller das Problem erstmal auf dem PC zu lösen. Wenn es > um eine Regelung geht vielleicht auch über Matlab/Simulink nachdenken. Nach den ersten Antworten habe ich auch gemerkt, dass ohne die Lösung in Matlab bzw. die Modellbildung und Regelsimulation erstmal kaum absehbar ist, welche Codemenge bzw. welcher Berechnungausfwand auf uns zu kommt (vor allem weil wir recht wenig Erfahrung in der Regelungstechnik bzw. in der Implementierung besitzen - wie meist sind die Vorlesungen doch eher theoretisch gewesen). Die Idee mit der Mikrocontroller Auswahl zu Beginn kam daher, dass es sich um eine Projektarbeit handelt und entsprechend ein recht knapper Zeitrahmen vorhanden ist. Es wäre also gut möglichst früh die Komponenten auszuwählen. Andererseits bringt es ja nichts wenn man aufgrund mangelnder Vorüberlegungen vollkommen an den wahren Anforderungen vorbeischießt. Wie gesagt wir werden und nun erstmal auf Modellbildung und Simulation konzentrieren. Armin schrieb: > ich würde mal die Idee mit dem OS nicht sofort verwerfen. Es muss ja > nicht gleich Vista drauf. Es gibt sehrwohl Echtzeitbetriebssysteme, die > mehrere Prozesse erlauben - was ja eine der Anforderungen zu sein > scheint und vielleicht händisch viel zu viel Arbeit bedeutet. Sowohl Betriebssystem, wie auch Programmierung in C++, sind eigentlich Anforderungen an das Projekt, da nachfolgende Studenten Erweiterungen komfortabel vornehmen können sollen. Nur so kann unser Prof. die recht hohen Kosten rechtfertigen. Die Abneigung gegen C++ in einem der obigen Beiträge verstehe ich nicht ganz. Gerade wenn man die floating point Idee verwirft und mit fixed point (z.B. 16.16) arbeitet ist ein eigener Datentyp als Klasse doch viel einfacher bzw. komfortabler zu implementieren als in C.
Welche hohen Kosten ? Ein paar Matritzen durchzulassen ? Das kann man mit einem Evalkit fuer 100 euro schon machen. Was ist der Vorteil von C++ ueber C ? Vererbung, Abkapselung und dynamische Bindung. Davon braucht man bei so einer Anwenung nichts. Mit einem Int32 ist man ueblichweise dabei. Dabei rechnet als fractional, den Dezimalpunkt behaelt man im Kopf. Am Projekt nachbessern ? Macht wenig Sinn. Ein paar Matritzen sind hinreichend trivial, das Ganze bei Bedarf neu zu schreiben.
Eine Zustandsrückführung ist recht einfach, das ist ja gerade ihr großer Vorteil - ungefähr n^2 Multiplikationen und n^2 Additionen. Je nach benötigter Abtastrate (und Systemordnung) schafft das auch eine 8Bit-CPU. Es gibt noch eine ganz nette Vereinfachung, wenn man die Ausgangsgleichung mal ausmultipliziert und die Matrixelemente konstant sind - führt wenn ich mich richtig erinnere auf ungefähr 2*n Multiplikationen und 2*n Additionen. Da man maximal 16Bit sinnvoll verwenden kann (mehr Auflösung wird man kaum in die Eingangs- und Ausgangsgrößen hineinbekommen) kann man recht locker mit 32Bit-Zahlen rechnen. MfG, Heiko
Nur so mal als Anhaltspunkt: Ich habe vor kurzem eine Integral-Zustandsrückführung (3x3) mit Beobachter auf einem 32Bit ARM7 @60MHz realisiert. Zusammen mit einem weiteren PI-Regler, dem Einlesen der Analogwerte und Setzen der PWM waren ca. 10 KHz Reglertakt drin. Mit SW FP und hardgecodeten Routinen in C++ (ohne Klassen). Ein OS habe ich ebenfalls nicht verwendet. LG Jan
10kHz Samplerate ist schon ueppig. Welche Art System [Die Physik, nicht die Elektronik] ist denn so schnell ?
Ich hab damit ein Magnetschwebesystem geregelt. Knapp 3 KHz waren da Pflicht. Für eine größere Steifigkeit bieten sich aber noch höhere Reglertakte an. Mit dem Erreichten konnte man aber schon recht gut arbeiten und hat sogar noch Platz für komplexere Reglungen bzw. mehr Magnete.
Danke, das ist sehr informativ. Und die nicht zwischen Spulen pendelnde zusaetzliche Energie wurde direkt per Thyristor eingespiesen ?
Die Einspeisung geschah über eine per PWM angesteuerte Vollbrücke mit entsprechender Stromreglung (der zus. PI Regler).
Beitrag #5787690 wurde von einem Moderator gelöscht.
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.