Picc C

Hi,

I have an old project for which I built a dozen or so devices based on 16F84. I wrote it in C and compiled it with (I'm pretty sure) PICC C (DOS based). I've finally succumbed to making some mods but no longer have the software package.

I remember trying endless variations to squeeze the code in & finally got it to compile @ 99% of available memory.

I'm afraid me & assembly will never meet eye to eye. ever. sorry!

So I would like to know what my options are to enable me to use my existing code with a new compiler with as few mods as possible on a device with more memory.

Many thanks in advance.

That depends on what compiler you started with, and how much proprietary syntax and/or functions you used.

Without actually seeing any of your code, it's kind of hard for us to judge how much it would need to be modified for a different C compiler...

Here's some code

Thanks for the reply. Below is some extracts from the code, rather than posting the whole thing (too embarrased about my commenting!)


#include <16c84.h>
#include <ctype.h>
#include <stdlib.h>
#fuses xt,put,nowdt
#use delay (clock=2457600)
#use rs232 (baud=2400,xmit=PIN_B2,rcv=PIN_B3)

#define A 1 // 0 A seconds for cap to discharge
#define B 1 // 1 B millisecs for cap to charge (i.e. light level threshold)
#define C 1 // 2 C secs between each sample
#define D 1 // 3 D minutes between each check for light

int now(void); // what's the light right now?
int light(void); // what's the average light?
void delay_secs(int time); // delay in seconds
void delay_mins(int time); // delay in minutes
void program(void); // program eeprom

INPUT(PIN_B0);
if(PIN_B0) {
program(); // run "program" if B0 is low
}

INPUT(PIN_A4);

printf("\r\nVM\r\n");

while(TRUE) {
printf("w4D\r\n");

delay_mins(READ_EEPROM(9)); // wait J before checking level
printf("eprom0 = %u eprom1=%u eprom2= %u",READ_EEPROM(0),READ_EEPROM(1),READ_EEPROM(2));
printf("P\r\n");

if(atoi(number)) { //atoi changes a string to an integer (standard library)
WRITE_EEPROM(count,atoi(number));
count++;
variable++;
printf("%u",atoi(number));

Further to that...

It didn't occur to me that PICC C compiler would now be free of charge, but I see that this is only the case for a limited number of devices:-
12F629 No Limitations
12F675 No Limitations
16C84 No Limitations
16F627 2 RAM banks supported
16F627A 2 RAM banks supported
16F684 1 RAM banks, 1K program memory supported
16F690 New! 2 RAM banks, 2K program memory supported
16F84A No Limitations
16F877 2 RAM banks, 2K program memory supported
16F877A 2 RAM banks, 2K program memory supported

I have seen may site declaring 16F628 as the best 16F84 replacement, but unfortunately it's not on the list above. How does the 16F627 compare?

Thanks.

flatfootskier said:

It didn't occur to me that PICC C compiler would now be free of charge, but I see that this is only the case for a limited number of devices:-
12F629 No Limitations
12F675 No Limitations
16C84 No Limitations
16F627 2 RAM banks supported
16F627A 2 RAM banks supported
16F684 1 RAM banks, 1K program memory supported
16F690 New! 2 RAM banks, 2K program memory supported
16F84A No Limitations
16F877 2 RAM banks, 2K program memory supported
16F877A 2 RAM banks, 2K program memory supported

I have seen may site declaring 16F628 as the best 16F84 replacement, but unfortunately it's not on the list above. How does the 16F627 compare?

Click to expand...

It's the same chip, except it's only got 1K of program memory instead of two. As you're looking for more memory space the 16F690 looks like it could do the job, but it's 20 pin instead of 18 (but a LOT smaller than the 40 pin 877's).

flatfootskier said:

Hi,
I'm afraid me & assembly will never meet eye to eye. ever. sorry!

Click to expand...

Why? Once you climb the learning curve a little you will find it is easy.

Assembly is much more efficient in memory space.

Why not assembly?

Thanks Nigel, I was hoping for a pin match so I could drop into the old PCBs, but a redesign of the PCB might be worth the investment in the long term.



I understand some of the benefits of assembly & I appreciate there are further benefits I haven't grasped, but I made the investment in learning enough C ( a work colleague strated me off & I just kept on building it up). I found it fairly intuitive. Fundamentally though, I have quite a bit of code already in C and I don't have time to reinvent the wheel

flatfootskier said:

Thanks Nigel, I was hoping for a pin match so I could drop into the old PCBs, but a redesign of the PCB might be worth the investment in the long term.

Click to expand...

The 16F627 would drop straight in, but doesn't give you any more memory than a 16F84.

You could always do the 'decent thing' and buy the full version of the compiler, then you could use a 16F628 with 2K of program memory.

At $950 for 1kB that's nearly one dollar per Byte!
I just can't strectch to that sort of money.

There are other C compilers that are a lot more affordable, but of course portability is the issue. BoostC has a free version that supports up to 2k of code size, and doesn't restrict by chip type. You can get a 4k version for $30, or an unlimited version for $70 ($150 if it's for commercial use). BoostC also has pretty good optimization.

However, looking at your code, it appears you are using a lot of proprietary functions - printf, eeprom functions, atoi, etc. Other compilers may have similar functions, but there's likely to be differences; Individually, none of them would be extremely difficult to implement manually in any given compiler, but it's still going to take a moderate amount of effort. There's definitely something to be said for avoiding compiler-specific proprietary functions and doing things yourself.

If I were you, I'd pick a good new compiler, and just take the time to port the code over.

I would try it on the 627 for two reasons.

First, it has a lot more ram (176 usable versus 68) than the 84 and therefore the compiler should be able to produce more efficient code.

Second, it has a hardware USART. As your code uses RS232 (from the snippet above) then the compiler has to implement this in software which will not be required on the 627.

I wouldn't be surprised if you ended up with lots of spare capacity.

HTH

Mike.

Thanks Pommie,
Showing my ignorance here but:-
I assume this would happen automatically within the compiler - i.e. I just change the device & recompile & hope for more space?

flatfootskier said:

Thanks Pommie,
Showing my ignorance here but:-
I assume this would happen automatically within the compiler - i.e. I just change the device & recompile & hope for more space?

Click to expand...

I'm sure that it would do it automatically - it would be a very poor compiler if it didn't. Even if it doesn't, implementing hardware RS232 is fairly trivial and a couple of posts here should get it working. Why not try it now, you don't need the chip to see how big the hex file is. Be sure to post the outcome.

Mike.

Mike. Thanks again. I'll give it a go & post.
Currently trying to get my head around MPLAB, HiTide, DOS based compiler etc. Not sure which ones I need just to do a recompile & how they fit together. Not investigated enough to warrant a post asking for help, but if anyone knows of any spoon feeding type instructions!...

I haven't used HiTide. Just install MPLAB and PicC Lite and run "configure MPLAB" from the Hitech entry on the start menu. Then run the project wizard in MPLAB.

I didn't realise Picc was the HiTech C product. I'm now certain that it will automatically use the hardware USART. However, the hardware USART uses B.1 and B.2 and you use B.3 and B.2 so it will still use the software USART. If you can physically swap B.3 to B.1 then it will use the hardware USART.

I still think it will fit in the 627 due to the extra ram available.

Mike.

oops

Thanks for the pointers Pommie.
I've got some learning to do here! I've not managed to successfully compile it yet, due to the results below. As Evandude states (thank you), there are several proprietary functions in my code. I don't yet understand whether I'm using the C complier within MPLAB or not - I assume not, or not properly, given that it can't recognise quite a few bits of Hitech's PicC own code. Microchip's 'idiots guide' for MPLAB is truly excellent from for a low end reader like me. I find it strange that HiTech don't appear to produce a similar doc to help get people started.

Below is the output from MPLAB.

Executing: "C:\Program Files\HI-TECH Software\PICC-Lite\9.50\BIN\PICL.EXE" -C -E"FEEDF2.cce" "FEEDF2.C" -O"FEEDF2.obj" -Zg9 -O -ASMLIST -Q -MPLAB -16F84
Advisory[1207] : some of the command line options you are using are now obsolete
Advisory[1208] : use --help option or refer to the user manual for option details
Error[107] C:\Documents and Settings\Simon\My Documents\PIC projects\FEEDF2.C 4 : illegal # directive "fuses"
Error[107] C:\Documents and Settings\Simon\My Documents\PIC projects\FEEDF2.C 5 : illegal # directive "use"
Error[107] C:\Documents and Settings\Simon\My Documents\PIC projects\FEEDF2.C 6 : illegal # directive "use"
Error[107] C:\Documents and Settings\Simon\My Documents\PIC projects\FEEDF2.C 19 : illegal # directive "rom"
BUILD FAILED: Fri Jan 12 11:39:51 2007

Does it appear as though this has been compiled (within MPLAB) by PicC?

flatfootskier said:

Does it appear as though this has been compiled (within MPLAB) by PicC?

Click to expand...

well, it appears that PICC is ATTEMPTING to compile it... if it was trying to compile it as an assembly file or something else, you'd have a lot more errors than that.

Thanks Evandude. Is there a C compiler within MPLAB or can I be sure that it's the PicC compiler doing it?

There's no C compiler within MPLAB, even it's assembler is external (MPASM).

Nigel Goodwin said:

There's no C compiler within MPLAB, even it's assembler is external (MPASM).

Click to expand...

What you say is correct but it's a bit like saying that there is no spelling checker in MS Word. In MPLAB, if I press F10 then it assembles. If I'm using HiTech C then F10 compiles it. For all intents and purposes there is a C complier in MPLAB as it gets integrated when you install it.

Mike.