No more space - options?

[StuH_CC]

I have a project which uses 4 PIC processors to do a job. It works well, but I have now encountered a little problem - one of the processors is at 98% capacity and it's getting impossible to squeeze any more code into it. I need to make a decision on the future direction of this product, so I've posted this message mainly to get other opinions on my options.
The processor in question is a PIC16F876A and the code is produced by PCM 3.185. The job of this processor is to handle communications with a PC/HyperTerminal via RS232. It only gets occasional use during commissioning and diagnostic procedures, otherwise it plays no active part in the product. A lot of the code space is used up by text strings to make its operation understandable by the operator.

As I see it, I have 3 choices.
1. Cut down the size of the text. Well, I've already gone about as far as I dare in that respect, any further and it'll be code, not intelligible text. I don't really want to do this.
2. Rewrite the code using tokens instead of text, and write a PC application for the operator to use instead of HyperTerminal. I'm leaning in this direction at the moment, although it has one major disadvantage; it won't support any of the handheld terminals commonly used in this industry - the current version supports anything that can send & receive ASCII.
3. Change the PIC for an 18F device with more memory. Probably the best solution technically, but I've never used an 18 series device before and although the pinout of the 28 pin devices looks identical, I'm pretty certain there'll be several "gotchas" to keep me awake at night. Oh yes, and I'll have to part with some cash for a copy of PCH as well...

There is of course a 4th choice, which is to scrap the current design completely and redo it with a "proper" processor and RTOS, but that would definitely be using a sledgehammer to crack a nut. Not really an option, as we're pretty much tied to the current hardware configuration for the next few months at least.

Ideas/opinions?

[newguy]

Go for the 18 series upgrade. You won't regret it. The only "gotchas" would be simple things - making sure that if you directly reference any specific registers in the existing code, that you change the address for the new chip - things like that.

[Douglas Kennedy]

You probably considered this and may not have had the board space or the pins available but just in case you do you could try this. Take the text and place it in an external I2C or SPI eeprom or FRAM. You then replace the text in your code with tokens that contain the address of the specific the text in the external eeprom. You are in fact losing some code space for an access to eeprom subroutine but gaining by compressing the code space text to tokens. This can have the added advantage if you have other languages to deal with since the language is now completely expressed within the eeprom. Swap the eeprom swap the language

[StuH_CC]

Yes, I did consider that option, especially as there is already a 24LC512 in the system. However, it's not really practical for a couple of reasons: I'd have to implement a multi-master I2C bus, and then there's the issue of getting the data into the EEPROM in the first place - it's a surface-mount part, the I2C bus is not accessible from the board connector, and as firmware updates of the PIC are usually related to new/enhanced commands the EEPROM would need updating at the same time. I can easily fix the physical bus access problem when the board is next updated, but there's still a stock of the current issue to get through first!

newguy, I think you're probably right. After eight-odd years working with midrange PICs it's hard sometimes to remember at the design stage that there are better PICs out there now. I've just ordered some 18F252s and 18F2525s for evaluation, and will get a copy of PCH sometime next week. As I said above, its the "gotchas" involved in the conversion that worry me a bit - looking at the code, one source file is littered with register references (I2C slave stuff), so I need to start comparing datasheets, I suppose.

[ckielstra]

[Charlie U]

ckielstra,

You are correct. The 18F252 is on the "mature products" page in the latest selector guide from Microchip. It is Not recommended for new designs. The recommended replacement is the 18F2520.

[ckielstra]

[ckielstra]

[Ttelmah]

Assuming that the string space sving approach just mentioned, does not cover it, then go with the 18F2520. This is very close indeed to the 252, just implementing some lower power stuff, and a few other little tweaks. Hence it really is logical for MicroChip to get rid of the duplication here.

Now on the question of how hard it is to upgrade, the answer depends.
Generally, you will need to alter the 'header' part of the sources (fuses statement etc.), add the code to disable the extra peripherals that are not used (particularly the comparator (setup_comparators(NC_NC_NC_NC);). Then alter the setup for the watchdog (on the latter chips this can be turned on/off in the code). At this point, if you only use standard C, the program has a good chance of already working. However if you use the ability to access registers directly, you will need to change the register definitions (these are at much higher addresses on the latter chips).
Generally, it is not hard. I had a project I originally 'built' to use the 252, but because of problems with the early chips, and delays in getting these, I wrote a 'reduced' version to run on the 876, to tide over, till the 252 worked properly. When the proper chips became available, I was able to have the reduced code running in the latter chips in a few hours (nearer minutes for the code conversion!), and then add the extra parts.
These chips also give you some other 'extras', such as the ability to upgrade to 4* the clock rate without changing your hardware (assuming the existing system is clocked under 10MHz).
Other problems:
Well when the 18Fxx2, came along, there were some 'issues' with the internal crystal oscillator circuit. To add the PLL, the sensitivity and gain of the clock had changed, and crystals (which were probably out of spec on the older chips, but worked), tended to cause some problems on the latter chips. There were also a number of hardware problems with the chips, but many of these have now gone, and/or there are software fixes for them.
One thing that is a problem with the latter chips, is that the interrupt latency is worse than with the 16 family. This comes about bcause there are more registers to save, and hence more instructions needed to get into the interrupt routine. If you have very tightly timed interrupt code on the older chips, then you might have a timing problem on the latter units...
On the other hand, the hardware multiplier does gain a little in performance for some of the maths.

Generally, these chips are nice to work with now, and are pretty easy to use as an upgrade.

Best Wishes

[StuH_CC]

Interesting point re the 252 - Microchip don't seem to be going out of their way to make its planned obsolescence obvious in the selector chart, or did I miss something? Anyway, I'm getting some 2525s - triple the program memory of the 876 and an order of magnitude more RAM. Might even be worth upgrading one of the other 876s in the system, no problems with program memory there (~40% usage) but data memory is definitely a bit short (342 used, worst case ) and I could really use quite a lot more.

Going back to the original problem, the string compression method would probably work for a while, but at the current rate of addition I'd soon be back where I started anyway. Might as well upgrade now and get any problems out of the way - I can use the experience to upgrade the other chips (2x 876A, 1x877A) on the board when they run out of capacity. Customers. Always wanting more, and more, and more...

The board is clocked from a 16MHz crystal oscillator module, so I won't be using the PLL mode yet (maybe in the future when every processor has been changed...), and any issues with crystal specifications are irrelevant with an external clock - I hope! The only interrupts I use are the SSP, RDA, TIMER1 and EXT ones, and I doubt that a few microseconds or even tens of microseconds either way will make any difference to operation. Register definitions are on the list of things to change, and I suppose I'll have to read the CCS documentation to see what I need to do to make the watchdog work properly - as I recall from browsing through it, the 18F chips are set up slightly differently.

Now I've just got to wait for the stuff to arrive, and I can get cracking!

[Mark]

Get some quotes. I just checked the price we paid for 16F876's vs 18F252's. They are the same.