Hallo, ich habe gerade mit einem neuen Projekt angefangen, dass ich von meinem Vorgänger übernommen habe. Leider wurde hier eine Regelung auf einem F28335 mittels Matlab Simulink Embedded Coder programmiert. "Leider", weil wir eine Lizenz für Matlab, Simulink, Simulink Coder und Matlab Coder, aber nicht für Embedded Coder haben. Dieses Add-On kostet erstaunlich viel. Nun zur Frage: Gibt es eine schlaue Herangehensweise, das Simulink-Modell ohne Embedded Coder zur Code-Generierung nutzen zu können, ohne gleich das ganze Projekt händisch in C zu verfassen? Besten Dank! Markus
Rechne aus wieviel es kosten würde, das Ganze händisch in C nachzuprogrammieren (testen und Doku nicht vergessen!) und mach dann nochmal den Vergleich zu den Lizenzkosten. Wäre es eine Option die Lizenzen für Simulink Coder und Matlab Coder aufzugeben, als Kostenersparnis? Wenn der Vorgänger schon Embedded Coder eingesetzt hat, wo ist seine Lizenz dann hin?
Hallo und danke für die Antwort. Klar, alles in C neu zu programmieren ist eine Option, es liegt ja auch schon der generierte C-Code von der alten Version vor. Es wäre sicherlich billiger, das so zu machen, aber es soll ja auch eine Weiterentwicklung in Simulink stattfinden. Da das Projekt aus der Uni kommt, wurde es vorher mit einer Campus-Lizenz erstellt.
Eric B. schrieb: > Wäre es eine Option die Lizenzen für Simulink Coder und Matlab Coder > aufzugeben, als Kostenersparnis? Das Software Support Package von C2000 benötigt Simulink Coder, Matlab Coder und Embedded Coder. Ich weiß auch garnicht, ob man gekaufte Lizenzen wieder zurück geben kann.
Allgemein musst du dir doch folgende Fragen stellen: 1. wie teuer ist es das Projekt zu portieren 2. wie teuer wäre die Lizenz 3. was gewinnst du bzw. verlierst du durch die Portierung zu 1. und 2. hast du ja schon gesagt, dass du glaubst eine Portierung wäre billiger. Entscheidend ist aber meiner Meinung nach der 3. Punkt und da musst du dir weitere Fragen stellen: 4. ist eine Lösung in Simulink besser zu warten/zu erweitern als eine Lösung in C? 5. bietet eine Lösung in C Möglichkeiten, die du mit Simulink nicht hast? 6. wer kann/soll in Zukunft an dem Projekt arbeiten und können diese Leute eher Simulink oder C? Zu 4. und 5. kann ich aus eigener Erfahrung sagen, dass Simulink-Programme je größer sie werden immer mehr zu "write-only-code" mutieren. Das hat den einfachen Grund, dass bei graphischen Programmierumgebungen die Eindeutigkeit wie bei C nicht so gegeben ist, d.h. es gibt unendlich verschiedene Möglichkeiten seine Blöcke zu platzieren, während es in C lediglich ein paar Zeilen Code sind. Desweiteren ist ein Refactoring bei einer graphischen Programmierumgebung grundsätzlich schwierig, d.h. wenn du etwas ändern willst, dann zeichnest du oft das halbe Model neu. Hast du dagegen nur einen simplen Regler mit einem ADC, einem DAC und ein bisschen Reglerlogik dazwischen, dann bist du mit Simulink super schnell fertig. Das du mit C quasi alle Möglichkeiten hast, die die Hardware dir bietet, während du bei Simulink nur auf die Blöcke zurückgreifen kannst die du hast, sollte auch klar sein. Will man eigene Blöcke erstellen wird es erst richtig abartig, da hat man nämlich nicht nur die Komplexität von seiner Hardware und von der Sprache C, sondern muss sich noch zusätzlich mit den Eigenheiten von Matlab bzw. Embedded-Coder herumschlagen. Der springende Punkt ist aber doch 6., also wer da zukünftig daran arbeiten soll und was diese Leute können. In der Uni wird doch heutzutage Matlab als "Industriestandard" verkauft, so dass es jeder irgendwann einmal lernen muss. Ob du fähige Leute hast oder findest, die ein Projekt in C (weiter-)entwickeln können, dass musst du selber wohl am besten wissen. Wenn du solche Leute hast dann wäre meine Entscheidung sehr wahrscheinlich C. Ist es aber nicht so, dann musst du eben abwägen und das geringere Übel wählen.
Vielen Dank Christopher für die Ausführliche Gegenüberstellung! Leider bin ich noch neu im Geschäft und kann schwer abschätzen, ob eine Portierung nach C (und das wäre in meinem Fall einfach mit dem generierten Code weiter zu arbeiten) sinnvoll ist. 4. ist eine Lösung in Simulink besser zu warten/zu erweitern als eine Lösung in C? - für mich auf jeden Fall, da ich das jetzt "kann" 5. bietet eine Lösung in C Möglichkeiten, die du mit Simulink nicht hast? - bestimmt, aber ist auch nicht nötig... soweit 6. wer kann/soll in Zukunft an dem Projekt arbeiten und können diese Leute eher Simulink oder C? - erstmal nur ich und dann Studenten, die alle lieber Matlab benutzen Das mit dem "write-only-code" ist natürlich so eine Sache. Bisher habe ich noch nicht wirklich viel im C-Code wieder gefunden, was ich vorher im Simulink-Modell hatte. Vielleicht mal anders gefragt: Was ist der Unterschied zwischen Matlab/Simulink Coder und Embedded Coder? Kann ich nicht (evtl. auf Umwegen), auch ohne den Embedded Coder den C-Code erhalten? Ist vielleicht eine dumme Frage, aber würde 5000€ sparen.
Erzaehl doch mal was zur Regelung. Ein normaler PID ? Dann ist er schnell neu geschrieben. Eigentlich ist auch eine andere Regelung schnell geschrieben, denn das Wissen steckt in der Parametrierung.
Hallo, von Simulink wird sowohl der ReadOut des ADC für 4 Sensoren sowie die arithmetische Berechnung der Sensorwerte (Kalibrierung) vorgenommen. Diese werden dann in 3 PID-Reglern gegeben und damit 4 Ausgangsgrößen geregelt. Würde schon irgendwie gehen. Mir wurde von einem Freund jetzt TargetLink von dSPACE empfohlen, um den Code zu generieren. Ich schau mir das mal an :)
Kalibrierung und 3 PID Regler...dafür braucht man nun wirklich kein Matlab/Simulink.. dSpace setzt bei sowas auch auf Matlab/Simulink auf...kostet aber noch um Welten mehr da man selbstverständlich alle Matlab Lizenzen zusätzlich benötigt. Generell lohnen sich solche Toolchains nur für hochkomplexe Regelungen und Rapid-Prototyping.. Octave/Scicos/Scilab können ansonsten auch solch simple Dinge..
Markus P. schrieb: > Vielleicht mal anders gefragt: Was ist der Unterschied zwischen > Matlab/Simulink Coder und Embedded Coder? Soweit ich das verstehe: Matlab Coder: Matlab Code nach C Simulink Coder: Simulink Blockschaltbilder nach C Embedded Coder: Integration der beiden oberen mit der Toolchain des jeweiligen Targets, sowie Target-spezifische Blöcke, z.B. ADC, DAC, PWM, usw. Markus P. schrieb: > Kann ich nicht (evtl. auf Umwegen), auch ohne den Embedded Coder den > C-Code erhalten? Geht vielleicht irgendwie für den Reglercode aber z.B. die ADC-Blöcke sind weg. Markus P. schrieb: > Mir wurde von einem Freund jetzt TargetLink von dSPACE empfohlen Kann mich da TestX nur anschließen. Zum einen wirst du weiterhin Embedded Coder benötigen, wenn du z.B. die ADC-Blöcke weiterhin nutzen willst und zum anderen wird es bei dSpace erst richtig teuer.
Danke für die Einschätzungen, dann versuche ich mal mein Glück und versuche meinen ersten Regler in C. :)
Falls da jemand noch nach 3 Jahren drüberstolpert: Grundsätzlich sollte es möglich sein, mit dem reinen RTW nur C-Code zu generieren (für Signalverarbeitung, Regler, Vorsteuerung) und sich dann händisch einen Wrapper drum zu programmieren, der die Schnittstellen im Mikrocontroller bedient.
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.