C18: Error - could not find definition of symbol..

[SiriusHardware]

Thanks for doing that - I do believe you when you say that a much newer version works just the way you say it does (ie, painlessly). But I find it hard to believe that nobody ever got these older versions working.

 

[DerStrom8]

But I find it hard to believe that nobody ever got these older versions working.

What do you think the newer versions are? They're improvements on the older ones

 

[SiriusHardware]

What do you think the newer versions are? They're improvements on the older ones

You're right of course - I'm going to have to install a newer version on one of my spare PCs, if only to see something working. But I still need these old ones to work, eventually, on that Windows 98 relic at work.

 

[DerStrom8]

You're right of course - I'm going to have to install a newer version on one of my spare PCs, if only to see something working. But I still need these old ones to work, eventually, on that Windows 98 relic at work.

Well I wish you the very best of luck. I hope you can find a way to make it all work out soon

 

[Ian Rogers]

I have been using MPLAB since version 6. However! Not with C... But I'm sure I was using C18 version 3.32 on MPLAB 7.62... I never had these issues... I still think the installation went south somewhere.... Pic18f452 was supported back at version 7.62 as this was the chip I always used... ( I use 4520 now ). So I don't think it's a version fault, nor do I think the OS is to blame.. 98 was pretty stable.....

I still think its a "path" issue!

 

[SiriusHardware]

I have been using MPLAB since version 6. However! Not with C... But I'm sure I was using C18 version 3.32 on MPLAB 7.62... I never had these issues... I still think the installation went south somewhere.... Pic18f452 was supported back at version 7.62 as this was the chip I always used... ( I use 4520 now ). So I don't think it's a version fault, nor do I think the OS is to blame.. 98 was pretty stable.....

I still think its a "path" issue!

Well, I can only refer you to the complete path listings that I gave in an earlier message in this thread. If you can see the problem there, please do let me know.

I'm certainly not blaming win '98 - that was actually a separate issue, in which MPLAB V8.66 ran unbearably slowly on the same win '98 machine which runs V8.00 very nicely. That is forcing me to use an old version of MPLAB which clearly does not want to work well with C18. Incidentally this is not only happening on the '98 machine I've been talking about - If I repeat everything I've already told you I've tried there on this machine, which is XP, I get exactly the same results / error. The common factors are the same version of MPLAB and the same version of C18. The two machines are twelve miles apart.

MPLAB has just become too unwieldy for '98 to be able to run it, which is not '98s fault. (In fact, official MPLAB supoport for '98 ended some time before V8.00. After that , it was a case of 'we don't guarantee that it works') I loved 98SE - I resisted every effort to kick me off it and was still using it for some time after MS discontinued all support for it. Only eventually did I move on to XP, which by then had been debugged to the extent that it was as stable as 98 SE eventually was... and now I'm still using XP.

Anyway, I have another XP machine hitherto untouched by MPLAB, and this evening I downloaded the current version of MPLAB (8.86) onto that, installed it and then immediately afterwards downloaded and installed the current version of C18, which in fact turned out to be V3.42, the version I have been trying to use all along.

I did as you did - created a project - added leds.c to it, and simply built it and it built successfully. All paths for the the toolsuite were already correctly set up without any intervention from me - and, just as you suggested, I did not need to add the linker script to the project myself - it was obviously found automatically on the basis of the processor specified in the project. The project contains nothing but the 'c' file, but compiles and links without any problem.

This is the way the other version should have worked all along.

What I can now do is look at the detail of the syntax which MPLAB V8.86 passes to the compiler and linker and see how that differs from that passed to them by V8.00, if at all. On the 98 machine, I can try opening a DOS window and running the compiler and linker from a command line using the exact parameters which MPLAB v8.86 passes to them on the XP machine, to see if it then works.

I'll let you know what happens.

 

[SiriusHardware]

Well, that's interesting.

This is the dialogue sent by MPLAB V8.86 to C18 (To allow these lines to fit into message width I have removed the start of the path from the beginning of each of these lines, which was "C:\Program Files\Microchip\mplabc18\v3.42\bin\...

mcc18.exe -p=18F452 "c:\picprojects\leds.c" -fo="leds.o" -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
mplink.exe /p18F452 /l"C:\Program Files\Microchip\mplabc18\v3.42\lib" "leds.o" /u_CRUNTIME /z__MPLAB_BUILD=1 /o"C18_test.cof" /M"C18_test.map" /W

I made these parameter lines into a batch file and used it from a command line to try to build the leds.c program on the XP PC which has MPLAB V8.00 and C18 installed.

It worked!

So what this suggests to me is that MPLAB V8.00 is sending the wrong parameters - or the right parameters in the wrong order - to C18. In order to prove this I need to edit the commands which the MPLAB V8.00 IDE sends to the compiler and linker. Can I do this? Are the commands hard coded into the IDE or is there a template file (in the toolchain definition, perhaps) which I can edit to alter the order and syntax of what the IDE sends to C18?

 

[SiriusHardware]

OK, tried something else:

On the Win'98 machine, I installed a slightly later version of MPLAB, taking it from V8.00 to V8.33.

This version works fine with C18 V3.42. Unfortunately it's a bit more clunky than V8.00 was, noticeably more resource heavy, runs quite slowly on the '98 machine (although not as unbearably slowly as V8.66 did).

The next step is to keep working downwards until I find the earliest version of V8.xx which functions correctly with C18 V3.42.

 

[Ian Rogers]

Is there any reason why you have a die hard 98SE (I'm gonna make it work ) campaign going? Will XP not work with this machine?

I must admit that I didn't / wouldn't shift from 98SE.... But XP has really proved itself....... ( Pssst!! I'm kinda getting to like Windows7.. Don't tell Bryan )..
When I go to work, I only have XP at work, I miss some of the features of Windows7 ( Sad isn't it ).

I hope you get to where you need to be....

 

[SiriusHardware]

Is there any reason why you have a die hard 98SE (I'm gonna make it work ) campaign going? Will XP not work with this machine?

I must admit that I didn't / wouldn't shift from 98SE.... But XP has really proved itself....... (

The background is that we have certain items of software and hardware (particularly some old DOS based device programmers) which can only be run from a 98 machine or earlier - so this machine and its operating system - which are conveniently close to me at work - can't be got rid of. It's not on the network and is little used which means that I have largely undisturbed access to it - I occasionally have to bale out for a couple of minutes while someone programmes a 27C128 or something. There isn't any other machine available to me, so the version of MPLAB that I run has to fit comfortably into the small RAM and slow processor - 233Mhz, I believe, of this PC, and once you get much above V8.00 the system really starts to struggle

As I said, I have been happily using MPLAB V8.00 for years to write assembly language and Hitech 'C' programmes on it with never a problem until the day I tried to use C18 for the first time - then I got the problems I've been talking about throughout this thread.

But the end is in sight - I've been over to Microchip's website again and laboriously read through the release notes for MPLAB V8.xx. The release notes for V8.10 state that a known linker problem is now fixed, and that the IDE no longer requires you to specify a .lkr file in your project (as was previously the case) - from V8.10 onwards it finds the relevant .lkr file automatically, just as you told me.

So tomorrow, I'm going to take the slightly top-heavy MPLAB V8.33 off the '98 PC and install MPLAB V8.10, which hopefully shouldn't consume any more system resources than V8.00 did.

I love XP now as much as I did 98SE back in the last years of its life, and I originally intended to keep on with XP until the official end of support for XP in mid-2014, by which time Win 7 ought to be properly bug tested and fixed and therefore worthy of my attention - but MS have thrown a spanner into those particular works by jumping to Win 8 when Win 7 (perfectly decent, I agree) has hardly been around for any time, which means I'll now have to keep on using XP for years until Win 8 gets to SP3 or thereabouts. Annoying.

 

[Ian Rogers]

I occasionally have to bale out for a couple of minutes while someone programmes a 27C128 or something.

Are you talking about stag? If so I have a windows XP GUI (I had to ask them nicely for it )...

 

[SiriusHardware]

We use a small collection of old programmers, all of which were supplied with DOS software to run them. None of them happens to be a STAG, though.

If they were suddenly able to be run from an XP machine that would be a bit of a disaster, as the machine thus transformed would be a lot more useful than it is now and would probably be moved from where it is.

I have considered looking into the well known DOSBOX utility - primarily meant to provide the necessary environment for running old DOS games on XP, it has to be a very good low level hardware emulator because most software of that nature went straight to the hardware, or used the motherboard BIOS to access hardware. If it facilitates direct access to the serial / parallel ports, then it might very well be able to run all of these old programmers. But I'd rather keep that quiet for now.