Hallo, angeblich kann man aus simulierten Modellen von Matlab simulink c-Code für mikrocontroller bzw auch VHDL Code generieren...hat jemand ne Ahnung wie das funktioniert? danke samuel
Hi C-Code wird über den Real Time Workshop direkt aus Simulink generiert (Im Simulink Modell auf Tools>Real Time Workshop>Options/Build Model). Da kann alles eingestellt werden. VHDL und VERILOG über den HDL Coder (Ebenfalls zu finden unter Tools>HDL Coder>...) Ich arbeite gerade selbst damit, bzw. arbeite mich ein, da ich ein Simulink Modell auf einen AVR bringen möchte. So ganz durchgestiegen bin ich da noch nicht. Hilfe ist also auch hier erwünscht :-) -Kai
Siehe auch RTW-Embedded-Coder. Auf der Mathworks Seite gibt es übrigens auch kostenlose Vorträge zu bestimmten Themen --> Webinars (viel Produktwerbung aber manchmal auch ganz interessant)
@Kai: Wäre schön, wenn du uns (mich) hier auf dem Laufenden hälst. Ich bin gerade in der AVr-Einsteiger-Phase, habe aber sehr gute Simulink Kenntnisse. Habe auch schon viel mit dem RTW gemacht. Dabei wurde das Modell aber direkt für das Target (dSpace-Box) kompiliert und draufgeladen. Mit dem entstandenen c-code habe ich mich nie beschäftigt, obwohl ich auch (achtung eigenlob) guter C++ Programmierer bin.
Welche Mikrocontroller gibt es, die Ich mit Matlab verbinden kann? Kann ich auch einen Atmega8 mit matlab beschreiben? Danke für euere Antworten
Was kann man den unter Matlab anders/besser machen? Beziehungsweise, was hätte man davon, etwas in Matlab zu programmieren?Redet ihr von emulieren? mfg
Hi VHDL kann man mit dem Xilinx Systemgenerator erzeugen. Das klappt echt gut ist nur sehr zeitaufwendig (kann je nach Modell schon mal 30min dauern bis das Modell im FPGA ist). Gruß Marcel
@Der Fast Ja, denke mal der Vorteil ist, dass man alles in Matlab erstaml simulieren kann. Dan weis man ob der Quat...ähm...Hirnschmalz der sich im Kopf gebildet hat, überhaupt so halbwegs in die richtige Richtung geht. Ist natürlich keine Garantie, dass das auf dem Mikrokontroller dann auch noch geht aber die wahrscheinlichkeit ist doch recht hoch. ;)
Michael wrote: > @Der Fast > > Ja, denke mal der Vorteil ist, dass man alles in Matlab erstaml > simulieren kann. Dan weis man ob der Quat...ähm...Hirnschmalz der sich > im Kopf gebildet hat, überhaupt so halbwegs in die richtige Richtung > geht. Ist natürlich keine Garantie, dass das auf dem Mikrokontroller > dann auch noch geht aber die wahrscheinlichkeit ist doch recht hoch. ;) Stehe da etwas auf dem Schlauch. AVRStudio+AVRGCC bietet doch genau sowas, man kann sich doch alle Register, Ports.. anschauen. Was man nicht kann ist etwas "anschließen" am AVR unter AVRStudio. Da wäre Simulink/Matlab hilfreich? mfg --edit AVR Studio simualtion von Assembler AVR Studio + AVR GCC Simulation von C Code Man kann unte AVR Studio die Ports mit Hand manipulieren. Also wenn man ein Prog schreibt, es durchlaufen lääst und es erwartet an PortX ein Bit, kann man das von Hand setzen... Also man muss wissen was man ranhängen kann und welche Sequenz diese Geräte senden. Aber das ist doch mit Simulink/Matlab doch auch so. Wenn ich da eine Simulationsumgebung erzeuge, muss ich doch auch wissen was ich programmiere?
Hallo zusammen, man sollte mal klarstellen, dass Matlab/Simulink 3 Abstraktionsebenen höher liegt, als das Embedded C, das wir auf unseren AtMegas schreiben. Damit macht man mathematische Modelle, deren Grundlage in der Regel Differentialgleichungen sind. Matlab wird deswegen sehr gerne in der Regelungstechnik eingesetzt. Das ist nichts, mit dem man irgendwelche Pins an Displays anschließen kann oder sowas. Mit Matlab simuliert man beispielsweise das dynamische Verhalten eines Antriebsstranges von einem Auto mit Automatikgetriebe. Man kann in so ein Modell dann Regler implementieren und diese optimieren. Wenn man das ganze dann aufbaut, kann man den im Modell optimierten Regler als C Code exportieren und in ein embedded System implementieren, das dann das echte Auto regelt. Ich persönlich halte nicht sehr viel von dieser Vorgehensweise, denn gerade auf kleinen Prozessoren, wie den AVRs entsteht dadurch sehr schnell ein sehr großer Codeoverhead, den man durch vorheriges Nachdenken hätte vermeiden können. Es ist mit Matlab sehr schwierig ein vernünftiges Modell auf einen 8 bit Rechner zu bringen, ohne, dass man erheblich Rechenleistung verschwendet. Zudem garantiert einem niemend, dass der erzeugte Code auch mit allen Eigenheiten der AVRs auf diesen überhaupt zuverlässig läuft. Das Simulieren mit Matlab mag an bestimmten Stellen praktisch sein, aber das Übersetzen von Reglern auf AVRs sollte man von Hand machen, dann ist man sicher, dass alle Integratoren sauber laufen und vor allem sparsam mit Variablengrößen umgehen und nicht alles grundsätzlich in Floatingpointarithmetik machen. Ein Modell in Matlab zu erstellen, das alle Typumwandlungen enthält, die man üblicherweie af einer 8 bit Maschine braucht, damit es überhaupt realisierbar ist, ist sehr sehr aufwendig. Meiner Meinung nach hat ein C-Code von Matlab auf einem AVR nichts verloren, das kann man bei DSPs machen, de irgendwelche komplizierten Filter, Faltungen oder Korrelationen in Echtzeit rechnen müssen und ohnehin in Float am effizientesten arbeiten. Grüße, Peter
Ja ich gebe dir recht. Die Frage war auch nicht ob es sinnvoll ist sondern ob es möglich ist. Ein Antriebsstrang eines Autos ist bestimmt auch nicht verlgeichbar mit einfachen Regelkreisen die dem Ausbildungszweck dienen (z.b. P-Regler). Ich möchte wissen ob Matlab mit irgend einem Modul die Möglichkeit bietet das erstellte Modell (Simulink) auf den Atmega8 zu übertragen?
Bei einem 8 Bit Prozessor wie dem AVR muß möglicherweise auch berücksichtigen, dass alle Berechnungen meines Wissebs nur mit 32 Bit Float zahlen erfolgen, während Matlab/Simulink dazu sicher 64 oder 80 Bit Gleitkomma verwendet. Auch wenn das vom Matlab generierte C Programm mit double Variablen rechnet, der AVR Compiler macht wieder 32 Bit Float daraus. Dann kann man auch Unterschiede zwischen Simulation und Hardware haben.
Hallo, wenn du einen P-Regler auf einem AVR laufen lassen willst, dann schreib ihn doch einfach hin. Regelfehler = Sollwert - Reglereingang; Reglerausgang = Regelfehler * Verstärkung_P; fetig. Wo brauch ich da Simulink dazu? Das schwierige daran ist nicht das Implementiern des Reglercores, das hast du oben gesehen. Nur das kann dir Matlab abnehmen. Das schwierige ist die Anbindung an die Hardware. Die Routinen, die die Variable Reglereingang mit Daten versorgt und Reglerausgang wieder auf die Hardware ausgibt. Diese Arbeit nimmt dir Matlab nicht ab. Grüße, Peter
Besonders lustig wird es bei der Generation von VHDL: Matlab baut Dir auch keine pipelines, asynchrone Fifos und rekursive Strukturen mit Merhfachnutzung. Da müsste sich Mathworks erstmal was in Sachen Logical Constraints einfallen lassen und einige Konvnetionen einführen mit denen man den Code steuern kann. Denkbar wäre das, aber National ist mit Labview dort schon Meilen weiter.
Wie schon gesagt es geht mir nicht darum ob ich das einfach so mit C machen könnte sonder ob die Möglichkeit besteht Simulink dazu zu verwenden. Welche µController würden sich besser dafür eignen ?
Hallo, prinzipiell eignen sich alle Mikrocontroller dafür, denn der erzeugte Code ist standardkonform. Die Frage ist nur, wie effizient die Lösung sein wird im Vergleich zu einem selbstgeschriebenen code. Und die Ansteuerung der Peripherie und Initialisierung der CPU übernimmt Matlab auch nicht, der Code ist also erst nach Überarbeitung lauffähig und das dauert mindestens genauso lang, wie wenn man es gleich selbst schreibt. Von der Seite der Rechengenauigkeit her betrachtet, bieten sich vor allem DSPs und andere 32bit Maschinen an, wie z.B. dsPIC, TMS320, AT91SAM, AVR32, TMS470 usw. 8 bit Mikrocontroller sind für den Code, den Matlab generiert nicht unbedingt ungeeignet, aber mit der Gleitkommarechnung überfordert. Jede Operation dauert ein Vielfaches an Maschinenzyklen, wie auf einem 32 bit Rechner. Grüße, Peter
Ich hab mir mal den dsPIC angeschaut und der sieht eigentlich genau nach dem aus was ich suche laut dieser Beschreibung: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538347 Gibt es den ein Blockmodell in Simulink auch für den Atmega8? Wo finde ich eine Schaltung für den dsPIC die für die Programmieschnittstelle (usb, seriell) geeignet ist?
Hallo! Ich möchte die serielle Schnittstelle in Matlab so konfigurieren, dass diese als USB Schnittstelle am Mikrocontroller (PIC) erkannt wird. Mein Ziel ist es, mit Matlab die Register eines DAC zu beschreiben bzw. diesen zu steuern. Der Dataflow sieht ca. so aus: PC -> USB Kabel -> PIC/Microcontroller -> DAC Danke!
>Wie schon gesagt es geht mir nicht darum ob ich das einfach so mit C >machen könnte sonder ob die Möglichkeit besteht Simulink dazu zu >verwenden. Welche µController würden sich besser dafür eignen ? Es kommt eben drauf an, wie viel Rechenaufwand für die betreffende Regelung nötig ist. Auch ein 8Biter kann da schon einiges leisten. (Und ein 16Biter muss nicht unbedingt schneller sein).
Seit knapp 9 Jahren arbeite ich mit Matlab/Simulink/Stateflow in Verbindung mit dem Real-Time Workshop Embedded Coder. Simulink ist meiner Einschätzung nach genau eine Abstraktionebene höher als die Funktionsentwicklung auf ANSI-C-Nievau im AVR-Studio. Wozu ist Simulin/Stateflow gut. Nun, versucht doch einmal drei parallel arbeitende Zustandsautomaten, die von einander gegenseitig abhängig sind, in C zu programmieren. Allein die prozedurale Anordnung des Codes ist schon ein Übersichtskiller. In Stateflow ist jede Automat für sich schön auf einer Fläche angeordnet und je nach dem, wie blöd man sich anstellt, auch entsprechend übersichtlich. Ich denke, dass ML/SL/SF - Code durchaus auf einem AVR Sinn macht. Ich habe mich jetzt die letzen 2 Jahre so nebenbei in meiner Freizeit durch den RTW und RTW/EC durchgearbeitet. Ich habe dabei viel Nützliches und viel Überflüssiges zur Kenntnis nehmen müssen. Aber so ziemlich am Ende des RTW /EC (in der Product Help) steht relativ gut beschrieben, wie man ein eigenes Target einbindet. Und wer mit einer Zeitscheibe zufrieden ist, wird auch deutlich schneller als in 2 Jahren zum Ziel kommen. Andererseits bringt ein solides Basiswissen stets ein großes Maß an Kompetenz, wenn mal der Kunde wieder etwas ausgefallenes haben möchte. Also ich habe jetzt eine Toolkette (Targetimplementierung) für den AVR(mega) erstellt. Die kleineren sind für mich sinnlos, weil unter 1k RAM ist der Compiler schnell am Ende. Aber mit dem atmega128x oder atmega256x macht das richtig Spaß. Das Hauptproblem ist, wie Peter schon sagte, das man Matlab zwar den ANSI-C- Funktionscode erstellt. Aber dann sitzt man da mit seinen External IN-and Outputs und muß zu sehen, wie die Ports klappern. Hier habe ich mir im Laufe der Zeit diverse Treiber für die Dinge, die mir wichtig waren, geschrieben. Die Treiber sind alle vollständig multitasking-fähig, weil delay-Loop für mich ein NO GO sind. Aufgrund dieser Fähigkeit, kann ich diverse Treiber parallel so betreiben, dass kein Device das andere behindert. Das ist für ML-SL-Funktionscode ein absolutes muß, weil die Modelle die Modellberechnungsfrequenz vorgeben. Ferner habe ich mir einen primitiven - aber sehr flexibelen Scheduler geschrieben, der die Quarztaktrate und die Abtastraten des Modells umsetzt. Darüber hinaus habe ich für die Externen Ein-und Ausgänge (Globale Variablen) Auswahl - GUIs erstellt, anhand derer ich die mir zur Verfügung stehenden Peripherien mit den Modellsignalen verbinde. Dieses geschieht während der Codegenerierung im Target Language Compiler. Die Programmierung des TLCs ist sehr stupide und unkomfortabel. Mit einer entsprechenden Strategie ist es einigermassen beherrschbar. Mittlerweile arbeitet meine Toolkette mit dem Mega 16- 128, 12xx, 25xx und atcanxxx recht zuverlässig. Die GUI-Dialogfenster blockieren die Auswahl bereits ausgewählter Schnittstellen und weist auf Abhängigkeiten hin. Warum habe ich das gemacht? Ich stehe ständig vor der Frage, wie eine Funktikons-Idee schnell mal umgesetzt werden soll. Nicht jeder hat das Kleingeld für eine Micro-Autobox von dSPACE oder alle die anderen mehrere K€ teuren Rapid-Prototyping-Tools. Und genau hier staunen viele, was so ein kleiner 8-Bitter so alles kann. Dabei darf man schon erwähnen, dass die Mega-Programmcode-Architektur 16-Bit breit ist. Im Screenshot umgesetzt habe ich die Digitalen Eingänge (I/O), den Dallas Temperatursensor DS18(B)20 und das LC-Display eDIP204 von Electronic Assembly (SPI-Schnittstelle). In Vorbereitung habe ich das VC8x0 von Conrad (ist schon etwas angestaubt), der SHT11 von Sensirion, den CAN-Treiber des atcanxxx, den MCP2515 (I/O) und das Grafikdisplay EDIP320TP. Bei dem Grafikdisplay sollen die Touch-Tasten als Modelltriggereingänge umgesetzt werden. Die Treiberimplementierung berücksichtigt dabei die HW-Trennung. Denn der nächste Schritt ist die Treibernutzung auf dem AVR32 umzusetzen. Ich gebe natürlich zu, dass ich mich so ein wenig vom AVR32-Framework habe inspirieren lassen. Mein Ziel ist es, dass Matlab nur durch Veränderung der Targeteinstellung alle notwendigen Anpassungen durchführt. Eine Implementierung eines Treibers soll durch diese Organisation relativ schnell auf allen anderen Plattformen genutzt werden können. Zurück zur Toolkette: Das dip204-Display wird vom Mega mit ca 10 Aktualisierungen pro Sekunde getrieben. Wenn ich die Busy-Erkennung noch aktiviere, ist bestimmt noch mehr drin. Aber für meine Verhältnisse reicht es und ich muss Prioritäten setzen. Die schnellste Taskscheibe ist eine 1ms. Der Build startet die Codegenerierung des Modell und der Basis-SW (Scheduler und HW-Treiber). Nach der Codegenerierung startet der Build automatisch. Wenn ein Programmer angeschlossen ist, würde die Toolkette auch die Software auf den Microkontroller programmieren. Ein Klick und gut ist. So sollte es sein. Man kann auch den GNU-Debugger automatisch nach dem Build starten. Aber wenn ich Fehler suchen muß, nehme ich ohnehin das Studio. Und weil nur debuggfähige Controller zeitlich sinnvoll zu supporten sind, fällt der ATMega8 bei mir aus dem Fokus. Mein Fazit: Ja, man kann die AVR - 16/8-Bitter sinnvoll in Matlab einbinden. Es macht auch richtig Spaß und die Begeisterung wächst zunehmends. Mein Tip an die Redaktion: Vielleicht sollte für Embedded-Matlab mal ein eigener Thread aufgemacht werden. Das Thema ist so vielfältig und spannend ! So, ich wünsche Euch viel Spaß auf euren eigenen Matlab-Abenteuern. Und dran bleiben sonst wirds nix ... (Ein Sorry an die Redaktion: das erste BIld als png wären 509kB anstatt 130 kB groß gewesen)
> Dabei darf man schon erwähnen, > dass die Mega-Programmcode-Architektur 16-Bit breit ist. ... >Ja, man kann die AVR - 16/8-Bitter ... ... Die Angabe der Bit-Breite einer CPU richtet sich hauptsächlich an die Registerbreite und ggfs der Breite des (Daten)Bussystems (Innerhalb/Ausserhalb) des ICs, aber nie nach der Breite des OP-Codes. Denn Die ist eigentlich immer grösser, weil sonst fast kein Befehlssatz möglich ist.
Hallo, ich arbeit auf ein kelein Projekt,und zwar ich soll ein µc Piccolo F2808 programiern nir mit Simulink(codegenerierung). wie in dem Bild zeigt, nur die Blöcke. wer kenne diese Thema , bitte ich brauch hilfe von euch /wie kann ich ADC Blöcke einstellen und die wert einlesen! /was ist fixdpoint /wie kann ich die variable andern bei Code Compose studie5 bzw Simulink auf ihre Hilfe wäre sehr dankbar
cskulkw schrieb: > > Warum habe ich das gemacht? Ich stehe ständig vor der Frage, wie eine > Funktikons-Idee schnell mal umgesetzt werden soll. Nicht jeder hat das > Kleingeld für eine Micro-Autobox von dSPACE oder alle die anderen > mehrere K€ teuren Rapid-Prototyping-Tools. Und genau hier staunen viele, > was so ein kleiner 8-Bitter so alles kann. Dabei darf man schon > erwähnen, dass die Mega-Programmcode-Architektur 16-Bit breit ist. Hallo, gibt es eine Möglichkeit den Nutzer "cskulkw" zu diesem Thema zu kontaktieren? Er hat genau das umgesetzt was ich suche. Danke
Bitte 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.