From PICLIST@MITVMA.MIT.EDU Fri Nov 15 16:00:40 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id AAA82AF0144; Fri, 15 Nov 2002 16:00:40 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007DE10C@cherry.ease.lsoft.com>; Fri, 15 Nov 2002 18:46:24 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 1087 for PICLIST@MITVMA.MIT.EDU; Fri, 15 Nov 2002 18:46:14 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 4391; Fri, 15 Nov 2002 18:45:34 -0500 Received: from *unknown [209.66.107.17] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with SMTP ; Fri, 15 Nov 2002 18:45:33 EST X-Warning: mitvma.mit.edu: Host *unknown claimed to be brouhaha.com Received: (qmail 4812 invoked by uid 1032); 15 Nov 2002 23:45:24 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Nov 2002 23:45:24 -0000 X-X-Sender: sdattalo@ruckus.brouhaha.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 15 Nov 2002 15:45:24 -0800 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Scott Dattalo Subject: Re: [PIC]: Simulator software available To: PICLIST@MITVMA.MIT.EDU In-Reply-To: X-RCPT-TO: Status: R X-UIDL: 277600751 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 000007b3-0000 On Thu, 14 Nov 2002, Bill Couture wrote: > I though people on the list might be interested in some software I've > written. > > I started using PICs at work about a year and a half ago, and quickly > discovered that MPLAB's simulator just wasn't good enough (too slow, > no support for UART's etc). That was my reasoning - 5 years ago - for starting gpsim. > > So, being the computer geek I am, I wrote my own PIC simulators -- > a 12-bit core and a 14-bit core, currently implemented as a 12C509A, > a 16F84A, a 16F628, and a 16F877 (each in a separate program). > > The programs include support for hardware UARTS (628, 877), software > (bit-bang) UARTS (all), I2C EEPROM (bit-bang, all), toggle I/O pins > via keypress, visual state of I/O pins, oscilloscope functions, > execution history, stimulus files, ADC result files (877), breakpoint > on program address, breakpoint on RAM address, and more. > > They are fast, with a PIII-600 doing about 5MIPS simulating a 12C509A, > down to about 3MIPS simulating a 16F877. > > There are some minor limitations, the analog comparitors of the 628 have > not been implemented, and the MSSP and PSP of the 877 have not been > implemented. > > They are written as DOS programs, in C with some inline assembly, and are > open source. You can download executables, source, and compiler at > www.picemulator.com > > And, let me answer some of the "usual" questions: > > * Why not just use GNUPIC? > 1) I had been writing PICEMU for a month before I found out about > GNUPIC. > 2) I don't use Linux either at work or at home. > 3) I wouldn't be learning about PICs if I didn't write my own > program. > > * Why not add to GNUPIC instead of re-inventing everything? > 1) I'm not a C++ programmer, and not a Linux programmer. > > * Why is this a DOS program instead of a Windows program? > 1) I'm not a Windows programmer. > 2) I didn't think that PICEMU would wind up being anything like > the program it is, so I started writing it "quick and dirty" > using the C compiler I've been using since 1985. > > Please feel free to make comments, suggestions, and derisive remarks. :) Bill, I'm glad to see another Open Source Simulator for PICs. You may wish to post this to the gnupic mailing list too. Even if you don't care to merge your work with the GNUPIC project, I'm sure there is someone there who would be interested in either trying your version out or perhaps porting some feature of gpsim to picemu or vice-versa. Incidently, if you want to speed the execution up from 3Mips to 30Mips like gpsim then try statically decoding the source. Then create an array of pointers to the statically decoded instructions. The index into this array can be the program counter. Then you can do something like: while( no break point) { decode_instructions[program counter] -> decoded_instruction(); } I.e. call the decoded instructions through the pointers. -- Even if you don't wish to port to Linux or windows, you may want to consider using MinGW. It'll run under dos (or MSys). Regards, Scott -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.