Subject:
Re: lcd module
From:
####@####.####
Date:
8 Feb 2000 00:50:24 -0000
Message-Id: <8525687F.000395D8.00@csc.com>
James Cameron writes:
> 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.
Given that you are designing a generic interface I would separate the
functionality a bit. Give the functions generic names (calling the interface
function "lcd" is not good for a DS1821 module). For example
int Update_Module_Time(cycle when);
int Module_Transmit_Pins(pins *tx);
int Module_Receive_Pins(pins *rx);
The return value indicates whether the operation was successful or not (you
might want to simulate a module that hangs under certain situations). The
update_module_time function allows the module to do time dependent stuff,
separately from I/O events. Gpsim needs more information to do its job, i.e. how
long are the tx and rx arrays, how often should Update_Module_Time be called
(e.g. every cycle or every second). These could be communicated by the module to
gpsim with a status function, for example.
int Module_Status(int num_tx_pins, int num_rx_pins, int update_interval);
Mal Goris
__________________________________________________
CSC Australia
Ph: 02 9901 1324 Fax: 02 9901 1555 Email: ####@####.####
####@####.#### on 08/02/2000 08:44:35
To: ####@####.####
cc: (bcc: Mal Goris/AUST/CSC)
Subject: Re: lcd module
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
