gnupic: gpsim 18F* problems
Subject:
Re: gpsim 18F* problems
From:
Scott Dattalo ####@####.####
Date:
11 Jan 2005 04:55:54 +0000
Message-Id: <Pine.LNX.4.60.0501102033260.22855@ruckus.brouhaha.com>
On Mon, 10 Jan 2005, Ian Jackson wrote:
> Scott Dattalo writes ("Re: gpsim 18F* problems"):
>> Ian thanks for taking the time to document all of these issues you've
>> encountered. Could you tell me which version of gpsim you were using?
>
> Oops, I forgot to say ! gpsim-0.21.2, compiled by hand from stock
> sources on Debian sarge using
>
> ./configure --enable-gtk2 --prefix /u/ian/things/Trains/plocal
> make CPPFLAGS+='-I/usr/include/glib-1.2 -I/usr/lib/glib/include \
> -I/usr/include/gtk-1.2 -I/usr/include/gtkextra' \
> LIBS+='-lgtkextra -lglib'
> make install
Ian,
Some of the errors you described have been fixed. I know the address
problem popped up in May(?) of last year when Craig fixed gputils to make
them match Microchip's tools. The interrupt priorities/peripheral
interrupt vectors were briefly visited since 0.21.2 has been released; so
this may be fixed as well (I never use interrupt priorities so, this is
an area that's seldom tested). However, the issues with configuration
bits and TMR0 are still present.
I can sympathize with the difficulty one can have trying to understand
another's code. The hierarchical design is nice for the designer, but
until you learn how things are structured it's just really hard to follow.
Early on I had thought about using 'configuration files' to describe each
device. The idea here is that the objects that comprise a processor would
be coded up as separate entities, and the configuration file would choose
from the various objects to build up a processor. This would be nice
because a user could essentially create any processor that consists of the
basic building blocks. I abandoned this approach because it was too much
work for the designer :).
In general, I try to accommodate everyone's requests (really). But the
fact of the matter is that I'm really overwhelmed. (The gui changes and
the lagging I/O port updates are constant reminders in this regard). So
progress is slow... But OTOH, I've been working almost full-time on gpsim,
but in areas that people are probably not too aware. Most of the changes
have been made to support regression tests.
Scott
