Just a thought, Why not put the low level stuff into it's own DLL? I
would think that would leave the option of using different low level
routines for different hardware.

You mentioned Tait style parallel programmers, but what about JDM
serial programmers, or some future USB or other programmers? I think
we're all aware that the parallel port is quickly becoming obsolete
(if not already), if your software only works with a p-port it'll be
obsolete before it's finished.

-Denny

> I started this message the other day, but I don't think that I
actually posted
> it. So apologies if this is a repost.
>
> One of my students is doing a port of picprg to Windows for a
semester
> project. picprg is Brian Lane's Linux software for programming PICs
using
> Tait style programmers hanging from the parallel port, such as my
Trivial
> Programmer. Our alpha version is working and we're planning on
releasing an
> interim version just as soon as the code to save the config settings
is done.
>
> The next stage is updating the programming algorithms so that all of
the chips
> that folks really want to use (18F, 16F819, 16F88, 16F648A, 16F87XA)
can be
> programmed. Our game plan is to separate each of the
program/read/verify
> routines into a DLL. That way a new programming algorithm can be
included by
> downloading a new DLL.
>
> In order to maintain dual system compatibility, we are compiling
with the
> MingW GCC compiler which has a compatibility layer for translating
Unix
> specific calls into Windows equivalents. The DLL builder works fine
BTW.
>
> So here's the problem. The programming software is divided into a
set of low
> level routines that twiddle the parallel port (vpp_on, bit_on,
bit_off and the
> like), and the high level routines that read/program the chip using
the low
> level routines. Since the low level routines are used by every
programming
> algorithm, and are used for auto chip detection, we are trying to
keep these
> in the main executable, only moving the high level routines to the
DLLs.
>
> The problem is how do you make callbacks into the main application's
low level
> routines from the high level routines in the DLL? Quick example:
>
> --------- main.c ------------------
>
> void vpp_on()
> {
>    // Code to turn the vpp bit on
> }
>
> main()
> {
>    // Load the DLL
>    read_pic(); // A routine in the DLL
> }
> -----------------------------------
>
> -----------testdll.c---------------
> int read_pic()
> {
>    // Read the chip. Calls vpp_on
>    vpp_on();
>    // ....
> }
> ------------------------------------
>
> Under Linux it's possible to tell the linker to export symbols from
the main
> executable so that they are visible from loaded shared libraries. So
the
> routine set above works fine. main calls read_pic int testdll and
testdll does
> a callback to vpp_on in the main executable.
>
> The documentation I've read on DLLs talks about import/export tables
that
> defines what the DLL uses or provides. But I can't find anything
that talks
> about an export table for an executable, only DLLs.
>
> I have my backup solution if I can't figure out how to do this: take
the low
> level routines and put them in a separate DLL that's linked to the
application.
> Since the DLL can have a export table, when the high level DLL is
loaded, the
> exported symbols from the low level DLL should be visible to it, so
that
> these routines can be called.
>
> Any suggestions on this would be appreciated. It's one of those
situations
> where I know what I want to do, I figure it can be done, but I just
don't
> program in Windows enough to figure out how to do it.
>
> Thanks,
>
> BAJ
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE
topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other
[BUY]:,[AD]: ->Ads
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads