gnupic: No more troubles in compiling gpsim
Subject:
Re: No more troubles in compiling gpsim
From:
Scott Dattalo ####@####.####
Date:
9 Jul 2001 04:45:33 -0000
Message-Id: <Pine.LNX.4.33.0107082327300.28089-100000@tempest.blackhat.net>
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
