Moin, ich habe mal die Tage bei github einen frischen OpenSource-Branch des "Masocisten" hochgeladen. Ist sowohl für HDL-Spezis wie auch für uC-Hacker was dabei: https://github.com/hackfin/MaSoCist Die groben Details, was das Ding tut: - msp430 kompatiblen neo430-Kern interaktiv simulieren (Docker demo) - Verschiedene SoC Konfigurationen (CPU-Kern, Peripherie) verwalten - VHDL-Hardware-Designs, C-Header und Dokumentation automatisch bauen - Komplette CPU und Peripherie zyklengenau virtualisieren und debuggen, z.B. wie hier: https://youtu.be/vIELshvKB_A Da eine Menge Tools nötig sind, habe ich das ganze in einen Docker-Container gepackt, die Anleitung findet sich im README.md (die Doku ist bisher nur Englisch, in der Annahme, dass das jeder kann). Wenn nix schiefgeht, wird die CPU und das Programm gebaut, und man kann per Terminal (minicom) mit dem virtuellen UART der neo430 quatschen. Da immer alles frisch ausgecheckt und gebaut wird, kann es auch mal sein, dass es nicht hinhaut. Vielleicht hat ja jemand Lust, sich mit der CI zu beschäftigen :-) Grüsse, - Strubi
Martin S. schrieb: > Da immer alles frisch ausgecheckt und gebaut wird, kann es auch mal > sein, dass es nicht hinhaut. Vielleicht lernst du erst einmal, wie man ein Versionsverwaltungssystem richtig benutzt?
c-hater schrieb: > Martin S. schrieb: > >> Da immer alles frisch ausgecheckt und gebaut wird, kann es auch mal >> sein, dass es nicht hinhaut. > > Vielleicht lernst du erst einmal, wie man ein Versionsverwaltungssystem > richtig benutzt? Normalerweise antworte ich auf kein Hater-Geunke. Der Vollständigkeit halber, für diejenigen, die auch Ahnung davon haben: Es sind third-party Git-Submodule dabei, wer es will, kann für sich eine fixe Revision auschecken. Meine CI-Strategie will das nicht.
Angeschaut und nicht gecheckt. Komme nicht damit klar. Warum nur ist es so schwer, einmal eine klare Anleitung zu liefern, WAS das ist WOFÜR es gedacht ist WAS man braucht? WIE man es laden muss? WIE man es erzeugt? WIE man es benutzt? Wenn ich so eine DOku zu einem gelieferten System abgeben würde, bekäme ich weder Geld noch einen weiteren Auftrag.
Wenn du damit nicht klar kommst liegt das eher an dir als an dem Projekt, das Projekt ist doch wahrlich hinreichend dokumentiert. Wenn du jemanden zum Haendchen halten brauchst musst du halt bezahlen ... Ich persoenlich halte nicht viel von solchen 'Lockvogelangeboten' bei denen bei Gefallen bzw kommerzieller Verwendung Geld abgedrueckt werden muss, aber mangelnde Dokumentation kann man hier wahrlich nicht vorwerfen.
Habe es mal ueber die tage ausprobiert. ok, nicht tiefer damit beschaeftigt aber hat auf anhieb geklappt in docker, laeuft nur sehr langsam. @elektrowagi78: verstehe dein problem nicht, dir ist schon klar was open source bedeutet? Und was isr daran lockvogel angebot? habe bisher kein catch gefunden. man kann das design frei verwenden solange man sich an die licensen haelt.
> ... dir ist schon klar was open source bedeutet?
Das weiß doch jeder. Kostet nichts - taugt nichts.
M. W. schrieb: > WAS das ist Eine Art von Spielzeug. > WOFÜR es gedacht ist Zum Spielen. > WAS man braucht? Linux. Und diverse Eval-Boards. > WIE man es laden muss? Von Linux auf ein spezielles Evalboard. > WIE man es erzeugt? Mit den Tools von Xilinx, oder Lattice, oder mit Synplify pro. Vermutlich. > WIE man es benutzt? Von BENUTZEN ist hier nicht die Rede. Es ist wirklich nur ein sehr spezielles Spielzeug für einen eher kleinen Kreis von Leuten, die in exakt DIESER Materie bereits drinstehen und alle Zutaten bereits haben. Zitat: The MaSoCist distribution enables you to quickly design, maintain, document and automatically create a family of Soft core featured System on Chip solutions on various FPGA architectures. It is relying heavily on the Linux kernel config utility and the section5 device description XML language. note: The full MaSoCist development environment is supported for Unix operating systems only Das Projekt hat als Dokumentation einige XML-Dateien. Dort werden über diverse Details Bemerkungen gemacht, die als notwendig erachtet wurden. Das, was als Einführung dient, hab ich oben zitiert. Wahrscheinlich wäre es doch besser gewesen, am Anfang mal ganz klar eine Ansage zu treffen. So in dem Stil: "Dieses Projekt richtet sich an erfahrene Ingenieure mit gründlichen Kenntnissen von: (hier die Liste der notwendigen Vorbedingungen hinein) und es beinhaltet die Simulation einer MSP430-artigen Architektur auf diversen Eval-Boards von (hier die Liste rein), zu dem Zwecke, daß man über eine serielle Verbindung zwischen Linux-PC und Evalboard mit dem Quasi-MSP430 kommunizieren kann." W.S.
Scheint ja das grosse Rätselraten ausgebrochen zu sein. Leider ist auch der Herr W.S. komplett auf dem Holzweg, ein Spielzeug ist es wahrlich nicht, wie einige Referenzdesigns wie z.B. eine MJPEG-Streaming-Kamera demonstrieren dürften. Was es ist, und wie man es benutzt ist m.E. hinreichend dokumentiert. Erwarte natürlich, dass die User mit Docker und gängigen Basics vertraut sind und "read the source" praktizieren. Und ja, es gelten Opensource-Prinzipien. Ich komme mit der Offenlegung a priori den entsprechenden Verpflichtungen (auch in Bezug auf den 'third party' neo430) nach, dazu kommt die Motivation, dass das System einer gegenüber den üblichen QSys/Vivado (u.a. Klickitools) gesteigerten Nachhaltigkeit genügen soll, d.h. so ein SoC auch noch in 10 Jahren für verschiedene Architekturen generierbar ist. Gab mal so'n Sprichwort: Nem geschenkten Gaul schaut man nicht ins Maul. In dem Sinne: Wenn ihr maulen/spielen wollt, gibt es genügend andere, weniger komplexe Projekte.
W.S. schrieb: > "Dieses Projekt richtet sich an erfahrene Ingenieure mit gründlichen > Kenntnissen von: > (hier die Liste der notwendigen Vorbedingungen hinein) > und es beinhaltet die Simulation einer MSP430-artigen Architektur auf > diversen Eval-Boards von (hier die Liste rein), zu dem Zwecke, daß man > über eine serielle Verbindung zwischen Linux-PC und Evalboard mit dem > Quasi-MSP430 kommunizieren kann." Das ist mal ein vernüftiger Satz, an dem einer erkennen kann, was man damit anfangen kann. Nochmal an den Kritiker da oben: Mein berechtigter Einwand ist der, dass man erwarten kann, dass man am Anschauen der Packung weiss, was drin ist und nicht erst eine SW installieren muss, um überhaupt zu kapieren, wozu sie gedacht ist und für wen. Aber das scheint für die U30-Fraktion unserer Kollegen (oder der Möchtegernkollegen) zuviel zu sein.
M. W. schrieb: > Aber das scheint für die U30-Fraktion unserer Kollegen (oder der > Möchtegernkollegen) zuviel zu sein. Ich glaub Strubi gehört schon zur Ü30-Fraktion. Das eigentliche Problem sehe ich aber auch bei mir selber: Man steckt so tief drin, das man gar nicht auf die Idee kommt, beim Urschleim mit Erklärungen anzufangen. Mir haben die Worte SoC, HDL und der Name des Autors schon genügt, um das Projekt einzuordnen. Ich bin da aber auch schon vorbelastet...
Hallo Martin, eine gutes GitHUB Projekt erkennt man gleich auf der Hauptseite am Readme.md Wenn es dort gut dokumentiert ist, findet man auch Anhänger und Mitstreiter. Als Template eignet sich der Aufbau mit folgenden Überschriften: What - Was ist das Projekt Why - Für was ist das Projekt gut - wofür kann man es verwenden - was zeichnet diese Projekt gegenüber ähnlichen aus How - was muss man konfigurieren - wie kann man es installieren - wie kann man kompilieren - Wie kann man das Projekt verwenden Ich denke, es steht jedem Open-Source Programmierer gut an, wenn er diese Fragen klar, kurz und prägnant beantworten kann. Es gibt zu viele Open-Source-Projekt und man blättert schnell weiter, wenn es nicht ersichtlich wird, um was es sich da dreht.
Tim schrieb: > Das eigentliche Problem sehe ich aber auch bei mir selber: Man steckt so > tief drin, das man gar nicht auf die Idee kommt, beim Urschleim mit > Erklärungen anzufangen. Es ist eine Frage der Selbstdisziplin, mit der es offenbar vielerorts mangelt. Ich hab mal vor langer Zeit ein gutes Wort dazu gehört und das geht sinngemäß so: Schreibe eine Dokumentation zu deinem Projekt in einem Format, das jeder lesen und ausdrucken kann. Bedenke dabei, daß andere Leute auch andere Systeme haben. Schreibe deine Dokumentation so, als ob du sie für einen alten Advokaten schriebest. Der kann logisch denken und er hat einen wachen und messerscharfen Verstand und er lernt alles, was du ihm richtig und logisch erklärst sofort. Aber er hat keinerlei Kenntnis von deinem Projekt. Und er hat Jura studiert und nicht dein Fach. Deshalb mußt du ihm alles, was du in deiner Dokumentation verwendest und was über den gewöhnlichen Schulstoff hinausgeht, erklären, BEVOR du es im Text verwendest. Du mußt in deiner Dokumentation deswegen systematisch sein und immer auch logisch, denn einen Logikfehler oder eine Auslassung oder Unsauberkeit wird er sofort merken. W.S.
Christoph M. schrieb: > eine gutes GitHUB Projekt erkennt man gleich auf der Hauptseite am > Readme.md Ja, lasse ich so stehen! Und jetzt lesen wir mal diese readmes, sofern vorhanden.
RTFM... Das kennt man doch, und meist ist es RTMM... ''Read the missing manual!'' ^^ Den Lötern unter Euch, die sich mal in Software reinbasteln wollen, geht es wie uns Codern, die mal nen IC aufs Breadboard stecken möchten... Hä? ^^ Wenn ich Code für Embedded Zeug sehe, denke ich mir meistens... Wo haben die geschlafen diese Nacht? Hingerotzt, keinerlei Knigge in Sachen Code beachtet, Hauptsache, die Bits flippen, und wenns kracht, gibts irgendwann ein Update, auf dass es woanders kracht, wo es nicht so weh tut. Hauptsache, der Kunde ist erstmal begeistert und zahlt. Wenn ich den Lötkolben schwinge, kommt auch was dabei raus, entweder, es funktioniert oder auch nicht. Oszi und Spice zeigen Fehler auf, die ich selbst nicht direkt kapiere. Tools wie ReSharper zeigen Fehler auf, die manche von euch nicht kapieren. Volt, Ampere, Watt, Farad, Henry, das ist für die Löter Brot und Butter, quasi wie void*, malloc() und free() für C-Coder: Wenn man das nicht versteht, wird's nix mit dem Projekt. Erkläre deiner Mutter, wie ein JFET funktioniert, dann erkläre ich meiner, was funktionaler Code ist ;)
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.