gnupic: Thread: No more troubles in compiling gpsim

Hello,

IT WORKS !! :-D. I've installed popt-1.5-0.1. I first tried with
popt-1.4-1.1, which is provided with Debian 2.2r0, without success.
A first thing, there's no gpsim.ps in the doc directory :-(. I've
downloaded it from your website.
A second thing: is there a way to have time simulation while running?
A third thing: I need recompilation if I want to change fonts size?
A fourth one: do you think it's possible to have a kind of I2C loopback
in the Linux kernel to communicate between simulator and other softwares
?

Certainly many other things to come...

I think I'll like gpsim. I thank you for all the help you provided ( I
hope I don't write too bad :-) ).

Bye

Vincent

On Mon, 9 Jul 2001, Vincent Besse wrote:

> Hello,
>
> IT WORKS !! :-D. I've installed popt-1.5-0.1. I first tried with
> popt-1.4-1.1, which is provided with Debian 2.2r0, without success.
> A first thing, there's no gpsim.ps in the doc directory :-(. I've
> downloaded it from your website.

Vincent,

You get an A+ for perserverance! Most people would've quit much sooner.

> A second thing: is there a way to have time simulation while running?

That's the second request for that feature in a week. I've got an idea for it
but I've haven't implemented it yet.

> A third thing: I need recompilation if I want to change fonts size?

That sucks. You probably had to edit the code too since the font types and sizes
are called out in the code. Maybe we can coax Ralf into putting that info in the
gpsim configuartion file.

> A fourth one: do you think it's possible to have a kind of I2C loopback
> in the Linux kernel to communicate between simulator and other softwares
> ?

I'm working on the uart one as we speak. (In fact I've been working on it too
long.) What I'm doing has nothing to do with the Linux Kernel per se, but it
could. gpsim supports dynamically loadable modules. I'm working on a USART one
that is capable of interfacing to a PIC and capture/decode byte streams. It does
not implement the transmitter yet, but that part's easy... (Writing an
autobauding routine has proven to be extremely difficult).

In theory, the USART routine could interface to a real serial port. So for
example, bytes transmitted from a simulated PIC could be redirected to
/dev/ttyS0 and vice versa.

The USART module could easily be modified into an I2C module.

BTW, if you're curious, here's a debug screen shot of the usart module in
action:

Minimum pulse width 10 Baud = 250000
 !! Found a valid byte !!
 Captured Start bit time vs calculated start bit time
0x5656c vs 0x5656c
 time: 0x565f4 evt index: 0xc6
 time: 0x565e4 evt index: 0xc6
 time: 0x565d4 evt index: 0xc6
 time: 0x565c4 evt index: 0xc5
 time: 0x565b4 evt index: 0xc5
 time: 0x565a4 evt index: 0xc4
 time: 0x56594 evt index: 0xc4
 time: 0x56584 evt index: 0xc4
 time: 0x56574 evt index: 0xc3
Most recent byte: 0x31
ascii art
minimum pulse width :10

___----____--------------------------------------------------
--------------------------------________------____-----------
-------------------------------------------------------------
------------__--____------____-------------------------------
-----------------------------------------------------__--____
______--__---------------------------------------------------
-------------------------------____--________--__------------
-------------------------------------------------------------
-----------__----________--__--------------------------------
--------------------------------------------------______--___
___--__------------------------------------------------------
------------------------------__--__--______--__-------------
-------------------------------------------------------------
----------____----______--__---------------------------------
-------------------------------------------------__________--
--____-------------------------------------------------------
----------------------------__--______----____---------
end of ASCII art

This shows the history of the uart receive line (the PIC's tx line).
The history shows the bytes 0x42, 0x43, 0x44, 0x45, 0x46, 0x30 and
the byte decoded, 0x31


I'd like to have a gui waveform viewer, but it's too much trouble at the moment.

---
Scott

Dears picers
    I have the following problema with te picp for the PICSTART PLUS the
picp dont recognize the pic 16f873 please some help. and thank in advance.

Luis Muñoz
####@####.####
www2.netexplora.cl/osmax68

----- Original Message -----
From: "Scott Dattalo" ####@####.####
To: "Vincent Besse" ####@####.####
Cc: ####@####.####
Sent: Monday, July 09, 2001 12:53 AM
Subject: Re: No more troubles in compiling gpsim


>
>
> On Mon, 9 Jul 2001, Vincent Besse wrote:
>
> > Hello,
> >
> > IT WORKS !! :-D. I've installed popt-1.5-0.1. I first tried with
> > popt-1.4-1.1, which is provided with Debian 2.2r0, without success.
> > A first thing, there's no gpsim.ps in the doc directory :-(. I've
> > downloaded it from your website.
>
> Vincent,
>
> You get an A+ for perserverance! Most people would've quit much sooner.
>
> > A second thing: is there a way to have time simulation while running?
>
> That's the second request for that feature in a week. I've got an idea for
it
> but I've haven't implemented it yet.
>
> > A third thing: I need recompilation if I want to change fonts size?
>
> That sucks. You probably had to edit the code too since the font types and
sizes
> are called out in the code. Maybe we can coax Ralf into putting that info
in the
> gpsim configuartion file.
>
> > A fourth one: do you think it's possible to have a kind of I2C loopback
> > in the Linux kernel to communicate between simulator and other softwares
> > ?
>
> I'm working on the uart one as we speak. (In fact I've been working on it
too
> long.) What I'm doing has nothing to do with the Linux Kernel per se, but
it
> could. gpsim supports dynamically loadable modules. I'm working on a USART
one
> that is capable of interfacing to a PIC and capture/decode byte streams.
It does
> not implement the transmitter yet, but that part's easy... (Writing an
> autobauding routine has proven to be extremely difficult).
>
> In theory, the USART routine could interface to a real serial port. So for
> example, bytes transmitted from a simulated PIC could be redirected to
> /dev/ttyS0 and vice versa.
>
> The USART module could easily be modified into an I2C module.
>
> BTW, if you're curious, here's a debug screen shot of the usart module in
> action:
>
> Minimum pulse width 10 Baud = 250000
>  !! Found a valid byte !!
>  Captured Start bit time vs calculated start bit time
> 0x5656c vs 0x5656c
>  time: 0x565f4 evt index: 0xc6
>  time: 0x565e4 evt index: 0xc6
>  time: 0x565d4 evt index: 0xc6
>  time: 0x565c4 evt index: 0xc5
>  time: 0x565b4 evt index: 0xc5
>  time: 0x565a4 evt index: 0xc4
>  time: 0x56594 evt index: 0xc4
>  time: 0x56584 evt index: 0xc4
>  time: 0x56574 evt index: 0xc3
> Most recent byte: 0x31
> ascii art
> minimum pulse width :10
>
> ___----____--------------------------------------------------
> --------------------------------________------____-----------
> -------------------------------------------------------------
> ------------__--____------____-------------------------------
> -----------------------------------------------------__--____
> ______--__---------------------------------------------------
> -------------------------------____--________--__------------
> -------------------------------------------------------------
> -----------__----________--__--------------------------------
> --------------------------------------------------______--___
> ___--__------------------------------------------------------
> ------------------------------__--__--______--__-------------
> -------------------------------------------------------------
> ----------____----______--__---------------------------------
> -------------------------------------------------__________--
> --____-------------------------------------------------------
> ----------------------------__--______----____---------
> end of ASCII art
>
> This shows the history of the uart receive line (the PIC's tx line).
> The history shows the bytes 0x42, 0x43, 0x44, 0x45, 0x46, 0x30 and
> the byte decoded, 0x31
>
>
> I'd like to have a gui waveform viewer, but it's too much trouble at the
moment.
>
> ---
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

On Sun, Jul 08, 2001 at 11:53:11PM -0500, Scott Dattalo wrote:
> 
> > A third thing: I need recompilation if I want to change fonts size?
> 
> That sucks. You probably had to edit the code too since the font types and sizes
> are called out in the code. Maybe we can coax Ralf into putting that info in the
> gpsim configuartion file.

It sure does suck. I'll see what I can do after my vacation (2 weeks).

 / Ralf

On Sun, Jul 08, 2001 at 11:53:11PM -0500, Scott Dattalo wrote:
> 
> 
> On Mon, 9 Jul 2001, Vincent Besse wrote:
> > A third thing: I need recompilation if I want to change fonts size?

I've been kind of busy. But, which fonts would you like to be able to
change?

> 
> That sucks. You probably had to edit the code too since the font types and sizes
> are called out in the code. Maybe we can coax Ralf into putting that info in the
> gpsim configuartion file.

I thought that I'd use the gtk font selection dialog, but I'll have to 
find out how to filter the fonts. I want to filter out non-fixed-width
fonts.

I was planning to have it done by now, but I haven't even started. It'll
take another few weeks.

 / Ralf