Hallo Linuxer, gibt es eigentlich LTSpice auch für Linux (NICHT KDE)? Ich habe zwar von verschiedenen Firmen (Maxim, Analog, Linear, National, ...) Simulatoren unter WINE laufen, nur gehen die 8 GByte an Diskspace mir auf den senkel und auf meinem neuen 19" PanelPC laufen die Teile alle nicht mehr. Benötige eine Linux Version die auf einm ARM Cortex A9 läuft. Grüße Michelle
qemu erfordert aber ein ZUSÄTZLICHES Betriebssystem wie Windows®,
was dann noch mehr Speicherplatz beansprucht...
Was der Scheiß bei diesen Programmen ist, ist das sie alle vom
${HOME} über NFS laufen müssen.
Gibt es eigentlich keine kostengünstigen Simulatoren unter Linux?
Ich meine, es gibt simulatoren, nur bin ich nicht gerade bereit
>6000 Euro dafür auszugeben.
Grüße
Michelle
Michelle Konzack schrieb: > qemu erfordert aber ein ZUSÄTZLICHES Betriebssystem wie Windows®, > was dann noch mehr Speicherplatz beansprucht... Ja. Wobei man das für LTspice wohl relativ knapp halten kann. > Was der Scheiß bei diesen Programmen ist, ist das sie alle vom > ${HOME} über NFS laufen müssen. Huh? Was läuft über NFS? Das qemu? Nicht notwendig, das läuft natürlich auch auf einem lokalen Image. Das LTspice? Das wird gar nicht wissen, was ein NFS ist. > Gibt es eigentlich keine kostengünstigen Simulatoren unter Linux? Klassisches Berkeley-Spice in seiner Urform, sowie qucs. > Ich meine, es gibt simulatoren, nur bin ich nicht gerade bereit > >6000 Euro dafür auszugeben. Naja, LTspice ist ja auch in erster Linie als Werbeverkaufsveranstal- tung für LT konzipiert. Nur darum haben sie ja auch kein Interesse daran, den Sourcecode rauszugeben.
Michelle Konzack schrieb: > qemu erfordert aber ein ZUSÄTZLICHES Betriebssystem wie Windows®, Kannst ja auch im qemu ein x86-Linux mit einem LTSpice über wine laufen lassen. ;-) P.S.: Es gibt ngspice und eine Menge anderes Zeug, ist aber was 'anderes' als LTSpice oder PSpice und ich glaube du musst dir die GUI für ngspice noch heraussuchen.
Das mit dem qucs funktioniert bei mir nicht richtig. Liegt warscheinlich daran, das es noch nicht fertig programmiert ist... Achja, meine alte i386er Workstation hat nur 4 GByte Flashdisk und die neue ist eben eine Marvel Armada 300 was eben ein ARM A9 ist aber wesentlich schneller als der Athlon XP 3000+. :-D Hmmm, ngspice ist also mit Version 20 in non-free von Debian. Mal sehn, was man damit anfangen kann... Grüße Michelle
Die Wine-Leute wollen? wollten? einen Wine für Arm mit dem qemu so verkoppeln, dass der Maschinencode aus dem .EXE vom qemu ausgeführt wird, aber alle syscalls, dll-aufrufe soweit im source vorhanden, gdi ... auf nativen ARM-Code zurückgreifen. => viel mehr Performance als alles im qemu laufen zu lassen, vor allem bei GUI-Lastigen Anwendungen. Google findet dazu: http://wiki.winehq.org/ARM
Grmpf!
Paket gspiceui
* squeeze (stable) (electronics): Eine grafische Oberfläche
für Gnucap und NGSpice
0.9.98.dfsg-1: amd64 armel i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc s390 sparc
paßt schon, nur...
Paket ngspice
* squeeze (stable) (electronics): A Spice circuit simulator
[non-free]
20-1: i386
Nur i386! Unter testing und unstable noch für amd64.
Mal sehn, ob sich da was machen läßt. Sourcen sind ja jedenfals da
und zum compilieren ist eine Kiste tauglich.
Grüße
Michelle
Früher oder später kommt man um Windows-Software sowieso nicht rum. Und wine ist eine viel zu feinziselierte Angelegenheit - eine Änderung ungeachtet auf welcher Seite und nichts geht mehr. Meine Lösung: eine virtuelle Maschine ohne Internet und per rdesktop vom X drauf. Hypervisor kann ja auch unter Linux laufen, damit nicht mal was am eigentlichen System geändert werden muss.
Εrnst B✶ schrieb: > Die Wine-Leute wollen? wollten? einen Wine für Arm mit dem qemu so > verkoppeln, dass der Maschinencode aus dem .EXE vom qemu ausgeführt > wird, aber alle syscalls, dll-aufrufe soweit im source vorhanden, gdi > ... auf nativen ARM-Code zurückgreifen. > > => viel mehr Performance als alles im qemu laufen zu lassen, vor allem > bei GUI-Lastigen Anwendungen. > > Google findet dazu: > http://wiki.winehq.org/ARM Das hört sich interessant an. Werde AndreHentschel mal kontaktieren. Wenn WINE nun bereits auch für Sparc und PPC verfügbar ist... Gut, experimental, aber immerhin... ;-) Und wie er schrieb, ist es empfohlen native zu kompilieren. Danke für den Tip Michelle
Michael H. schrieb: > Meine Lösung: eine virtuelle Maschine Hypervisor für einen ARM? gibts da einen? Und dann braucht's ja trotzdem noch eine i386 CPU-Emulation... da kann man auch gleich direkt den qemu laufen lassen. Vielleicht wird's mit Windows8 auf ARM ja besser, und LT stellt ein echtes ARM-Binary zur Verfügung.
Michelle Konzack schrieb: > Das mit dem qucs funktioniert bei mir nicht richtig. Was denn genau nicht? Das Einzige, was mir dort gelegentlich passiert, ist der berüchtigte "Jacobian singular". Kann einen natürlich mit einem Berkeley-Spice nicht passieren, weil das keine Schrittweitenanpassung macht. ;-) Was bei qucs wirklich (größtenteils) miserabel ist ist die Doku. Michael H. schrieb: > Früher oder später kommt man um Windows-Software sowieso nicht rum. Unsinnige Behauptung. Wenn man nur will, kommt man da drumrum, und glaub' mir, das tut auch gar nicht weh. ;-) Im Übrigen ist Wine gerade für LTspice gewissermaßen der offizielle Weg. Sprich: der Autor bzw. seine Firma mag keine separate Linux- Version herausgeben, sondern empfiehlt stattdessen die Benutzung von Wine.
Jörg Wunsch schrieb: > Unsinnige Behauptung. Wenn man nur will, kommt man da drumrum Darüber lasse ich mit mir reden. >, und > glaub' mir, das tut auch gar nicht weh. ;-) Darüber eher nicht. Wenn ich mir heute ein Eval-Baord von irgendwem hole, dann ist da Windows-Software dabei. Sicher kann man sich das dann lauffähig frickeln. Aber die Zeit, die ich damit verbringe, kommt bei 2..3 Projekten sehr schnell an die Dauer für eine dumme aber lauffähige Windows-Installation. Εrnst B✶ schrieb: > Hypervisor für einen ARM? gibts da einen? Und dann braucht's ja trotzdem ??? Der Windows-Rechner kann sonstwas sein, du sitzt nur vor deinem X Terminal und bist der rdesktop auf dem Windows-Rechner. Die Verbindung kann auch nur ein DSL sein - das reicht.
Michael H. schrieb: > Wenn ich mir heute ein Eval-Baord von irgendwem hole, dann ist da > Windows-Software dabei. Dann hole ich mir eben kein Eval-Board von irgendwem :), sondern ich hole mir eins, mit dem ich hernach auch arbeiten will. Wenn Support für !Windows für den Hersteller des jeweiligen Systems kein Thema ist, dann prima, reduziert sich die Auswahl der Zielplattform aus der ohnehin unübersichtlichen Menge für mich gleich von vornherein. Ich muss doch schließlich nicht alles ausprobieren, was es auf der Welt gibt. Krempel, der bei einem Evalboard dabei ist, interessiert mich ohnehin nur selten. Ich will doch hinterher meine Probleme gelöst bekommen, und nicht die Probleme, die der Hersteller denkt, manche Leute haben könnten. Für jedes Produkt eine neue IDE brauch' ich sowieso nicht. Ich bin schon alt, da muss ich mich nicht für jeden an was anderes als den Emacs gewöhnen müssen, den ich seit 20 Jahren wenigstens so einigermaßen kenne. Auf diese Weise bin ich übrigens seinerzeit nach einem kurzen Besuch bei "PIC" zu "AVR" gekommen: ich wusste, dass es dafür einen GCC-Port gibt, das genügte mir für den Einstieg. 10 Jahre später kann ich resümieren, dass ich damit gut gefahren bin.
Den Luxus die Hardware nach der Betriebssystem-Unterstützung auszuwählen kann sich leider nicht jeder leisten; bei der Art von Anwendungen für die Controller wie AVRs üblicherweise verwendet werden geht das, bei vielen anderen nicht.
also für ngspice gibt es den quellcode, kannst du also selbst compilieren http://ngspice.sourceforge.net/
Hatte schon bei ettlichen Herstellern gesehen, das sie explizit darauf hinweisen, das die Simulatoren und so unter Ubuntu mit Wine laufen. Grüße Michelle
user schrieb: > also für ngspice gibt es den quellcode, kannst du also selbst > compilieren > http://ngspice.sourceforge.net/ Das Problem ist dass viele Modelle herstellerspezifische Spice-Features verwenden, und deshalb nicht mit den Open-Source-Versionen von Spice funktionieren. Spice ist ein Beispiel für ein Programm, dem eine GPL-Lizenzierung gut getan hätte.
Jörg Wunsch schrieb: > Support für !Windows für den Hersteller des jeweiligen Systems > kein Thema ist, dann prima, reduziert sich die Auswahl der > Zielplattform aus der ohnehin unübersichtlichen Menge für mich > gleich von vornherein. Ich muss doch schließlich nicht /alles/ > ausprobieren, was es auf der Welt gibt. Der Haken ist, dass du auch nicht alles ausprobieren könntest, weil du einen Großteil schon wegen felhendem OS-Support ausfilterst. Das wäre für mich keine Option. Es stellt sich natürlich die Frage nach der Ambition des Unterfangens. Privat kann man seinen Vorlieben sicherlich nachgehen. Aber beruflich wirst du mit einer Unix-Only Richtlinie sicher schlechter dastehen als ohne. Nachtrag: Wer als Embedded-Entwickler Windows-Only fährt, macht mit absoluter Sicherheit etwas verkehrt - ein Unix-OS ist naturbedingt die bessere Wahl.
Andreas Schwarz schrieb: > Spice ist ein Beispiel für ein Programm, dem eine GPL-Lizenzierung gut > getan hätte. Denke ich nicht. Dann hätten die Hersteller wohl andere Wege gefunden, sich ihr eigenes Süppchen zu kochen. Letztlich sind ja Dinge wie LTspice auch komplett from scratch geschrieben worden (so die Aussage des Entwicklers). Michael H. schrieb: > Aber beruflich wirst du mit einer Unix-Only Richtlinie sicher schlechter > dastehen als ohne. Naja, sagen wir, Windows-mostly. Wie in allen großen Unternehmen ist Windows ohnehin "corporate policy" (egal, wie viel es kostet, ich meine hier die vielbeschworene "total cost of ownership", die nach alldem, was ich da bei den Kollegen erlebe, alles andere als billig ist), aber ich hätte dort nicht angefangen, wenn ich nicht gewusst hätte, dass ich meinen lieben langen Tag nicht vor einem Windows verbringen muss. Aber privat will ich mir den Aufwand einfach nicht antun, sowas als produktives System pflegen zu müssen.
Jörg Wunsch schrieb: > ist), aber ich hätte dort nicht angefangen, wenn ich nicht gewusst > hätte, dass ich meinen lieben langen Tag nicht vor einem Windows > verbringen muss. Verstehe ich voll und ganz. > Aber privat will ich mir den Aufwand einfach nicht antun, sowas als > produktives System pflegen zu müssen. So war mein Ursprungs-Post auch nicht gemeint. Es ist praktisch, um schnell und unkompliziert etwas ausprobieren zu können. Wirklich damit in Vollzeit arbeiten würde ich auf keinen Fall wollen.
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.