In alt.fan.frank.mccoy Öldman© <b@ld.is.best> wrote:
>On Sat, 24 Jul 2004 11:19:02 -0500,Frank McCoy's cat ran across
>the 'puter keyboard and out came...
>} In alt.fan.frank.mccoy �ldman© <b@ld.is.best> wrote:
>}
>} >} However, still missing, is the "filename.h" file.
>} >} Encountered a slight difference in compilers, where structures were
>} >} being done before the call to the include file that defined them; and
>} >} that was a no-no to my compiler. However, that was an easy fix; just
>} >} moving the global definitions after the include files.
>} >}
>} >} However, can't go any further without the filename.h definitions.
>} >}
>} >}
>} >the file you refer to was PART of the original post of
>} >the C code.
>} >
>} >I marked the two files with a comment bof and eof and a line of 8's
>} >
>} >you need to copy them individually into notepad and create the TWO
>} >files "customer.c" and "filename.h".
>} >
>} >Which compiler are you using?
>} >
>} >The included complier in the zipped file "Microtec C Tools" is the
>} >only one that is going to work with these source files.
>} >
>} >Look at my post of the C Tools again- both are on my server.
>}
>} Well ... It compiles a lot better now that I have the filename.h file.
>} Thouhg I don't have the Microtec compiler, it still checks out fairly
>} well, except for one missing definitin: _iob
>}
>} I presume that's part of your standard stdio.h file ... Probably
>} because of a slight difference between your compiler and mine.
>} I suspect that if you could send me just a copy of the stdio.h file, I
>} could get it to compile so I could make changes and check them.
>}
>} The stdio.h file comes with the compiler, unlike the other include
>} file. It's most likely in the "include" directory just above your
>} compiler.
>}
>} Might need io.h too.
>} Sometimes stdio.h makes reference to that.
>} I *can* make it work without that though, just by defining _iob, which
>} is just a pointer to COM0-COM4. Still, it would probably be better to
>} use the same definition.
>}
>}
>Being that the output of the compiler is all important - machine code
>that directly addresses the I/O registers of the CPU - Borland will
>not work as it compiles for xxx386 processor.
>
I know that.
*BUT*, it should do just as good as an *error checker* for code I
write; since in neither case can I execute the code.
IOW, "Is it good 'C' code?"
Not, "Does it work?"
Without the target machine here to run it on, and an application to
run the target machine on, the best I can do HERE, is write what I
assume to be good code and check it for errors on a 'C' compiler
that's compatible.
From all indications, the compiler used for your machine is compatible
with Borlund C.
>The processor of the PLC is a RISC type - the same family of processors
>used for video cards, sound cards, modems etc. These processors have
>a greatly restricted command set as much of the work they do is a
>function of the hardwired part of the board they live on. As a rule
>they do not use a lot of memory 'mapping' as the RAM is hardwired to
>the CPU. This particular CPU uses limited mapping as an array can be
>defined for the data base. Every one of these CPUs has its own dedicated
>compiler.
>
>BTW - I thought that hard drives incorporate a similar processor. You
>worked for Seagate? (I have two Seagate drives and a Western Digital in
>my 'puter. Built the whole thing myself from components).
Huh? Damned near every drive I worked on (And I worked on hundreds of
different types) had different processors in them. They seemed to
pick new processors for each generation to get the mostest bang for
the buck; and damned little source-code made it from generation to
generation. Each generation having too many differences and added
"features" to make using older code and designs much of a deal in the
total cost of the design. Even the interface changed from each
generation. Of course, having (at least) three and sometimes as many
as six different departments designing the hardware for each drive,
many of the departments being originally whole company acquisitions
within a few years, had a lot to do with the large number of
processor-types.
That (as you might imagine) made it a little hard on ME; as I was
designing the software to TEST all these differing drives, to make
sure they met design specification. (That's Product Assurance, not
Quality Assurance. Quality Assurance made sure drives being shipped
ran properly. PA tested the WHOLE drive to make sure that as-designed
it would meet the specification ... MUCH harder, and about 1000 times
more rigorous.)
To test each drive to make sure each one could do all the things the
Product Specification *said* it could do, under all the conditions and
overlaps ....
Then, I had to do this on several different platforms, with one
program. ;-|
There area gazillion different ways to meet minimum ATA specs. Same
thing with SCSI specs. However, when you start adding in all the
special feeping creatures that each company, department, or manager
decides to put in or remove for each drive ....
--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
|
| Follow-ups: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
|