gnupic: Thread: lcd module

As I mentioned briefly the other day, I was going to start working on a
simulated lcd module that can interface to gpsim. You can see a screen
shot and the very first glimpse of the code:

http://www.dattalo.com/gnupic/lcd.html

I only post this stuff to get some feed back. As it stands, it's pretty
damned rough right now.

The goal is to ultimately get the LCD module and gpsim interfaced through
some sort of IPC (inter process communication). I'm still not set on how
this going to be exactly done. The first version will most certainly be a
shared library (hardly ipc, but it's a first step) linked directly to
gpsim.

This version has no provisions for or intentions of supporting IPC. It
only is the gui side of the LCD. I've focused most of my efforts (all 5 or
6 hours) in to making the code somewhat flexible. We all know how many
different variations of LCDs are out there. Hopefully all of the character
types are easily supported with the model that's been created.

Some of the things that have been parameterized are:

size of the display (rows and columns)
size of a character cell
size of the display when drawn on the crt. (The character bitmaps are
scalable).
colors
fonts

Anyway, take a look and tell me what you think.

Scott

I see no reason why you would need to implement it as a separate
process.  Can you suggest any?

-- 
James Cameron   ####@####.####   http://quozl.us.netrek.org/

On Mon, 7 Feb 2000, James Cameron wrote:

> I see no reason why you would need to implement it as a separate
> process.  Can you suggest any?

Yes. Perhaps not good ones, but I can suggest some.

From day one I've wanted gpsim to be able to be extendable and support
modules that are not necessarily pic related. I also eventually would to
create an infrastructure that others may easily add new modules to without
having to know all the intricacies of gpsim. This certainly could be
accomplished through a well documented api (and it's in fact how the gui
talks to the simulator now [I mean there's an api, it ain't documented by
any stretch]). However, a fairly complex module like the LCD would expose
all of the details required to achieve this goal.

Having a modular interface would allow others to distribute modules
without (in theory) having to worry about patching gpsim, or forcing
others to recompile. It's not a big deal now, because gpsim is so
unstable. There's a new release every few days it seems just to keep it
from falling over. But once it becomes more stable, I expect the release
frequency to drop off. If that stage is ever reached, it'd be convenient
(but not necessary) to simply add modules to your module library much like
you add .el files to configure emacs.

I know the counterpoints. An IPC will slow things down, all the modules
can be built into gpsim and selected with a script, probably only me and
maybe one other person in the world will actually ever right any modules,
...

I also know that it's past 1:00am and that I've been up for close to 20
hours...

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/

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: ####@####.####

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

Has anyone got the LCD Module working with gpsim 0.20.14?
This is what I end up with after configure:
 
lcd-0.1.1 is now configured for

  Source directory:     .
  Installation prefix:  /usr/local
  C compiler:           gcc  -g -O2
  C++ compiler:         c++  -g -O2

  gui:

I have a few lines that end in "no"  they are as follows:

checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking for working const... (cached) no
checking for inline... (cached) no
checking for working alloca.h... (cached) no

What am I missing?
Thanks for any help!
Wayne