gnupic: Thread: gpsim CVS

After a four day delay or so, the gpsim CVS repository is finally
browsable.

(P.S. Eric Smith - My response to your CVS question bounced.)

As I said before, in lieu of micro-releases, we'll instead refer everyone
to CVS. So for the first referal...

Today's CVS contains new support for PORTD and PORTE in the 14bit core.
The associate peripherals like PSP are not yet supported. However, you
should be able to attach stimuli to these ports just like you would to the
others. 

Also in CVS is support for miscellaneous pin access functions. This is
primarily for Ralf so that he may get access to: pin directions, pin
states, and pin names. Support functions exist for changing pin
directions (this means that if you change the direction of an I/O port,
that change will be propogated to the associated tris register). A
cut-n-paste from interface.h:


//---------------------------------------------------------------------------
// pin interface functions
//---------------------------------------------------------------------------
  void  gpsim_assign_pin_xref(unsigned int processor_id, unsigned int pin,
gpointer xref);
  unsigned int  gpsim_package_pin_count(unsigned int processor_id);
  char *gpsim_pin_get_name(unsigned int processor_id, unsigned int pin);
  unsigned int  gpsim_pin_get_value(unsigned int processor_id, unsigned
int pin);
  void  gpsim_pin_set_value(unsigned int processor_id, unsigned int pin);
  unsigned int  gpsim_pin_get_dir(unsigned int processor_id, unsigned int
pin);
  void  gpsim_pin_set_dir(unsigned int processor_id, unsigned int pin,
unsigned int new_dir);


Scott

gpsim CVS now has a gui trace window. This is NOT the graphical waveform window.
Instead, it's a simple gui representation of cli trace dump. The main difference
is that the trace window is automatically updated when you single step. I still
need to add the code to update the window after the simulation has been running
for a while. I also want to add color coding (e.g. to highlight the
instructions, or color-code reads and writes) and I want to add filtering.  
0.21.0 will be released within 2 weeks (probably).

Scott

Now in CVS:

Added 18c442,18c452 processor
Patches from Salvador  ####@####.#### to A2D,window management, and
 miscellaneous. 
Patch from JG for Suse 7.1. (Though commented out at the moment...)
Fixed WDT during SLEEP bug reported by Tor Fredrik Aas ####@####.####


Scott

"Real time"
Salvador has submitted a patch that displays the simulation time in the status
bar (previously, gpsim only displayed the number of instruction cycles). There
are four different formats selectable from a popup menu.

"frequency" command
Salvador has added a "frequency" command that allow you to control the
simulation frequency. gpsim's time is still instruction cycle based, but expect
some of the timing to be expressed in terms of seconds shortly.

"Pullup/Pulldown Resistors" Salvador had submitted a patch that added two new
commands called pullup and pulldown. After some discussion, I took this idea and
instead implemented it with gpsim's modules. So like the LEDs and LCDs, you can
now instantiate resistors and attach them to PIC I/O lines. Unlike the LCD and
LED, the resistor has no gui counterpart.

There's a new subdirectory: examples/modules/ that for now contains one project
subdirectory called "mod_test". The project is structured similar to the way
Craig has structured the gpasm examples. You can see it here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gpsim/examples/modules/mod_test/

It illustrates four resistors tied to PORTB on a 16c84.

I've added a new option to the module command that allows you to now set module
attributes. This was inspired with the need to modify the resistor module's
resistance, however it's going to play an important role for controlling
modules. (For example, I'm going to revist the stimulus sources and move them
all to modules. Their behavior will be controlled via the set attribute
interface.)

Scott

G'day all,
Just trying Gpsim for the first time in a while.
Compiled and installed fine on a Debian Woody system,
simply had to apt-get install libpopt-dev.

Is there a known bug with the uart emulation regarding
fast baud rates?
With a Pic 16f877
I'm emulating a crystal speed of 12.228Mhz with
BRGH=1 and SPBRG=2. This should give me about 255kBaud

Gpsim reports about 188uS for a byte, when it should be
about 43uS.
SPBRG=1 give me about 118uS which is way high..

I have a breakpoint set on the tx Isr and stopwatch between
breakpoints.

Is there anyway to watch the internal state of the uart, 
or breakpoint on it's output pin changing?
I tried setting a break on portc writes, and port c values
but no joy. I tried looping the tx pin to a portd pin and
setting a breakpoint on that also. No go..

Great work BTW. The combo of gpasm/gpsim/picp has just about
obsoleted mplab for me. Just need to add a 16f876 to gpsim :p)

I may look at that if I can find some time.

-- 
Brad....
                   /"\
Save the Forests   \ /     ASCII RIBBON CAMPAIGN
Burn a Greenie.     X      AGAINST HTML MAIL
                   / \

On Wed, 7 Aug 2002, Brad Campbell wrote:

> Is there a known bug with the uart emulation regarding
> fast baud rates?

There are no known bugs, but this section of gpsim hasn't been thoroughly 
tested.

> With a Pic 16f877
> I'm emulating a crystal speed of 12.228Mhz with
> BRGH=1 and SPBRG=2. This should give me about 255kBaud
> 
> Gpsim reports about 188uS for a byte, when it should be
> about 43uS.
> SPBRG=1 give me about 118uS which is way high..
> 
> I have a breakpoint set on the tx Isr and stopwatch between
> breakpoints.
> 
> Is there anyway to watch the internal state of the uart, 
> or breakpoint on it's output pin changing?

No, unfortunately.

> I tried setting a break on portc writes, and port c values
> but no joy. I tried looping the tx pin to a portd pin and
> setting a breakpoint on that also. No go..

You may wish to examine the undocumented usart module:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gpsim/modules/usart.cc

This code was useful in debugging gpsim's USARTs. This code illustrates 
how the individual bits of a serial line can be captured. There is also an 
algorithm for autobaud detection. 

> Great work BTW. The combo of gpasm/gpsim/picp has just about
> obsoleted mplab for me. Just need to add a 16f876 to gpsim :p)
> 
> I may look at that if I can find some time.


Cleaning up the Serial Port module has been one of things I've been 
wanting to do for a long time. However, SDCC has consumed most of my free 
time lately.

Scott

For two days now I've been attempting to access gpsim's CVS repository on
Source Forge, but have been unable to. I've heard about others having
trouble accessing it, but it's now to the point where it's not usable. If
this keeps up much longer, gpsim will be moving to another repository.

So far, I know of at least one other possible place to move, and that's to 
SEUL where gEDA is located. I have not contacted Ales, the administrator, 
but he did make a public offer to accept other projects the other day. 

But before embark upon something fairly drastic, let me ask for some 
advice:

1) Should I just wait and do nothing?
2) Is there another CVS repository that others know?


Scott

There is also Savannah.

http://savannah.gnu.org/

RMS gave us the OK to call our project gnupic, right?  So we it seems
like using Savannah shouldn't be a problem.

I considered using it when I merged gpasm into the gputils package. 
Many people were concerned about the direction SourceForge was going. 
They were closing the source to some of the tools for project
management.  I decided to stay.  I haven't keep up with the it.

I haven't had any problems with Sourceforge.  The download statistics
have been wrong for a couple of monthes, but I don't really care about
that.  How do you have your cvs access setup?  Apparently there is a
limit on the number pserver connections.  The link below explains it.  

https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1

Use SSH based access if you can.  That is what I use.  I haven't had any
problems.  I just tested it.  I tried pserver access:

cvs -z3
####@####.#### co
gputils

and I get the message:

cvs [checkout aborted]: end of file from server (consult above messages
if any)

I tried SSH access:

export CVS_RSH="ssh"
export
####@####.####

cvs checkout gputils

and it worked.

On Fri, 2003-06-27 at 12:10, Scott Dattalo wrote:
> For two days now I've been attempting to access gpsim's CVS repository on
> Source Forge, but have been unable to. I've heard about others having
> trouble accessing it, but it's now to the point where it's not usable. If
> this keeps up much longer, gpsim will be moving to another repository.
> 
> So far, I know of at least one other possible place to move, and that's to 
> SEUL where gEDA is located. I have not contacted Ales, the administrator, 
> but he did make a public offer to accept other projects the other day. 
> 
> But before embark upon something fairly drastic, let me ask for some 
> advice:
> 
> 1) Should I just wait and do nothing?
> 2) Is there another CVS repository that others know?
> 
> 
> Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

On 27 Jun 2003, Craig Franklin wrote:

> There is also Savannah.
> 
> http://savannah.gnu.org/
> 
> RMS gave us the OK to call our project gnupic, right?  So we it seems
> like using Savannah shouldn't be a problem.

Yes he did. Actually I spoke mostly with Bruce.

> 
> I considered using it when I merged gpasm into the gputils package. 
> Many people were concerned about the direction SourceForge was going. 
> They were closing the source to some of the tools for project
> management.  I decided to stay.  I haven't keep up with the it.
> 
> I haven't had any problems with Sourceforge.  The download statistics
> have been wrong for a couple of monthes, but I don't really care about
> that.  How do you have your cvs access setup?  Apparently there is a
> limit on the number pserver connections.  The link below explains it.  
> 
> https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1
> 
> Use SSH based access if you can.  That is what I use.  I haven't had any
> problems.  I just tested it.  I tried pserver access:
> 
> cvs -z3
> ####@####.#### co
> gputils
> 
> and I get the message:
> 
> cvs [checkout aborted]: end of file from server (consult above messages
> if any)
> 
> I tried SSH access:
> 
> export CVS_RSH="ssh"
> export
> ####@####.####
> 
> cvs checkout gputils
> 
> and it worked.


And this worked for me too! Thanks Craig. I just checked in a few fixes.

Scott