gnupic: Thread: Programmable stimuli for gpsim?

Folks,

I've been looking at gpsim, and it's a great piece of software! So far,
I had followed my old dinosaur instict and done my debugging with
blinking LEDs, but this is much better.

For my project, however, the waveform stimuli provided by the program
are insufficient, since I must be able to simulate interaction with a
host processor (i.e. I'll need the stimuli not just to monkey a signal,
but the signal must be determined at run time, as it encodes commands
and responses from the host). Is there a way to attach an external
program to a collection of pins? It looks like it ought to be doable via
modules, but I'm not familiar with gpsim's internals (yet?) as to figure
out how it ought to be done.

If I'm not being clear as to what I mean, the general idea would be to
enable a filter-like program (i.e. one that reads from STDIN and writes
to STDOUT), which would be called from within gpsim. Communication with
the program would be via a simple ASCII-based protocol:

* The program initializes, and prints a ready message which contains the
protocol version number.
* Gpsim answers with an ACK, stating its own version. 
* The program sends a message (or series of messages) stating how many
pins the component it simulates has, how they are called, and their
initial I/O configuration
* From then on, gpsim tracks the signals connected to the program's
"input pins", and sends a signal update together with a clock timestamp
to the program each time any one of them changes, which the program
ACKs.
* Similarly, each time the computation of the value at one of the PIC's
input pins involves one of the program's outputs, a status query is sent
to the program, again together with a clock timestamp, to which the
program reports the value of all its output pins.
* Both the program's ACKs to signal updates and the signal reports from
the program would include syntax to optionally reconfigure its pins
(turn inputs into outputs, and viceversa).

Is this possible now, and it's just not documented? If not, could this
make it into the wish list?

	Fede

On 15 Dec 2002, Federico Heinz wrote:

> Folks,
> 
> I've been looking at gpsim, and it's a great piece of software! So far,
> I had followed my old dinosaur instict and done my debugging with
> blinking LEDs, but this is much better.

Never underestimate the power of a blinking LED!

> 
> For my project, however, the waveform stimuli provided by the program
> are insufficient, since I must be able to simulate interaction with a
> host processor (i.e. I'll need the stimuli not just to monkey a signal,
> but the signal must be determined at run time, as it encodes commands
> and responses from the host). Is there a way to attach an external
> program to a collection of pins? It looks like it ought to be doable via
> modules, but I'm not familiar with gpsim's internals (yet?) as to figure
> out how it ought to be done.
> 
> If I'm not being clear as to what I mean, the general idea would be to
> enable a filter-like program (i.e. one that reads from STDIN and writes
> to STDOUT), which would be called from within gpsim. Communication with
> the program would be via a simple ASCII-based protocol:
> 
> * The program initializes, and prints a ready message which contains the
> protocol version number.
> * Gpsim answers with an ACK, stating its own version. 
> * The program sends a message (or series of messages) stating how many
> pins the component it simulates has, how they are called, and their
> initial I/O configuration
> * From then on, gpsim tracks the signals connected to the program's
> "input pins", and sends a signal update together with a clock timestamp
> to the program each time any one of them changes, which the program
> ACKs.
> * Similarly, each time the computation of the value at one of the PIC's
> input pins involves one of the program's outputs, a status query is sent
> to the program, again together with a clock timestamp, to which the
> program reports the value of all its output pins.
> * Both the program's ACKs to signal updates and the signal reports from
> the program would include syntax to optionally reconfigure its pins
> (turn inputs into outputs, and viceversa).
> 
> Is this possible now, and it's just not documented? If not, could this
> make it into the wish list?

Fede,

This protocol is feasible with gpsim as it is now. gpsim can interface 
to external devices through its "modules" interface. This is how the the 
LED, LCD, UART and various other modules interface with gpsim. The 
undrelying approach is dynamic linking with dlopen. Modules are created as 
standalone libraries that are dynamically opened by gpsim.

From within gpsim type "help module". The help lists the options available 
to the module command. For example, you can load a module library, list 
its contents, and instantiate one (or more) objects. When a module is 
instantiated, gpsim can then interface to it using the "node" and "attach" 
commands. Think of "node" as a wire and "attach" as the solder. 

At a lower level, the modules are created as C++ objects that conform to 
an API exposed by gpsim. Look at src/modules.cc and src/modules.h for the 
definition and look at module/led.cc for an example on how it is used. 
This, unfortunately, is the extent of the documentation. But if you have 
questions, well, you know where to ask.


Scott