gnupic: No more troubles in compiling gpsim
Subject:
Re: No more troubles in compiling gpsim
From:
Luis ####@####.####
Date:
10 Jul 2001 18:37:40 -0000
Message-Id: <001601c1096f$638e3b10$7abefea9@jimena7gmz3kv1>
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: ####@####.####
>
