gnupic: GPSim Compilation Error
Subject:
Re: GPSim Compilation Error
From:
Scott Dattalo ####@####.####
Date:
19 Jul 2002 13:40:08 -0000
Message-Id: <Pine.LNX.4.44.0207190609340.17618-100000@ruckus.brouhaha.com>
On Thu, 18 Jul 2002, Loren M Lang wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> gpsim-0.20.14 fails to compile
> with an error message saying it's
> missing the include file linux/ppdev.h
> I found this file under the include
> directory of a 2.4 linux kernel, but
> not under the kernel I'm using, 2.2
> I commented out the module for the
> parallel port and it compiled ok
> otherwise. I think this should be
> fixed, at least by an autoconf test
> if nothing else. If I have time, I
> may write one.
I believe Ralf has fixed this one.
>
> Also, now that I have it working, I'm
> trying to simulate a PIC6C73A or a
> PIC16F873 since these are the two
> chips we're using for our project,
> but neither processor is accepted,
> though, I noticed the PIC1674 works:
>
> gpsim> processor pic16c74
> c74 construct
> gpsim> processor pic16c73
> Can't create a generic pic processor
> unable to add a processor (BUG?)
> Unable to add processor
> No cpu has been selected
This has been fixed in CVS.
>
> Both the '73 and '74 are on the 'Not
> fully supported' list. What does this
> mean, what isn't supported exactly.
>
> Also, I'm planning on attempting to
> write a module for gpsim so I can talk
> to the simulated pic's serial port
> with the software I'm using to control
> it though pseudo ttys. Is there
> anything like this by any chance?
> Also, I'm not very well versed in C++,
> I almost always write in C, do the
> modules require C++?
While developing the USART code, I created a usart module. I wanted to
wrap a gui around it , but I never did... The module is in CVS:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gpsim/modules/usart.cc
The top level comments describe the basic function of the module:
------------
gpsim's USART module
The USART module is a general purpose universal synchronous/asynchronous
serial receiver and transmitter. In other words, it's a serial port. It's
purpose is to provide a tool to assist in the debugging of serial
interfaces. Users can load this module and tie it to their receive and
transmit pins of their simulated PIC's. Then experiments can be conducted
on things like baud rate variation, transmit inundation, protocol
development, etc.
The design of this dynamically loadable module mimics the USART peripheral
found in PIC microcontrollers. In fact, the USARTModule class is derived
from the USART_MODULE class that is instantiated by simulated PIC's. There
are some notable differences, however. For example, the registers from
which the usart is constructed behave differently. Most notably, the spbrg
(serial port baud rate generator) is not confined to the limited number of
discrete baud rates.
-------------
Some of the features it has are:
- autobaud detection on receive
- all bit edges are timed
- data is logged at the bit level
- data can be displayed as bits or bytes. For bytes,
the baud rate can be selected.
I've been wanting to revisit this code ever since some has reported a bug
with the gpsim USART (essentially, the claim is that the usart behaves
differently depending on the order of initialization of the control
registers).
-------
Now that I've got SDCC fairly usable, I think I'm going to switch gears
back to gpsim for a while. I really want to get a new release with all of
the major enhancements Ralf has added over the last 6 months. I'd also
like to remove the readline dependency. I had slated that demolition for
April, but got side tracked by SDCC.
Scott
