> 1. Some feedback when you are running with unbuilt code.
>
> 2. support for 3rd party programmers, esp. the direct from
> parallel port kind.
>
> 3. make stopwatch less obtrusive - put it in status bar???
>
> 4. some way to interface a program to create a stimulus file on the fly.
> Incorporating Visual Basic would be easy. Listening at a TCP/IP
> socket would be quite general. ODBC would be perverse but would
> work - CORBA?? RMI??? ActiveX???  Something??????
>
> For example, I'm using an external serial EEPROM that the
> chip reads and writes. What a pain to have to anticipate exactly
> when the EEPROM will provide data. Writing code to simulate the
> device would be fairly simple.
>
>
>
> --
> Anniepoo
> Need loco motors?
> http://www.idiom.com/~anniepoo/depot/motors.html
>

>and forces me to do most of my debugging in-circuit.
>
>> 4. some way to interface a program to create a stimulus file on the fly.
>> Incorporating Visual Basic would be easy. Listening at a TCP/IP
>> socket would be quite general. ODBC would be perverse but would
>> work - CORBA?? RMI??? ActiveX???  Something??????
>
>I'd like to have a few simulated LEDs, or better strip chart, for viewing the
>state of the pins.  A $12k logic analyzer seems a suitable replacement for
>this, but takes longer to hook up.
>
>> For example, I'm using an external serial EEPROM that the
>> chip reads and writes. What a pain to have to anticipate exactly
>> when the EEPROM will provide data. Writing code to simulate the
>> device would be fairly simple.
>
>Jon Doran
>
>

> I liked the idea of "LEDs" assignable to a port to give a quick visual of
>  what's going on. - Any chance of adding this as a new window/panel - along
>  the lines of the ext. async stimulus panel? (or am I just lazy? - my
>  hex-binary  converter is getting old and tired!)
>
>  Say -   RED =   Active High
>                  Green = Active Low
>                  Blue    = High Z - Input State
>
>
>  Richard
>

>
> [snip]
> > > 2. support for 3rd party programmers, esp. the direct from
> > > parallel port kind.
> > This is a possibility.  Whoever makes these, contact me at
> > @spam@darrel.johansenKILLspammicrochip.com and we can discuss.  I know
> > the PICSTART Plus interface has been hacked --with that data,
> > just about anyone could hook into the interface.
> [snip]
>
> most(all?) parallel port programmers are based on AN589 with some
> variations:
>
> inverters instead of buffers (so you would need the option to be able to set
> normal or inverted outputs.
>
> different lines used for outputs and inputs, a nice example of what
> parameters you would need and how to present this to the user is written by
> Nigel Goodwin "wpicprog" that you can download from
> http://www.lpilsley.demon.co.uk/programs.htm
>
> Peter van Hoof

> Peter van Hoof wrote:
> >
> > [snip]
> > > > 2. support for 3rd party programmers, esp. the direct from
> > > > parallel port kind.
> > > This is a possibility.  Whoever makes these, contact me at
> > > RemoveMEdarrel.johansenTakeThisOuTmicrochip.com and we can discuss.  I know
> > > the PICSTART Plus interface has been hacked --with that data,
> > > just about anyone could hook into the interface.
> > [snip]
> >
> > most(all?) parallel port programmers are based on AN589 with some
> > variations:
> >
> > inverters instead of buffers (so you would need the option to be able

> > Nigel Goodwin "wpicprog" that you can download from
> > http://www.lpilsley.demon.co.uk/programs.htm
> >
> > Peter van Hoof
>
> Just as an aside, this is going to be pretty hard for some programmers
> (Example:  The Needham's EMP-20 here), I suspect it doesn't use anything
> like the example you mention <G>  Some others (The Parallax unit here)
> are pretty do-able (though easy enough to move to a serial port based
> unit.)
>
>   Mark

> I liked the idea of "LEDs" assignable to a port to give a quick visual of
> what's going on. - Any chance of adding this as a new window/panel - along
> the lines of the ext. async stimulus panel? (or am I just lazy? - my
> hex-binary  converter is getting old and tired!)
>
> Say -   RED =   Active High
>                 Green = Active Low
>                 Blue    = High Z - Input State
>
>
> Richard
>

> For instance, by adding an ActiveX interface for the stimulus input you
> could use the existing stimulus systems, write a script to provide stimulus
> (in any scripting language M$ supports (they've got a real nice extensible
> scripting engine with M$ support for VBScript and Javascript and 3rd party
> support for many others such as PerlScriptibly M$ Perl in Win 2000),
> CobolScript and anything else people want to implement)) or write a full
> blown ActiveX DLL (in VB, VC, Borland C, Delphi , anything else with
> ActiveX).
>

> Add an interface for output and you can write custom ActiveX interface to
> simulate the real devices interface.

> Add an identical interface to the ICD
> code, write a simple protocol and add a few debugging macros to MPLAB and
> you can use the same ActiveX controls while debugging. This canb then be the
> basis of the final products PC interface. Hence, you design one ActiveX
> interface and you can use it in simulation, debugging and production.
>


> Also, by adding an activeX interface for the programming you could plug in
> your own ActiveX components for handling other components.
>
> Obviously ActiveX enabling the whole thing would be #$%$ing fantastic (at
> least for developers). However, it might not be so fun for the MChip
> developers I would say.
>

> Also,
> > All this talk about wanted features from MPLAB makes me wanna whip out VB
> and
> > write an application. A lot of this can be accomplished using DDE...I'd be
> >willing to take a crack at implementing these features. Any ideas?
> > Tim Hamel
>
> Don't know about how possible it'd be with DDE. MChip'd have to have a
> pretty complex DDE interface wouldn't they (DDE was a bit before my time so
> I'm not really sure). Looking at Universal MicroProcessor Simulator got me
> thinking about writing an ActiveX enabled simulator. UMPS is great but the
> interface could do with a revamp and the ability to add your own components
> via ActiveX would be great (I think UMPS can do this but it doesn't appear
> well documented and they must be C/C++ DLLs). The only problem with ActiveX
> is that you cut out non M$ platforms basically (unless you want to write
> ActiveX for Unix). A better idea would be to write it in Java. Due to M$s
> seamless JavaBean<->ActiveX integration you could use JavaBeans or ActiveX
> for the addins with no problems. You might have some speed problems but it'd
> be cross platform. Also, you could take advantage of the current trend
> towards embedded Java.
>

> Everything's done with messages in Windows, basically;  You send a
> message to the File Register Window, telling it to change subwindow RA
> to 0x49 (or whatever), IIRC you can intercept those messages, but it's
> hard to do so without being part of that application (I'd have to go
> look to be sure, it'd be easiest if Microchip did this as this sort of
> thing's always simple with source code access & a *bear* without that.)
>
> For Microchip to create a customizable LED-ized Register window would be
> not too horrible, I'd think, and hiding windows is certainly simple
> enough for those who don't use that window <G>  Not that hard to wrap
> our brains around reading hex, either, though.
>
>   Mark
>
> Jim Hartmann wrote:
> >
> >        Any windows programmers out there know if it is possible to
> >        capture window repaint data?  If it is then repaints to the
> >        File Register window or Special Function Register could be
> >        intercepted and made to do something useful like light up
> >        simulated LED's or what have you.
> >
> >        -Jim

> Date: Wed, 4 Aug 1999 20:00:24 -0400
> From: Bob Drzyzgula <EraseMEpicdrzyzgula.org>
> To: RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU
> Subject: Re: MPLAB desires
>
> On Wed, Aug 04, 1999 at 02:42:10PM -0700, Anne Ogborn wrote:
>
> > 4. some way to interface a program to create a stimulus file on the fly.
> > Incorporating Visual Basic would be easy. Listening at a TCP/IP
> > socket would be quite general. ODBC would be perverse but would
> > work - CORBA?? RMI??? ActiveX???  Something??????
>
> To include VBA would require a reasonably hefty
> ISV license fee payable to M$, I believe, and
> could potentially threaten the free status of
> MPLAB. CORBA is more likely in that it is possible
> to implement the CORBA architecture without
> paying through the nose, in fact there are several
> free implementations available (although I don't
> know how many of them are available for Windows).
>
> Were they to take the CORBA route (not that I'm
> holding my breath) it would be incredibly cool
> if they were to work with Scott D. et. al. to
> come up with a unified interface that would
> allow stimulus generators that could be used with
> either the Microchip or the gpsim simulators. I
> mean, it isn't like Microchip makes any money
> off of Mplab that wouldn't also be made off an
> alternative IDE. Daydreaming, however, is
> way too easy.

>Scott Dattalo wrote:
>
>> But back to Annie's original suggestion: dynamically modifiable stimuli. I
>> think that'd be a really cool thing to have in a simulator. We had
>> discussions about this subject on the GNUPIC mailing list a while back.
>> Some of the uses mentioned were things like UART and A/D modules. Some one
>> even suggested that the PC's parallel port could act like a pic I/O port!
>> The possibilities are endless. Unfortunately, so are the details...
>
>PicNPoke's Real World Interface provides complete working 16F84 IO ports
>controlled by both simulators. Only good for beginner experimenting
>unless you've got plenty of time, but the principle works ok. It
>supports interrupts, pullups, TMR0 input etc. It's even got an A2D
>input.
>
>--
>Best regards
>
>Tony
>
>"COMING SOON"
>A Parallax to PIC source code converter.
>
>http://www.picnpoke.com ???
>Email ???
>
>