gnupic: Thread: gpsim status

Ralf,

I decided to bring this back on-line again...

On Mon, 17 Jan 2000, Forsberg Ralf wrote:

> > BTW, gpsim. I got the 64 bit cycle counter code fully integrated in the
> > /src directory. I changed all references to the cycle counter from
> > 'unsigned int' to 'guint64'. This implies that glib.h is now needed for
> > the ./src too (it's always been needed for the gui). I still have a few
> > additional minor things to fix with the trace buffer though. After I
> > receive your patches on the gui, I'll go ahead and make the cycle counter
> > 64 bits wide in the status bar.
> 
> 	You'll get my patches in two-three days, but we will need gtk-extra.
> I haven't 
> 	considered how to detect/configure it (and I don't know much about
> automake)
> 	so you'll have to do that.

I'll go ahead and grab gtk-extra and make all of the changes in the
./configure script to detect it. It looks like Adrian implemented the same
installation technique as gtk, so it ought to be straight forward in
detecting gtkextra and linking it with our stuff.

Also, I got the register symbol stuff working. Now when gpsim starts, all
sfr's have an associated entry in the symbol table. I did not do anything
with the bit flags, though.

Some other things I've recently added:

cli 'set' command - used to modify flags and control gpsim's behavior (I
currently just have 'verbose' . 'set verbose 0' will turn off all of those
damn debug messages.)

cli 'dump s' command. I added an 's' option to the dump command so that
only special function registers are dumped.

rounded out support of the 18cxxx instruction set -
tblrd,tblwr,mullw,mulwf are now supported.

Finally fixed the 'config_word' bug once and for all. Now the
configuration word is properly loaded when either .cod or .hex files are
used.

If anyone cares to see the pre-18 stuff, I've gone ahead and placed a
copy here:

http://www.dattalo.com/gnupic/gpsim-0.17.2.tar.gz

The README goes into more detail about the latest features:
http://www.dattalo.com/gnupic/README

(Ralf, you don't need to merge with 0.17.2)

The only thing I want to add before we release 0.18.0 is the interrupt
support for the 18cxxx family. The code is mostly done, but hardly tested.



Scott

gpsim development has been stalled for a week because I somehow trashed my
system. I wanted to get version 0.20.0 released last weekend, but instead I
spent about 10 hours trying to figure out what's going on! In case anyone's
interested, here's what I posted to the gtk list to get some help:

---------------------------
Subject: mixing cout with gtk


Has suddenly produced core dumps for me.

I've been using gtk for a few years now, but I'm stumped on this one. Perhaps
somebody's seen this too and can help out. It appears that I'm unable to write
to the cout stream. However, if I configure my program without the gui (there's
a command line version too), the cout's work fine ?!?

Why all of a sudden? Well I upgraded from gtk 1.0.? to 1.2.8 and that's when I
noticed the problems. I've done many `experiments' with my system... but suffice
it to say that I'm now running gtk/glib 1.2.6 . I've attempted to remove all
traces of old gtk/glib libraries and I'm fairly sure I've gotten them all. The
1.2.6 version of glib/gtk were installed from RPMs. I've also installed the
`devel' versions of gtk/glib. 

I use automake - is there a check that's possibly being missed?

My system is basically a RH6.0 system with numerous upgrades. My gcc is old:
$ gcc --version
egcs-2.91.66


(BTW, my project is gpsim, http://www.dattalo.com/gnupic/gpsim.html , a
simulator for pic microcontrollers.)

Here's a snip of my `main.cc'.

------------------------

void
main (int argc, char *argv[])

{

  cout << "this is a test with cout\n";

------------------------

And here's the backtrace after it dumps core

#0  0x403377b2 in __overflow (f=0x80cddc0, ch=-1) at genops.c:197
#1  0x403366b0 in _IO_new_file_xsputn (f=0x80cddc0, data=0x80ba57f, n=27) at
fileops.c:802
#2  0x80b22b4 in filebuf::xsputn (this=0x80cddc0, s=0x80ba57f "this is a test
with cout a\n", n=27) at filebuf.cc:205
#3  0x80af8b3 in ostream::operator<< (this=0x80cdec0, s=0x80ba57f "this is a
test with cout a\n") at iostream.cc:784
#4  0x8070d79 in main (argc=1, argv=0xbffffbf4) at main.cc:108
#5  0x402f9cb3 in __libc_start_main (main=0x8070ce4 <main>, argc=1,
argv=0xbffffbf4, init=0x806f53c <_init>, 
    fini=0x80ba2cc <_fini>, rtld_fini=0x4000a350 <_dl_fini>,
stack_end=0xbffffbec)
    at ../sysdeps/generic/libc-start.c:78


Any ideas?

---------------------------------

Anyway, I can't release gpsim until this is resolved... 


Scott

PS. Yeah, I'm pissed.

In case you're wondering why it's been so quiet:

http://www.dattalo.com/gnupic/t.gif

But it ain't ready for prime time just yet.

Scott

On Mon, Aug 21, 2000 at 09:20:56PM -0500, Scott Dattalo wrote:
> 
> In case you're wondering why it's been so quiet:
> 
> http://www.dattalo.com/gnupic/t.gif
> 
> But it ain't ready for prime time just yet.

wow! that's cool!

how does that device connect to the pic??
i mean can i configure which pins of the device get connected to which
pins on the pic? can i invert some of the pins?

is it a typical default display?



cu
erik

-- 
Name:  Erik Thiele                                       \\\\
Email: ####@####.####                                o `QQ'_
IRC:   erikyyy                                            /   __8
WWW:   http://www.erikyyy.de/                             '  `

On Tue, 22 Aug 2000, Erik Thiele wrote:

> On Mon, Aug 21, 2000 at 09:20:56PM -0500, Scott Dattalo wrote:
> > 
> > In case you're wondering why it's been so quiet:
> > 
> > http://www.dattalo.com/gnupic/t.gif
> > 
> > But it ain't ready for prime time just yet.
> 
> wow! that's cool!
> 
> how does that device connect to the pic??
> i mean can i configure which pins of the device get connected to which
> pins on the pic? can i invert some of the pins?
> 
> is it a typical default display?

It's totally generic - almost.

I've got the module hard coded for a 2X20 display and it doesn't support all of
the LCD commands (like scrolling). I wrote a script that attach nets between the
pic and the LCD module. The pic source code is something I wrote a while back
for a real LCD display. In fact, this version starts off in 8-bit mode and then
initializes the display to 4-bit mode.

And it works!

As far as interfacing is concerned, you can do just about whatever you want, I
suppose. The pic and LCD modules are totally unaware of one another. It's the
nodes that link them together. The LCD module is event driven (like gpsim) and
will respond to changes on the control and data lines. The events control a
state machine. 

I'm going to be out of town for a few days (ISA show) so it won't be 'til this
weekend when I can work on it some more.

Scott

gpsim-0.20.1 fails to compile with the attached log.
gtk+extras-0.99.10
eXdbm-0.1.0b2 with README.gpsim
glib-1.2.8
gtk+-1.2.8
What am I missing?
Garst

make  all-recursive
make[1]: Entering directory `/usr/local/src/gpsim-0.20.1'
Making all in cli
make[2]: Entering directory `/usr/local/src/gpsim-0.20.1/cli'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/local/src/gpsim-0.20.1/cli'
Making all in xpms
make[2]: Entering directory `/usr/local/src/gpsim-0.20.1/xpms'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/local/src/gpsim-0.20.1/xpms'
Making all in gui
make[2]: Entering directory `/usr/local/src/gpsim-0.20.1/gui'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/local/src/gpsim-0.20.1/gui'
Making all in src
make[2]: Entering directory `/usr/local/src/gpsim-0.20.1/src'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/local/src/gpsim-0.20.1/src'
Making all in gpsim
make[2]: Entering directory `/usr/local/src/gpsim-0.20.1/gpsim'
/bin/sh ../libtool --mode=link c++  -g -O2  -o gpsim -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include main.o ../src/libgpsim.la ../cli/libgpsimcli.la ../gui/libgui.la     -lstdc++ -L/usr/local/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm -L/usr/local/lib -lgtk -lgdk -lgtkextra -lglib -lm -leXdbm 
c++ -g -O2 -o .libs/gpsim -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include main.o ../src/.libs/libgpsim.so -L/usr/local/lib -L/usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lm -leXdbm ../cli/.libs/libgpsimcli.so -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lm -leXdbm ../gui/.libs/libgui.so -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lm -lgtk -lgdk -lgtkextra -lglib -lm -leXdbm -lstdc++ -L/usr/local/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm -L/usr/local/lib -lgtk -lgdk -lgtkextra -lglib -lm -leXdbm -Wl,--rpath -Wl,/usr/local/lib
../cli/.libs/libgpsimcli.so: undefined reference to `completion_matches'
../cli/.libs/libgpsimcli.so: undefined reference to `rl_forced_update_display'
../cli/.libs/libgpsimcli.so: undefined reference to `rl_copy_text'
../cli/.libs/libgpsimcli.so: undefined reference to `rl_attempted_completion_function'
../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_handler_install'
../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_handler_remove'
../cli/.libs/libgpsimcli.so: undefined reference to `add_history'
../cli/.libs/libgpsimcli.so: undefined reference to `rl_initialize'
../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_read_char'
collect2: ld returned 1 exit status
make[2]: *** [gpsim] Error 1
make[2]: Leaving directory `/usr/local/src/gpsim-0.20.1/gpsim'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/gpsim-0.20.1'
make: *** [all-recursive-am] Error 2

"Garst R. Reese" wrote:
> 
> gpsim-0.20.1 fails to compile with the attached log.
> gtk+extras-0.99.10
> eXdbm-0.1.0b2 with README.gpsim
> glib-1.2.8
> gtk+-1.2.8
> What am I missing?
> Garst
> 
>   ------------------------------------------------------------------------
> ../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_read_char'
Ah, these are from readline. 4.1 is installed, and this stuff is in it,
but cli/info.c has the include buried inside extern "C".
Garst again

On Sat, 26 Aug 2000, Garst R. Reese wrote:

> "Garst R. Reese" wrote:
> > 
> > gpsim-0.20.1 fails to compile with the attached log.
> > gtk+extras-0.99.10
> > eXdbm-0.1.0b2 with README.gpsim
> > glib-1.2.8
> > gtk+-1.2.8
> > What am I missing?
> > Garst
> > 
> >   ------------------------------------------------------------------------
> > ../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_read_char'
> Ah, these are from readline. 4.1 is installed, and this stuff is in it,
> but cli/info.c has the include buried inside extern "C".

Correct. Imbedding the readline.h include files in extern "C" stuff is necessary
for version 3.0 of the readline library. Are you saying it's causing problems
for the version 4.0 library? (Or rephrased - Is the THE problem gpsim has been
having with readline 4.0 all along?)

Scott

Scott Dattalo wrote:
> 
> On Sat, 26 Aug 2000, Garst R. Reese wrote:
> 
> > "Garst R. Reese" wrote:
> > >
> > > gpsim-0.20.1 fails to compile with the attached log.
> > > gtk+extras-0.99.10
> > > eXdbm-0.1.0b2 with README.gpsim
> > > glib-1.2.8
> > > gtk+-1.2.8
> > > What am I missing?
> > > Garst
> > >
> > >   ------------------------------------------------------------------------
> > > ../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_read_char'
> > Ah, these are from readline. 4.1 is installed, and this stuff is in it,
> > but cli/info.c has the include buried inside extern "C".
> 
> Correct. Imbedding the readline.h include files in extern "C" stuff is necessary
> for version 3.0 of the readline library. Are you saying it's causing problems
> for the version 4.0 library? (Or rephrased - Is the THE problem gpsim has been
> having with readline 4.0 all along?)
> 
> Scott
I have never gotten gpsim to compile. That is one of the reasons why I
installed v4 of readline, but these are not the same messages. But the
problem has always been with input.cc (info.c in the prv. msg. obv.
wrng.) I don't know what the problem is.
Garst

On Sat, 26 Aug 2000, Garst R. Reese wrote:

> I have never gotten gpsim to compile. That is one of the reasons why I
> installed v4 of readline, but these are not the same messages. But the
> problem has always been with input.cc (info.c in the prv. msg. obv.
> wrng.) I don't know what the problem is.
> Garst

As soon as I finish the LCD module, I'll install readline 4 and solve this
problem. This has been affecting too many people for too long...

Scott

PS. The LCD module is almost ready for initial release.