----- Original Message ----- From: Scott Dattalo To: Sent: Saturday, August 10, 2002 3:28 PM Subject: Re: [PIC]: Is MPLAB Junk? > 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. > Hi Scott, Thanks for the input regarding gpsim. We have a competing system which unlike gpsim is not free (although it is heavily discounted for students and hobbyists). It is part of a larger case tool called ZMech. Like you we found that we could easily simulate a fast PIC running at full speed on a modest PC. Although gpsim looks like a great free tool I think our tool has its own merits. For instance our products use our own graphics libraries which are multiplatform. They offer great performance increases over the standard MS Windows GUI and X11 (X windows system) on Linux. The libraries are designed for embedded realtime systems use and consequently can even run on an MSDOS system (386 or higher). Our scripting facilities also seem totally different to yours. We can embed high level simulation statements directly in the assembler source. It's kind of like putting debug code into your basic or C program. But it doesn't stop there. Our high level simulation statements allow you to keep track of complex sequences of events, conditionally execute simulation code, read from or write to files, interact with other background tasks, popup dialogs and request user input or even interact with physical hardware. Like gpsim we also allow users to write and attach their own modules and hardware mimics to a simulated system but we go a step further by allowing the user to connect components using virtual wire. Regards Sergio Masci http://www.xcprod.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads