gnupic: lcd module
Subject:
Re: lcd module
From:
James Cameron ####@####.####
Date:
7 Feb 2000 22:55:19 -0000
Message-Id: <20000208094435.D1010@us.netrek.org>
Scott,
What you suggest can still be isolated to a call interface regardless of
how you implement it within it. The API decides whether to fork a
process and communicate with it.
You can use dlopen() to separate the functionality into a different file,
so that it is not included at run-time unless required.
It is not overhead and execution time that concerns me, but ease of
writing new code that uses the same interface to gpsim. If it is easy
enough, I might write a DS1820 interface.
My guess for an interface API for the LCD ... without seeing your code;
void lcd (cycle when, lcd_pins *tx, lcd_pins *rx)
Where tx are the pin states sent to the LCD, sourced by the PIC, sunk
by the LCD, and rx are the return states.
/* time since simulation start */
typedef unsigned long cycle;
/* pin states */
typedef enum pins {
low,
high,
open
}
/* collection of pins */
typedef struct lcd_pins {
pins rs, rw, e, db0, db1, db2, db3, db4, db5, db6, db7;
}
So gpsim would load tx.* with either low, high, or open, according to
what the output data and tristate latch are set to, not to mention the
wiring configuration. It would do this every cycle. The virtual LCD
panel would respond with how it drives the pins in response.
You don't need to tell me if I'm barking up the wrong tree, as the aim
of describing this is so that you can see what one person would expect
in the way of an API.
--
James Cameron ####@####.#### http://quozl.us.netrek.org/
