Searching \ for 'MPLAB desires' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=mplab
Search entire site for: 'MPLAB desires'.

Truncated match.
PICList Thread
'MPLAB desires'
1999\08\04@174435 by Anne Ogborn

flavicon
face
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

1999\08\04@182139 by Matthew Fries

flavicon
face
Heck! As a PIC Newbie, I would be glad if the HELP in MPLAB were
implemented....



On Wed, 4 Aug 1999, Anne Ogborn wrote:

{Quote hidden}

1999\08\04@183009 by Jonathon Doran

picon face
<snip Anniepoo's suggestions>

I would kinda like the trace facility to work too :-)

Given that nobody else is complaining, it must be something I'm not
doing correctly.  I select a region (either with the mouse, or by selecting
the start and end points in the dialog).  There are "T"s in the program
memory window where I've selected tracing.  When I run the program all
I get in the trace buffer are NOPs.  Kinda defeats the purpose of a simulator,
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

1999\08\04@183631 by Dan Creagan

flavicon
face
>Heck! As a PIC Newbie, I would be glad if the HELP in MPLAB
were
>implemented....


My version (4.12) has help on all the major topics.  Like my
experience with most help files, it hasn't helped me yet. I
keep finding problems that I need to research elsewhere. But
I'm still glad it is there.

Dan

1999\08\04@183633 by John A. Craft

flavicon
face
Two Letters,, N T......

Picmaster NT support......................

Jc.

At 04:29 PM 8/4/99 -0600, you wrote:
><snip Anniepoo's suggestions>
>
>I would kinda like the trace facility to work too :-)
>
>Given that nobody else is complaining, it must be something I'm not
>doing correctly.  I select a region (either with the mouse, or by selecting
>the start and end points in the dialog).  There are "T"s in the program
>memory window where I've selected tracing.  When I run the program all
>I get in the trace buffer are NOPs.  Kinda defeats the purpose of a
simulator,
{Quote hidden}

John A. Craft                           (601)689-8100 Voice
Vice President, Sr. Analyst             (601)689-8130 Fax
Nation Computer Services, Inc.  http://www.ncs-ssc.com
MSAAP Bldg 9110                 spam_OUTcraftTakeThisOuTspamncs-ssc.com
Stennis Space Center, MS  39529

1999\08\04@193520 by Thomas Brandon

flavicon
picon face
Ever looked at Universal Micro Proccessor Simulator. You tell it there's an
ADC hooked up to pins whatever give it an input for the ADC and it handles
the rest. Very nice idea. The interface could do with a bit of polishing. If
I had $500+ to spend on a emulator I'd be getting it.

I wonder if Microchip will create some sort of graphi8cal configuration
utility like Intel's ApBuilder. I find ApBuilder to be fantastic for someone
new to Intel chips.

Tom.
{Original Message removed}

1999\08\04@203956 by Darrel Johansen

picon face
We're working on much of this right now.  Expect an end of
the year update that has mostly user-friendliness improvements.
Of course, by the end of the year, you might not need those
things, because you'll be an expert by then.

Anne Ogborn wrote:
> 1. Some feedback when you are running with unbuilt code.
We are looking at this, as well as a message to indicate that
the source has been modified but not rebuilt when you try
to do debug functions.

> 2. support for 3rd party programmers, esp. the direct from
> parallel port kind.
This is a possibility.  Whoever makes these, contact me at
.....darrel.johansenKILLspamspam@spam@microchip.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.

> 3. make stopwatch less obtrusive - put it in status bar???
Ran out of room on the status bar in 640:480 mode.  Maybe we
can make the status bar customizable...

> 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??????
This'll probably have to wait for MPLAB-32 (which is also underway,
but don't look for it this millenium).

___________________________
|     Darrel Johansen     |
|     tempe,  arizona     |
|   darreljspamKILLspamprimenet.com  |
|_________________________|

1999\08\04@205029 by Bob Drzyzgula

flavicon
face
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??????

Writing it in real Win32 code would be a start at
improving the product for the Windows platform,
although my preferance would be for them to go
in the opposite direction and write totally
portable code that could someday wind up on a
Unix or Linux platform. Cadsoft, for example,
is going to use the Qt GUI for the next version
of Eagle, which will help keep the product
cross-platform. It isn't clear to me that
uChip cares about this sort of thing, however.

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.

BTW, as for the help file being less than helpful,
there is also a full (250 page) manual for MPLAB,
that AFAIK doesn't come with the MPLAB download:

www.microchip.com/10/Tools/PICmicro/DevEnv/MPLABi/Software/manual/51025b/
index.htm

There are also MPASM/MPLINK/MPLIB manual at

http://www.microchip.com/10/Tools/PICmicro/Code/MPASM/33014g/index.htm

FWIW.

--Bob

--
============================================================
Bob Drzyzgula                             It's not a problem
.....bobKILLspamspam.....drzyzgula.org                until something bad happens
============================================================

1999\08\04@205650 by Richard Prosser

flavicon
face
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

> {Original Message removed}

1999\08\04@211558 by Tim Hamel

picon face
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

In a message dated 8/4/99 5:57:22 PM Pacific Daylight Time,
EraseMERPROSSERspam_OUTspamTakeThisOuTSWICHTEC.CO.NZ writes:

{Quote hidden}

1999\08\04@223540 by Peter van Hoof

flavicon
face
[snip]
> > 2. support for 3rd party programmers, esp. the direct from
> > parallel port kind.
> This is a possibility.  Whoever makes these, contact me at
> darrel.johansenspamspam_OUTmicrochip.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

1999\08\04@234406 by Mark Willis
flavicon
face
Peter van Hoof wrote:
{Quote hidden}

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

1999\08\05@095330 by Jim Hartmann

flavicon
face
      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

1999\08\05@121323 by Anne Ogborn

flavicon
face
Matthew Fries wrote:
>
> Heck! As a PIC Newbie, I would be glad if the HELP in MPLAB were
> implemented....
>

It is, you've got to download it though.
I like their help system and use it all the time.

1999\08\05@121721 by Anne Ogborn

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

I thought M$ was giving it away for a small fee to
encourage adoption. Maybe I'm wrong.

1999\08\05@180552 by Eric Oliver

flavicon
face
The thing is, you could eliminate all that using programmer plugins.  MChip
dictates ( or documents - I noticed the PS+ software is a DLL ) a DLL
interface and what is expected of the DLL.  All configuration, etc. can be
handled by the DLL (same concept as control panel applets). Really wouldn't
matter then.  All MPLAB has to do is load the DLL ( that you select) and
call various functions within the DLL to program a chip.

Sure would make life simple. Imagine being able to buy a programmer,
install the DLL in MPLAB, and your set.  Of course, right now, a person
using MPLAB has an added incentive to buy a PS+ <g>.

On Wednesday, August 04, 1999 10:43 PM, Mark Willis
[SMTP:KILLspammwillisKILLspamspamNWLINK.COM] wrote:
{Quote hidden}

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
{Quote hidden}

1999\08\05@180555 by Eric Oliver

flavicon
face
I like that idea also.


On Wednesday, August 04, 1999 7:52 PM, Richard Prosser [SMTP:RPROSSER@SWICHTEC.C
O.NZ] wrote:
{Quote hidden}

> > {Original Message removed}

1999\08\05@205857 by Thomas Brandon

flavicon
picon face
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.

However, a simpler task (which provides almost as much functionality) is too
slowly implement ActiveX interfaces for critical parts of the program.
Depending on the exact way the program's designed this could be quite easy
or quite difficult. Assuming that MPLAB is modular (which it almost
certainly is) and they are using a development tool that supports ActiveX
(which most Windows tools do in some way) it should be possible to add
ActiveX interfaces for some parts.

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.

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

Tom.
----- Original Message -----
From: Anne Ogborn <spamBeGoneanniepoospamBeGonespamNETMAGIC.NET>
Subject: Re: MPLAB desires


> > 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.
>
> I thought M$ was giving it away for a small fee to
> encourage adoption. Maybe I'm wrong.

1999\08\05@220357 by Tony Nixon

flavicon
picon face
Thomas Brandon wrote:

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

I am thinking of looking down this track myself for my own PIC tools. I
wonder if there is any support for serial/parallel port interfaces
though.

--
Best regards

Tony

"COMING SOON"
A Parallax to PIC source code converter.

http://www.picnpoke.com
Email ???

1999\08\05@221426 by Thomas Brandon

flavicon
picon face
Good point. In any case it could be done with native DLLs. You'd probably
want to do some of it in native code anyway for speed\programming ease.

Tom.
{Original Message removed}

1999\08\05@225229 by Dan Creagan

flavicon
face
I like the idea of doing it with Java since I'm a Java supporter. The idea
of doing it in ActiveX or in MS DLLs locks everyone into MS and there's no
reason to exclude the MAC users (both of them ;) ) or the Linux folks.  Java
applications should run smoothly and fast enough even without native code -
thus it could be made cross platform easily. Some native stuff for the port
addressing might be necessary (I haven't thought that through at all) - but
if kept to a minimum, moving it to different platforms should be easy
enough.

Unfortunately, it would lock everyone into a 32 bit machine with 32 meg+ of
memory, many megs of hard drive space for the runtime, etc. Trade offs can
be difficult.

Dan

{Original Message removed}

1999\08\05@225445 by Thomas Brandon

flavicon
picon face
Just had a look at the Sun Java site (love all those "; expected" Javascript
errors) and found the Java(tm) Communications API Users Guide
at http://java.sun.com/products/javacomm/javadocs/API_users_guide.html .
Support for serial +parallel access across platforms.

It's not actually part of the JDK (at least not yet) it's the javax.comm
package. They call it a Java Standard Extension. Haven't done any Java in a
while so I haven't seen any of these before. Sun has implementations
available for Solaris (SPARC and x86) and Windows.

Tom.
----- Original Message -----
From: Tony Nixon <TakeThisOuTTony.NixonEraseMEspamspam_OUTENG.MONASH.EDU.AU>
Subject: Re: MPLAB desires
> Thomas Brandon wrote:
>
> > I'd certainly be willing to devote programming time to a Java based
> > simulator.
>
> I am thinking of looking down this track myself for my own PIC tools. I
> wonder if there is any support for serial/parallel port interfaces
> though.

1999\08\05@232332 by Thomas Brandon

flavicon
picon face
Yep, some underlying native code all done through standard Java interfaces
would allow maximum flexibility. That way you can have Java interfaces
dealing with native formats via native code (i.e. add support for gpsim
format etc). Then the *nix people can write C DLLs, the M$ people can write
ActiveX DLLs (thus they can use VB etc) or Active Script, the Mac people can
write Hypercard addins or everyone can write Java.

I think it's better to limit it to any 32bit 32meg machine than only
PC\Mac\Unix. Upgrading your machine doesn't change the way things work,
upgrading your OS does.

Tom.
{Original Message removed}

1999\08\05@232803 by Anne Ogborn

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

{Quote hidden}

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.

{Quote hidden}

Yes - but this seems to be impractical to do given reasonable budget. Yet a stim
ulus file
interface is fairly trivial.


{Quote hidden}

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

1999\08\05@235548 by Anne Ogborn

flavicon
face
Tony Nixon wrote:
>
> Thomas Brandon wrote:
>
> > I'd certainly be willing to devote programming time to a Java based
> > simulator.
>
> I am thinking of looking down this track myself for my own PIC tools. I
> wonder if there is any support for serial/parallel port interfaces
> though.
>

If you can't do it with javax.comm (which has pretty poor parallel port
support, but excellent serial support - I'm already lobbying Sun for
better parallel port support) you can do it with
JNI methods.  Just do us all a favor and make them general enough to
not orphan us NT users.


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

1999\08\06@002224 by Anne Ogborn

flavicon
face
Thomas Brandon wrote:
>
> Just had a look at the Sun Java site (love all those "; expected" Javascript
> errors) and found the Java(tm) Communications API Users Guide
>  at http://java.sun.com/products/javacomm/javadocs/API_users_guide.html .
> Support for serial +parallel access across platforms.
>

I've used this package.
It's parallel support is pretty poor - it assumes you're a printer,
and if you aren't, tough. It's a "parallel out" package, not a parallel port har
dware
we all know and tinker with package.
But that's irrelevant - doing JNI's a < 1 day/OS task.
Still, have a little trouble imagining parallel port support for the Mac.  8o)


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

1999\08\06@043625 by Michael Rigby-Jones

flavicon
face
       <snip>
Thomas Brandon [RemoveMEtomspamTakeThisOuTPSY.UNSW.EDU.AU] wrote:
> 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.
>
I'm not a big fan of Java, but MPLAB probably couldn't run much slower than
it does now!  I started writting a very simple simulator purely in VB5, and
the last time I had a fiddle with it, I was managing faster than real time
on a 233 Pentium (about 1.2 MIPS) which isn't bad for such a bloated slow
langauage....admittedly it is very basic at the moment, no breakpoints or
anything yet.

The reason I started writting the it is I've always thought a cool idea
would be to have a "semulator".  This would be a simulator, but with some
kind of hardware interface, probably through the parallel port.  For a chip
like the 16F84, and assuming you don't want to do anything tricky this
dosen't sound too difficult.  In fact, if you could put up with PORTA being
inputs only and you didn't need interupts etc, you wouldn't need any other
hardware.  Obviously this wouldn't be suitable for serious development, but
for newbie push button/led flasher projects it would be great.  With a nice
fast CPU and a more complex interface, who knows whats possible.

Tony, maybe a PIC'n'PLUG add on to your simulator?

Cheers

Mike Rigby-Jones

1999\08\07@013715 by Mark Willis

flavicon
face
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

1999\08\07@113508 by Eric Oliver

flavicon
face
IMHO, it would be extremely difficult, to hack.  Without access to the
actual data used to paint the window, intercepting the WM_PAINT message is
useless. Then there's the possibility that some ill behaved programs paint
outside the WM_PAINT.  Windoze's very own edit control is a nice example of
this.  I concede that it would be possible to hack MPLAB to discover where
and how the data used in the register window is stored ( many with talent
beyond me have done that very thing to Windoze itself ), however, those
with this much talent and time are probably writing their own simulator
<g>.

BTW, I wouldn't think that individual messages are sent when a register is
changed.  More likely register data is stored in some type of structure and
when that structure is changed a call to InvalidateRect(..) is made to
force a repaint.  If individual messages were used, it might make it easier
to intercept and maintain the status of registers outside of MPLAB.

On Saturday, August 07, 1999 12:35 AM, Mark Willis
[SMTP:mwillisEraseMEspam.....NWLINK.COM] wrote:
{Quote hidden}

1999\08\08@025326 by Scott Dattalo

face
flavicon
face
On Wed, 4 Aug 1999, Bob Drzyzgula wrote:

{Quote hidden}

I actually had CORBA "integrated" into gpsim at one point. But I soon had
to remove it. That's the bad news. The good news is that I plan to add it
back again. [That time will come when ORBit - the GPL orb that implements
CORBA {and is used by GNOME} becomes a little more mature and when I
understand the latest CORBA spec better. ORBit only supports the latest
POA stuff and not the BOA. Only in the last few weeks have I seen books
describing the POA. ]


The whole purpose of CORBA was to provide a convenient method to interface
with gpsim without having to dig into the source code. The basic
assumption is that gpsim is a simulator engine - period. Everything else
such as the user interface, stimuli, etc, are better supported externally
and dynamically linked/networked to gpsim. That's a nice idea, but if
you've got the source code freely available then some things are more
easily implemented using a direct approach. But I still wish to keep the
functionality separated. So, currently gpsim consists of three libraries:
the simulator, the command line interface, and the graphical user
interface. I went through considerable effort to ensure that these three
are kept as separate as possible (e.g. duplicating information,
structures, etc.). And it's at these boundaries where CORBA will most
likely be inserted.

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

Scott

1999\08\08@191233 by Tony Nixon

flavicon
picon face
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 ???

1999\08\08@191644 by Tony Nixon

flavicon
picon face
Michael Rigby-Jones wrote:

> Tony, maybe a PIC'n'PLUG add on to your simulator?

Already done. PicNPokes Real World Interface.

Lots of people including schools using it.

--
Best regards

Tony

"COMING SOON"
A Parallax to PIC source code converter.

http://www.picnpoke.com ??
Email ???

1999\08\08@192936 by Dennis Plunkett

flavicon
face
At 09:12 9/08/99 +1000, you wrote:
{Quote hidden}

Hey Tony,
I think that your product should be known as plug'n product at every chance.

Dennis

1999\08\08@194629 by Thomas Brandon

flavicon
picon face
I would be most interested in seeing your VB simulator. Is the code\exe
anywhere on the web?

I used too be more into VB but VJ6 has got me. The ease of VB form design
with a few advantages (love that slider control. Add a Tree (or any other
control) docked to the right side of the screen, add a slider docked to the
right side of the screen and youve got an explorer style resizable tree with
no code. Try doing that in  VB). And, best of all it's Java based so you get
all that lovely OO stuff in both the backend and the UI (which is messy to
do in VB).

Your "semuator" idea is the sort of thing I would love to see. The ability
to mix flat file stimuli data, script/addin generated stimuli data and
hardware generated stimuli would be a real boon in my eyes. If you could
come up with a nice small, flexible protocol for PIC->PC data tranfer you'd
be laughing. Simulate the buttons and LEDs with a PC interface sending the
resulting output to a real PIC which does an A/D conversion and sends the
result back to the PC to simulate the output to LCD and storage in
(simulated) EEPROM. Thus to test an A2D/LCD/LED/Button based solution the
only hardware you need is an A/D hooked up to the specially configured PIC.
In my mind this would help alleviate the problem of simulations being too
rugged. i.e. specs are not 100% correct and thus it is very hard to truly
simulate a devices errors. However, if you can start with an entirely
simulated project and slowly replace simulated components with real
components you will be able to quite easily detect where it your simulation
falls over.

Tom.
{Original Message removed}

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