[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
lcd module
From: Scott Dattalo ####@####.#### Date: 7 Feb 2000 06:12:11 -0000 Message-Id: <Pine.LNX.4.05.10002062348270.21219-100000@tempest.blackhat.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: lcd module
From: James Cameron ####@####.#### Date: 7 Feb 2000 06:47:47 -0000 Message-Id: <20000207173659.H1454@us.netrek.org> 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/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: lcd module
From: Scott Dattalo ####@####.#### Date: 7 Feb 2000 07:11:25 -0000 Message-Id: <Pine.LNX.4.05.10002070040180.22762-100000@tempest.blackhat.net> 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... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
LCD Module
From: Wayne Patterson ####@####.#### Date: 25 Nov 2002 00:01:37 -0000 Message-Id: <auto-000031177888@dc-mx14.cluster1.charter.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |