On Sat, 10 Aug 2002, Alex Holden wrote:

> Sergio Masci wrote:
>
> >>http://www.dattalo.com/gnupic/gpsim.html
> >>
> >Isn't gpsim a command line simulator i.e. GUI-less?
> >
> >
>
> No, if you go to the above site you'll see some rather out of date shots
> of the GTK+ based GUI. You can run it from the command line if you want
> though, which can be useful for batch mode simulations like Scott's
> automated SDCC regression test suite.

Alex, first of all, thanks for the gpsim plug.

Sergio,

The main reason I started gpsim was because MPSIM was so slow. I also
started gpsim so I could learn about software development under Linux.
That was 4 (or was it 5?) years ago. gpsim has matured. It now supports
the entire range of Microchip controllers except for the 17Cxx series.
Several individual controllers have not yet been added to gpsim, but
adding them amounts to writing some trivial configuration code. Over this
same time frame, I gather that MPSIM is still slow.

If you're interested in speed, then you'll love gpsim. It's fast -
extremely fast. On a typical 1GHz x86 machine, gpsim will simulate a
midrange PIC faster than real time. Depending on the program being
simulated, the effective clock is as high as 30Mhz. On a 2GHz machine I'd
expect this to double.

If you're interested in a command line interface only, then you'll love
gpsim. gpsim was originally structure as two pieces of code: the simulator
engine and the command line interface. The command line interface can also
be scripted. I use this extensively to perform regression tests with SDCC.

If you're interested in a gui interface, well again, you'll love gpsim.
After the CLI was written, I hacked a simple gui in. Ralf Forsberg took
this and really enhanced into a top notch interface. There are the common
things one would expect, like source level debugging and register viewers.
There are also the common things for which one would hope, like a stop
watch, symbol viewers, trace viewers. And then there are things that one
would never expect, like a graphical view of the microcontroller and a
schematic-type view of your simulation enviroment.

If you need to simulate your PIC as part of a system, you'll love gpsim.
gpsim supports a rather power stimulus interface where you can control the
behavior on any I/O pin. This interface also has extended into full-blown
modules. For example, you can add LED's, 7-Segment Displays, LCD's,
resistors, etc.

---------

I'm not a salesman. I'm an engineer. Just so you don't feel misleaded, let
me tell you some of the negative things about gpsim.

First, gpsim doesn't run on Windows. This makes it hard for new users of
gpsim. I spend quite a bit of time helping people straighten out their
Linux installation just so gpsim can run. In some cases, I encounter bugs
that I can't fix because I can't duplicate what others are experiencing.
The good news is that there are several people who now regularly use gpsim
and can offer advice and help on installation.

Second, while gpsim supports several of the internal peripherals, there
are many that are either only partially supported are not supported at
all. For example, the SPI module doesn't exist. Off the top of my head,
here are the ones that are supported: EEPROM, USART, Timer 0, Timer 1/2
capture compare/PWM, Port A (e.g. open collectors), Port B (e.g. interrupt
on change), Analog to Digital comparators, WDT, Sleep, and probably a few
others.

Third, while gpsim is powerful, it is also hard to use. There are numerous
features, but not all of them are intuitively obvious. Furthermore, the
documentation is lacking. This can be especially frustrating if you want
to create a special module. The good news is that you can support on the
GNUPIC mailing list.


Scott

PS. To answer the question in your subject line, No MPLAB is not junk.
Having developed a similar development enviroment, I have respect for
MPLAB.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads