gnupic: Thread: gpsim

Oh one more thing, Ralf. I've changed the gpsim installation so that include
files are now installed along with the libraries. For the time being though,
"make" is going to fail. You'll need to manually install the include files or go
into the modules/ directory and "#ifdef 0 / #endif" the code in
binary_indicator.cc. I'll fix the install dilema soon.

I've cc'd the gnupic mailing list just in case anyone's thinking about
downloading the CVS. (I'd suggest waiting a few days to let things settle down a
bit).

Scott

Hello all,

I'm very interested in the Gpsim PIC simulator but 
so far, I haven't succeeded in compiling it.

I have gpsim-0.20.0 from dattalo.com.
eXdbm-0.1.0b2.tar.gz and gtk+extra-0.99.9.tar.gz     

./configure seems to work properly.  A couple of minutes 
into make, I get error messages:

-lgdk -lgtkextra -lglib -lm -lreadline -Wl,--rpath -Wl,/usr/local/lib
../gui/.libs/libgui.so: undefined reference to `eXdbmGetList'
../gui/.libs/libgui.so: undefined reference to `eXdbmGetLastError'
../gui/.libs/libgui.so: undefined reference to `eXdbmNewDatabase'
../gui/.libs/libgui.so: undefined reference to `eXdbmCreateList'
../gui/.libs/libgui.so: undefined reference to `eXdbmInit'
../gui/.libs/libgui.so: undefined reference to `eXdbmOpenDatabase'
../gui/.libs/libgui.so: undefined reference to `eXdbmChangeVarInt'
../gui/.libs/libgui.so: undefined reference to `eXdbmUpdateDatabase'
../gui/.libs/libgui.so: undefined reference to `eXdbmGetVarInt'
../gui/.libs/libgui.so: undefined reference to `eXdbmGetErrorString'
../gui/.libs/libgui.so: undefined reference to `eXdbmCreateVarInt'
collect2: ld returned 1 exit status
make[2]: *** [gpsim] Error 1
make[2]: Leaving directory `/home/skelton/gpsim-0.20.0/gpsim'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/skelton/gpsim-0.20.0'
make: *** [all-recursive-am] Error 2  

I've tried both the rpm and tar.gz version of eXdbm. 
/usr/local/lib is in my ld.so.conf file and I have 
run ldconfig

I have a PII 333 running RH6.2, kernel 2.2.16, 
gcc  egcs-2.91.66.

Many Thanks.

Eamon Skelton.


                       
     
 
--


"In theory there is no difference between theory and practice.
  In practice there is."
                                   Albert Einstein

Linux  2.2.16

On 25-Sep-2000 Eamon Skelton wrote:
> 
> Hello all,
> 
> I'm very interested in the Gpsim PIC simulator but 
> so far, I haven't succeeded in compiling it.

Hello Again,

I've got it working!  0.20.0 just wouldn't compile 
so I tried the development version 0.20.5.  It 
works perfectly and seems quite stable.

My first impression is that it is VERY fast.
Simulations that take minutes on PSIM.EXE 
take a fraction of a second on Gpsim.

OK, thats the assembler and simulator sorted. 
Can anybody recommend a good pic programming 
program that works properly with kernel 2.2.16?
I managed to program a few chips with David 
Tait's pp ver. 0.5 and the QANDD hardware. I 
would like to try something with a nicer user 
interface.

Thanks,  E.S.

On 27-Sep-2000 Eamon Skelton wrote:

> Can anybody recommend a good pic programming 
> program that works properly with kernel 2.2.16?

I really will have to stop replying to my own 
messages!   I built the JDM style - serial port 
programmer.  It works very nicely with picprog-1.0.

Thanks to all who replied.

E.S.

--


"In theory there is no difference between theory and practice.
  In practice there is."
                                   Albert Einstein

Linux  2.2.17

Hello all,
	Could some one help me with gpsim? I'm wanting to set up some inputs to test 
a program. I'm new to all to all this. I looked for docs but they didn't give 
a whole lot of detail on how to do this.
Thanks.
-- 

L. Wayne Patterson
Linux User #207455
"Change lays not her hand upon Truth"
Algernon Charles Swinburnee

On Sat, Dec 15, 2001 at 04:01:08PM -0600, Lenny Patterson wrote:
> Hello all,
> 	Could some one help me with gpsim? I'm wanting to set up some inputs to test 
> a program. I'm new to all to all this. I looked for docs but they didn't give 
> a whole lot of detail on how to do this.

I saw your last email, but I forgot to answer, sorry. 

Yeah, the docs are not so good. I'm not very good at updating the docs.
There should be a FAQ-type section of the docs that explain common tasks.


You can control inputs to the processor by opening the pins window and
double-clicking the pins.

Or, you can look at some of the .stc files in the examples directory. The
stc files is where you create the stimuli.

The third way would be to create a gpsim module that simulates a switch.
This module could even simulate contactor bounces. I don't know of any 
module like this yet.

 / Ralf

John,

You've brought up some interesting points. I hope you don't mind that I've
cc'd my response to the gnupic mailing list (see http://www.gnupic.org/
for info on how to join the list).

On Sat, 26 Jan 2002, John Sheahan wrote:

> Hi Scott
>
> been playing with gpsim a bit for a couple of pic projects I have.
> under linux of course.
>
> definitely a step up on the cook - 16f84 - try - think - fix - reburn loop
> I like it.    but I'm too anti-windows to use mplab
>
> found a few minor issues, wondering which way to proceed.
>
> Are you currently maintaining the code?
>

Absolutely.

> would you prefer bug descriptions or patches?

Patches are preferred. However, if you see a bug, don't feel obligated to
create a patch.

>
>
> I'm more a perl / script / assembler person (really a hardware
> designer) but I have to finish learning c one day :)
>
>
> things I have noticed so far:
>
> I'm using gpsim-0.20.12.tar.gz  (whoops, thats old I now notice, you
> must be workng on same)
>
> o eerom window stays blank if it comes up before the pic type is defined and
>   code loaded.

I haven't seen this because I invoke gpsim different than you.

From the command line:

gpsim -s file.cod

This loads the .cod file when gpsim is invoked.

>
> o stimulus, pullup on a dedicated input port not obvious to model.
>   I ended up just modifying the reg contents

I'm not sure what you mean here. It is possible to attach a pull up (or
pull down) resitor to an I/O pin. This is done via an external module.

>
> o setting a symbolic register seems to be two step
>   ie first find the address, then set it.

From the command line you can use the 'x' command. E.g. here is a
cut-n-paste session illustrating the 'x' command.

gpsim> x temp
temp [0x34] = 0x0
gpsim> x temp 4
gpsim> x 0x34
temp(34) is 4
gpsim> x 0x34 5
temp(34) was 4 now is 5

In the gui, you can click on a cell in the register window and directly
edit a register. (Unlike MPLAB where you have to bring up a dialog window
to edit a register).

>
> o register viewer window seems not to always reflect reg contents, but
>   watch window is good. And I'm not sure how to repeat this.

Hmm. Are you sure? I suspect that a few of the special function registers
may not get updated, but they should! If you can repeat this, let me know.

> o doing a table string lookup with
>   GetInitChar
>       addwf	PCL,F		; Jump table
>   the pc address seems to be calculated as  (pcl) & 0xff
>   ie high byte is set to 0 instead of unchanged.
>   So this works in the first 256 bytes, then clags out.

This is the way PICs work. You need to set the PCLATH register too and be
aware when your table spans the 256 byte boundary.

>
> o cannot figure out how to load a cod file from the cmd line.
>   works from the gui.

See above.

> o reset appears to leave enough states unreset its better to quit and restart.

This is true. In CVS, I've changed the way reset is implement so that this
issue can be addressed. Before, a reset would basically zero the program
counter and set a few status bits. However, Peter Onion reported a bug
with Reset/WDT/Sleep that led me to redo the reset logic. I added a new
member function to the register base class that gets invoked when a reset
occurs. All I have to do now is go through each register type and write
the reset logic code. Simple, but tedious. For the moment, the
quit/restart approach is the best way.

>
> o doc/feature  related, is there a way to step through a subroutine call?
>   ie, tracing at higher level, is there a 'next' button that does a
>   step for an instruction, and sets a temporary breakpoint on the next
>   code address for a call?

at the command line

gpsim> step over

In the source browser,

right click to bring up a window and select the step over option
  OR
press the letter 'o' while the source browser window has focus
  OR
press 'F8' while the source browser has focus

>
> o doc/feature  related
>   when single stepping, is save_state and restore_state practical, so
>   that a backup button could be implemented?
>   I get a bit carried away stepping, particularly is I want to fudge
>   registers and test a routine

That's interesting you mention this. This was one of the original design
goals of gpsim. (In fact, I think it's still buried in the TODO). I
desired this feature because of my experience with MPLAB. MPLAB was so
slow that it took a long time to reach a state in the simulated program.
So I wanted to step forward across a crucial state, see what happens, step
backwards, change a condition, and step forward again. While writing
gpsim, I found this very difficult to implement. One of the problems with
it is that all state machines need to run forwards AND backwards in time.
In many cases it's hard enough to get them to just run forwards properly!
After using gpsim as a development tool, I found the running backwards
feature was not really needed. gpsim is so fast that for most cases it's
easy to just let the code loop and set a break at the point of interest.

-----

These are all very good suggestions and observations, John. I'm currently
in SDCC mode and will not be working on gpsim for the next few weeks. The
next items I plan to address with gpsim are:

  * Fix the readline install problem
  * Document the module interface

I'm also falling behind on Craig's work and suspect that I'll need to
address the new features of gpasm/gputils too.


Scott

Hi all,

i need to simulate a distributed embedded system that is composed of 
thousands of pics. 

Each pic will be implemented as a java object that encapsulates gpsim. 
And the distributed system simulator will be implemented in java.
(jni to interface gpsim c code and java code.) java based simulation 
system will execute each individual instance of gpsim object in a 
round-robin fashion and pass the messages between them. 

now, can this be done? does gpsim provide the necessary modularity to 
develop such a simulation system? if so, what are the interfaces/src 
files i need to look into? 

any help/suggestions will be gratefully appreciated.

thanks in advance,
Deva Seetharam

-------------------------------------------------
617.666.6674 (h)
617.253.1522 (w)

E15-426,
MIT Media Laboratory,
20 Ames Street,
Cambridge, MA 02139
-------------------------------------------------

On Sat, Jun 29, 2002 at 01:37:11AM -0400, Deva Seetharam was heard to remark:
> Hi all,
> 
> i need to simulate a distributed embedded system that is composed of 
> thousands of pics. 

Can't answer your questions, but ... my curiosity is piqued ... 
"MIT Media Labs" .... what are you planning on doing with a thousand
connected pics?

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) ####@####.####
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933

On Sat, 29 Jun 2002, Deva Seetharam wrote:

> Hi all,
> 
> i need to simulate a distributed embedded system that is composed of 
> thousands of pics. 
> 
> Each pic will be implemented as a java object that encapsulates gpsim. 
> And the distributed system simulator will be implemented in java.
> (jni to interface gpsim c code and java code.) java based simulation 
> system will execute each individual instance of gpsim object in a 
> round-robin fashion and pass the messages between them. 
> 
> now, can this be done? does gpsim provide the necessary modularity to 
> develop such a simulation system? if so, what are the interfaces/src 
> files i need to look into? 
> 
> any help/suggestions will be gratefully appreciated.

With a little work, I think it would be possible.

Right now, gpsim creates three libraries: libgpsim, libgpsimgui, and 
libgpsimcli. You should be able to link to these with another, custom 
application. As it currently stands, libgpsimcli (command line interface) 
and libgpsimgui (the gui interface) are dependent on libgpsim (the 
simulation engine. But in your case, you really don't need the gui or the 
cli. The cli however, will be useful usefl for illustrating how to 
interface to gpsim. In other words, the gpsim api is not documented.


The way I'd approach this is to start off with a copy of gpsim. In the 
directory gpsim/gpsim/ there is a makefile that creates the executable.  
I'd edit the Makefile in that directory and hack main.cc to perform the 
work. Essentially what you'll need is to instatiate your 1000 processors 
(e.g. processor[i] = add_processor(name, type); ) and then load each with 
it's own hex file (e.g. processor[i]->load("file.hex");). Now, while gpsim 
was designed with multiple processors in mind, over the years I know that 
design has been violated. I'm fairly confident that you'll be able to step 
and run your programs, but the break point, trace, and stimuli subsystems 
will need some work.

---

An entirely different approach is to consider something like SID.
http://sources.redhat.com/sid/ .  Ben Elliston (a SID developer and I) 
exchanged a few messages about adding a PIC engine to SID. Check out this 
thread: http://sources.redhat.com/ml/sid/2002-q2/msg00030.html

BTW, I'm using SID to simulate an ARM processor. It's pretty cool.


Scott