gnupic: Dynamic Libraries in gpsim
Subject:
Dynamic Libraries in gpsim
From:
Scott Dattalo ####@####.####
Date:
24 May 2000 11:57:32 -0000
Message-Id: <Pine.LNX.4.21.0005240633540.15885-100000@tempest2.blackhat.net>
It's been quiet, but I haven't given up working on gpsim - just in case anyone's
wondering.
But it's been a while since I've said anything about gpsim, so here's a brief
update.
I've been working on dynamic library support. I'm essentially implementing what
James Cameron and others suggested a couple of months ago. While I won't bore
you with the details of my inexperience in this style of programming, it's
sufficient to say the learning curve has been rather steep. But I think the peak
is in sight and this is what I've got so far (this is NOT in CVS):
I've got an example library that consists of a single Module that I've
creatively named Binary_Indicator. This library is built along side of gpsim,
but it's otherwise totally separate. So when you type make followed by make
install, the gpsim code and this new library will be built and installed.
I've added a new command to the cli called module. The help for it is:
module [ [load module_type [module_name]] | [lib lib_name] | [list] |
[[dump | pins] module_name] ]
If no options are specified, then the currently defined module(s)
will be displayed. This is the same as the `module list' command.
The `module load lib_name' tells gpsim to search for the module
library called `lib_name' and to load it. (Note that the format of
module libraries is exactly the same as a Linux shared library. This
means that the module library should reside in a path available to
dlopen(). Please see the README.MODULES in the gpsim distribution.
To instantiate a new module, then type
module module_type module_name
where module_type refers to a specific module in a module library
and module_name is the user name assigned to it.
Information about a module can be displayed by the commad
module module_name [dump | pins]
where module_name is the name that you assigned when the module
was instantiated. The optional dump and pins identifiers specify
the information you wish to display (dump is the default).
examples:
module // Display the modules you've already
defined.
module lib my_mods.so // Load the module library called my_mods.
module list // Display the list of modules supported.
module load lcd my_lcd // Create an instance of an 'lcd'
module pins my_lcd // Display the pin states of an instantiated
module
module load lcd lcd2x20 // Create a new module.
module load led start_light // and another.
Ideally, one would use the module command as part of a start up script. But the
intent is to have this one command load libraries, list the contents of
libraries, and to load specific modules within libraries.
Much of this is working right now. However, it's not very useful. The next step
will be to continue massaging gpsim's infrastructure to make use of these
external modules. I've already begun to do this somewhat. For example, it used
to be that the pic_processor class served as the base class for all pic
processors. Well, I've now added a new class called Modules and have wedged
beneath the pic_processor class. The intent here is to leverage off all of the
gpsim code that supports the pic_processor infrastructure. For example, a module
will have the ability to instantiate file_registers and use the break point
mechanisms that gpsim provides. I'm not pretending to say that this will be
trivial. There's still quite a bit of work that needs to be accomplished
first (especially with stimuli).
Once I get the module infrastructure stabilized I'll check it into CVS. I
wouldn't expect a new release for at least month (especially since I'll be out
of town for a week too).
Scott
