Searching \ for 'MPLAB desires (or Is it wrong to dream?)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'MPLAB desires (or Is it wrong to dream?)'.

Truncated match.
PICList Thread
'MPLAB desires (or Is it wrong to dream?)'
1999\08\06@004407 by Thomas Brandon

picon face
Thanks for the advice on javax.comm. Implementing cross platform
serial/parallel support shouldn't be too hard. As you say, the problem will
be providing good NT support. The best thing about this is NT people can
write the native NT methods while some Mac programmer can do the Mac native

In regards to your last reply:
To incroporate the VBA runtime it isn't a requirement to be all ActiveX but
the VBA runtime would be an ActiveX component. Hence to interface with VBA
you need ActiveX code thus you need an ActiveX interface to all the working
of your program. That doesn't mean your program has to be ActiveX. You could
simply have an ActiveX interface that talks to all your existing C DLLs. But
I don't think you can avoid having an ActiveX interface somewhere along the
lines but of course this could be the ActiveX interface M$s VM automatically
creates for all Javabeans hence ActiveX programming isn't required, just the

An ActiveX interface is no more impractical than the current C interface.
But of course retrospectively converting their C interfaces to ActiveX is a
lot of work. But just an ActiveX (or Java) interface for the Stimuli stuff
would be great and not so impractical.

Obviously writing a full blown simulator of the level of say Protel or any
of the VHDL sim. tools is out of the question (although if you managed to
add support for say SPICE simulation most of the work would be done for
you). A simple simulator (anyone seen Electronics Workbench, nice simple
Analog/digital simulator. Not good for production level sims but good to
logically test a design if nothing else). So you start with a simple PIC
only simulator (you could of course try and use something like the gpsim
engine ported to Java) then you add support for hard coded stimuli. Then
code generated stimuli. Then support for linking to external stimuli (so you
have the PIC stuff done by the PC but all the other hardware as hardware).
Then support for simulation of components to produce stimuli. It'd still be
a big task. But if you start with an extensible base it will go as far as
you want it to go.

BTW: I'm not saying MChip *should* add an ActiveX interface. I'm sure
there'd be no complaints (at least from PC users) if they did. But they
won't because it's too expensive. Which is always the problem with software
development. You have to get your product to market ASAP but the sooner you
get it on the market the sooner it's outdated and the sooner it's underlying
architecture (e.g. C DLL, ActiveX DLLs, Java Beans) becomes obsolete.

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...