Re: Dynamically loading a static C library (compiler suggestion?)

In article <0ea9d309-782c-4eb4-95e0-349e074da43d@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
nleschov@xxxxxxxxx writes:

Hello again,

First, I want to thank all of you for rushing out to help me, though I
supplied so little clues. I really wanted not to bother you with
unneeded details that could possibly lead the discussion to the wrong
path, but in fact said not enough to be understood.

So, let me clarify the situation:

I am programming a microcontroller, ICPDAS i-8411 to be exact. (http://
www.icpdas.com/products/PAC/i-8000/i-8411-i-8811.htm)
Microcontroller not in the sense of "Embedded CPU" but "a small box".
A box has slots: one for CPU board and several more for I/O boards.
From the programmer's point of view microcontroller is a PC. It has:
- i186-compatible CPU; 512K RAM

The reference you gave suggested 80188, but from a programming
viewpoint that should not be a problem.

- 512K flash-based disk with simple filesystem
- DOS-compatible OS in boot sector
- some specific devices

Manufacturer suggests using one of the following compilers:
- Borland C++ 3.1~5.02
- MSC 6.0
- MSVC (before version 1.52)
- TC 2.01 (*available for free)
- TC++ 1.01 (*available for free)
and supplies a system library for their controller for use with one of
the above compilers. Library doesn't have source and comes as .lib
and .h files. I also have some of the above compilers .

Have you tried contacting the supplier to see if the C source is
available? If it is, that will save you some time. Of the
compilers you mention, I have only experience of MSC (5.1) and
BC++ 3.1; both would appear to me adequate though Borland would
get my vote for such a development.

So, the proposed design cycle looks like this:
I write my program in 'C' and link against the manufacturer's library
with one of recommended compilers, on Windows PC (maybe even in a DOS
box). Then I transfer binary file to microcontroller using
manufacturer's terminal program. I run it. Repeat until satisfied with
result.

Is there any possibility of expanding the "disk" to a few MB? If
so, you might even consider installing the compiler there and
doing the development locally -- these "old" compilers take up a
fraction of the disk space of more modern ones... Probably
though you will be stuck with the external build/transfer/run
cycle.

There are 2 major problems for me:

1. Proposed compilers are all old cruft.

"old" != "cruft". If they work and produce efficient binaries
don't knock them ;-)

I would like to use more up-to-date tools for programming my embedded
PC. I want something that is at least either (a) non-proprietary or
(b) modern, or both. The best I saw is Borland C++ 5.02 (in the modern
department, but still it could use some improvement)

No experience of 5.02 but I cannot imagine it being any less
capable than 3.1 -- what improvements did you have in mind?

And how do you
obtain license for the compilers _that_ old? Will Borland or Microsoft
grant me license for them tomorrow? (or even today) Will DOS compilers
run on my computers tomorrow? (or even today)

2. No debugging.
It doesn't need explaining, I guess. Debugging is good.

I assume you mean a debugger that will run on the microcontroller?
It might be worth asking around in one of the "embedded" groups
for advice there (even though you say your app is not embedded).

So I started to think about using a Forth system on this controller. I
can choose a free as in freedom Forth for DOS, put it on controller's
disk and if I find a way to use system library from it, I'll be fine.
With a little modification, I hope, I will have a license-free
development environment with debugging. I'll also have the bonus of
the compiler on the target, just in case.

I want to use the supplied library because as opposed to
microcontroller as "Embedded CPU", I don't have the data*** for all
my hardware. I don't get schematics, it's not practiced in the case of
microcontrollers in the sense of "small box". Instead, I get system
library that should fit a lineup of controllers.

So, I thought that maybe I should dynamically load the system library
and gain acess to its functions. From what I gather LIB is a
collection of OBJ files in the OMF format, developed by Microsoft, but
later standardized. I found a bunch of information here, on the 'D'
community forum: http://www.dsource.org/forums/viewtopic.php?t=959
Seems that if no one else, developers of exotic languages confront
this problem?

The libs are [almost certainly] OMF-format OBJ files; these are
not executable so dynamically loading them in this format would
be a non-starter, unless of course your code can handle linking
them and carrying out the fixups on-the-fly. If you want to
"execute" them in a foreign environment, an alternative approach
would be to extract the objs from the lib (you'll need LIB.EXE or
something similar) and then recreate the [asm] source with e.g.
obj2asm. You would then be able to see how the passed params are
used and what the functions actually do with the hardware, giving
you the chance to recreate their functionality in whatever other
language. How legal this would be I have no idea, and getting
hold of the original C source would be far better.

Either that, or I could use a better development environment for 16-
bit DOS. (But the debugging is out of the question, as I understand)

Assuming you will be calling/using services on the microcontroller
that don't exist in a "PC", debugging on the latter could prove
troublesome. But heh, if you can attach a serial monitor to this
device, with #IFDEF DEBUG and printf() what more could you need?

;-)

Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
.