1. Home
  2. Electronics Design
  3. Spice's graphical interface for Linux...

Spice's graphical interface for Linux...

Hi guys. This is my second post on this group, and based in the nice answers I received before, I would like to ask you something.

For my pre-grade thesis I am finishing a program (SpiceX) for doing schematic capture in Linux, which is going to link automatically the graphical interface with the command line simulation core (so far Spice or Ngspice). The program is very understandable and it is very easy to be expanded by electronics users without knowledge about programming (xml based).

the pages are:

formatting link
formatting link

It is an attempt of integration of the several steps followed when designing a circuit, something like the great Schematics of Pspice (but opensource).

At my University they asked me what is the impact and potential of the program in the electronics community, and I argued all the things that I spoke when proposing the project. Nevertheless, I would like to have a stronger argument. That is why I ask your opinion about such kind of program, in that operating system, and after seen all the lost attempts in the past.

The differences between this program and the old attempts are, basically, the lenguage (C# - mono), strongly object oriented, the development process followed (RUP), and the focus on electronics users as potential mantainers.

Thank you very much for your words...

Franco.

Reply to
rmendoza79
Loading thread data ...

Check out

formatting link

and

formatting link 

--
Bill Sloman, Nijmegen
Reply to
bill.sloman

formatting link
$ snipped-for-privacy@dispatch.concentric.net

Reply to
JeffM

Hi guys, thanks for the answers.

I have checked these projects before, and they were part of the state of the art of my project.

I think gschem (and also xcircuit which is not part of gEDA group) is an application a little bit different to the one I proposed for two reasons:

1.- The schematic capture program leaves the responsability of linking the netlist generated with the simulation core to the user (gEDA does not look for the integration between the application, but just to deliver them all together in a single package). 2.- The language used to program the application makes difficult the future improvements and extensions (I also tried to keep evolution of the software on mind when developing the system - OOP paradigm, low coupling, high cohesion, etcetera. So the application can survive after my academic compromise).

Oregano is another attempt to provide almost the same functionality than SpiceX. Nevertheless, the language and the architecture of the program are bringing some troubles to the developers in this moment (they are evaluating to port the code to C# or Python, xor to stop the development of it).

The second group of programs has a very big difference: they are commercial. Maybe some of them are free, but they still not opensource (we cannot help to grow them) and they are constrained to the companies' decisions. One example of it, is the very nice application LTSpice (that was not on my mind when I begun the project), which can become private whenever they want and where you must include your own components if they belong to another producer (as I understand, and specially in the case of switched regulators chips). There are other issues that is very important for me and my region (sudamerica) as: the price and artifitial limitations.

The idea is to provide something free, easy to be maintained and evoluted, not attached to any private constraint, and with libraries easy to be expanded by the user.

Any comments?

Franco.

Reply to
Franco

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.