Thomas Brandon wrote:
>
> There are two different technologies that could be used. To actually license
> the VBA engine would cost money (you'd have to speak to M$ personally for an
> exact price). This is the setup used in say Office where you effectively
> have a cut down version of VB embedded in your program. This would mean you
> could fully script MPLAB with no external programs. e.g. You could write a
> VBA procedure to use as stimulus at some point. This would be great for all
> those who know VBA. However, it wouldn't be so fun for the MChip developers.
> Unless there whole program is written as ActiveX components they would have
> to port it all. And somehow MPLAB doesn't look like it's all ActiveX.
>

I didn't know it was a requirement of a program to be all ActiveX to embed VBA,
but
whatever.

below is what I was driving at - most specificly, SOME (ActiveX isn't the only
possibility) interface.  And somebody claims DDE IS implemented.

> 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.

Strikes me these are the same - call my code to find out what's on the pins this
 clock cycle.
That's a stimulus file and that's 'real devices interface'.
I could even see a program that had most of the common things you'd want to have
 wired up,
and would let you wire to your PIC - serial EEPROMS, normal EEPROMS, external RA
M,
the Dallas chips, ISD's sound units - basicly anything with an SPI I2C etc proto
col
or likely to be wired to a PIC at some point. Presumably some graphic interface
to wire
it all up.

> 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.
>
Yes - but this seems to be impractical to do given reasonable budget. Yet a stim
ulus file
interface is fairly trivial.


> 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.
>

Yes - in an ideal world MPLAB would have a beanbox stimulus mode where you could
drop components (javabeans) and wire them up.  Indeed, there could be a
16F84 (or whatever) bean, so you could debug that mixed Atmel - PIC - ASIC board
without mucking about with solder.

> I'd certainly be willing to devote programming time to a Java based
> simulator.

While I'd love to see it, I can't imagine devoting the required time right now.
It's a non-trivial task.

--
Anniepoo
Need loco motors?
http://www.idiom.com/~anniepoo/depot/motors.html