Subject:
Re: lcd module
From:
Scott Dattalo ####@####.####
Date:
8 Feb 2000 13:38:43 -0000
Message-Id: <Pine.LNX.4.05.10002080611430.8026-100000@tempest.blackhat.net>
On Tue, 8 Feb 2000, James Cameron wrote:
> 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.
James,
You DO have a way of exposing my system level programming in-experience!
This looks like a MUCH better solution than any of the ones that I've seen
so far. It satisfies two criteria: it separates gpsim from the modules and
it's fast. In fact, it's probably the fastest way short of directly
linking with the module libraries.
> 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.
and then
On Tue, 8 Feb 2000 ####@####.#### wrote:
> 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,
I was thinking about an implementation similar to yours. It's slightly
different so that it can utilize gpsim's internal event driven processing
algorithms. Essentially I'm thinking about a two-staged interface. First
there's the initialization phase where the various nodes of the module and
the pic are interconnected. And then there's simulation phase where data
between the two are exchanged.
For the initialization phase, I'm thinking about creating an API that the
module may use to register all of it's nodes (or pins if you prefer). Each
node has type information associated with it (e.g. input, output,
bi-directional, analog, etc.). All of the nodes will be collected together
to form a 'bus'. For purely digital interfaces, the information on the bus
will be sent back and forth as an integer. The module will specify how the
nodes are mapped to the bus. For example, with the LCD you could define
all your nodes (data lines, E, R/W, D/C and perhaps pwr and gnd) and then
map these into the bus such that the bit position on the bus corresponds
with the pin number on the LCD interface. If there are more than 32 nodes
in the module, then there are simple tricks to extend this (e.g. msb could
be use as flag to indicate that there are more nodes than can be contained
in one integer, or we could use 64bit integers, etc...). I haven't thought
about how to convey analog information yet (perhaps the already existing
analog stimulus code may be used).
The goal of the initialization phase is to convey all of the time
consuming information up front so that during run time the information may
be efficiently exhanged between gpsim and the module. Once the
initialization is done, then I envision an interface like what you're
proposing but with a gpsim twist.
gpsim is an event driven behavioral simulator. The timing for all events
is directly derived from the simulation frequency, or more specifically
the pic's cycle counter. (I've been exploring ideas on separating the
event drive time base from the pic so that variable frequency clocks may
be used, but for now...) The way a pic peripheral creates and responds to
events is by interfacing with pic cycle counter. As an example, consider
the tmr0 peripheral. When first initialized, it will create something I
call a 'cycle breakpoint'. Associated with this is a call back function
that is invoked when the cycle is encountered. So tmr0 knows the cycle at
which it will rollover and will set a cycle break point at that cycle.
When the call back routine is invoked, then tmr0 will do what it has to do
when a rollover occurs (like perhaps setting an interrupt flag or
something) and then set a new break point for the next roll over cycle.
The module interface will be similar. When first initialized, it will
specify the cycle when it wishes to receive attention ( which could be no
cycle for a purely passive module like a 7-segment display). When that
cycle is encountered then the callback function will be invoked.
Now sending data to and from the module will be different than
communicating with a peripheral such as tmr0. What I was thinking here is
to tie into the stimulus infrastructure that exists with gpsim. gpsim
already has the capability to respond to stimulus changes. For example, if
you created a node that tied porta-0 to portb-0 and programmed the pic to
make a-0 an output and b-0 an input that will generate an interrupt on
change, then toggling porta-0 will cause an interrupt. The stimulus
infrastructure is capable of detecting changes and responding to them.
So for example, if we tied the LCD data bus to port B, then whenever port
B is written to, the LCD module interface will be notified. The way this
notification will occur is:
update_module(time, bus)
The module will receive this information and respond to it accordingly.
For example, the LCD will probably have some kind of state machine that
responds to specific changes such as E changing states. The module will
have two functions for talking to gpsim:
update_bus(new_bus_value)
and
call_me_when(time)
The 'update_bus' will allow the module to respond instantaneously to
changes sent to it by the update_module function (dead lock mechanisms
will have to be put into place...). The time of these changes is now - or
the current value of the cycle counter. The 'call_me_when' function will
be used to obtain control at a specific time. For example, if the LCD
module state machine determines that the bus interface is requesting data
to be read from character memory, then the call_me_when function will tell
gpsim to call the module back when the data is ready. When the call back
occurs, the module will respond with an update_bus() and/or a
call_me_when(). It might make sense to create another function that
combines these two operations into one.
A ModuleStatus(), like Mal suggests, could be useful for the gui to get
specific information about the module that is otherwise unavailable. For
example, if you wanted to know what state the LCD module is in, perhaps
you could query that information through the ModuleStatus(). A reciprocal
function like SetModuleState() could be useful to control the behavior of
the module. For example, if you were trying to create custom LCD
characters, you migh like to have the ability to directly write to the
character ram without having to go through the module interface. There are
many possibilities here.
Scott
