Should I upgrade?

[dbotkin]

Hi all... it's been a while since I was here last.

I've been using PICC since V2.something. I'm currently using V3.124, and it's doing fine. However, again today I started thinking about a project that would need a chip not supported by 3.212. It's happened a few times, and with the number of new chips since 3.212 was released it's going to be an issue soon.

The last time I was regularly watching threads here, 4.x was pretty buggy still, and people weren't too happy. I would assume that's changed by now. My issue is, I have an application that is currently using all but the last 6 or 8 words of program memory on a 12F683 -- meaning there's nowhere to go from there; there hasn't been anything to surpass the '683 yet and I don't know if there ever will be. In the past, I saw problems where new compiler versions would actually use more program memory than older versions - it usually got fixed, but not always right away.

I want to upgrade for the new parts, but I'd hate to have to keep the 3.212 compiler alive to maintain that one project. So, my questions are...

Is V4.069 working properly, and more or less free of annoying bugs on 12, 14 and 16 bit parts (10F, 12F, 16F, 18F)?

Does code compiler any better/smaller with 4.x that with 3.212?

Are there any "killer" new features I'm missing, ignoring for now support for dsPIC and all?

Help me out here... thanks!

Dale

[PCM programmer]

[RLScott]

It seems that supporting a new chip should not be a necessary reason to have to upgrade the compiler - provided CCS gave us one thing: the ability to specify configuration fuses with a hex value. It may be different now, but in the 3.242 PCM compiler that I am using, the only option is to specify configuration fuses with a list of symbols that are associated with the particular PIC device. In the 14-bit cores, for example, a new chip differs from other chips in the configuration bits, perhaps in the configuration word address, and in the SFRs. I never use the CCS-supplied library of peripheral functions - I talk to the SFRs directly. So a new chip would not be a problem for me in that regard. That leaves the configuration bits as the only item needing to be customized to a given chip. In a different thread on this subject, I even went so far as to suggest that someone could use an older version of the CCS compiler by selecting a similar chip with the same core, and then editing the Intel HEX file to add the final line containing the configuration bits. It is not too hard, and once you figure it out for a given project, it remains the same. A simple post-processing program could even be written to remove the irrelevant configuration bits line and add the correct one. However, this nonsense would be unnecessary if CCS provided something like:

#Fuses 0x3FFC, 0x2007

which would mean to emit Intel HEX for address 0x2007 containing 0x3FFC.

Robert Scott
Real-Time Specialties

[baltazar_aquino]

There are even instances where you won't need the fuses at all as in the case of using a bootloader since the fuses area cannot be accessed by the bootloader. Also, in the final stage of burning your hex file, there are some programmers (like mine - GTP-USB) that would allow you to modify the fuse settings so the #FUSE issue has some solutions. My concern is, up to what level is the "support" of a given compiler version to the chip? Example:
If a chip is not supported by my current version and I do some works in creating my own header file for that chip based on Microchip documentation, will it compile assuming I have the correct port of the *.inc code from Microchip? Or there is still a library hidden somewhere that counter checks the supported devices? This is same as the case of a header file for a known supported device got corrupted and instead of going through my installer, I reconstructed my own header file based on the chip documentation/ *.inc. CCS C has a good answer to this, definitely.

Baltazar

[RLScott]

The custom header file that you need is not a replacement for the CCS-supplied headers. It is in addition. I use my own custom headers even when the device is fully supported by CCS. For example, in a recent 16F630 project, I have in my own header file things like:

[Guest_7068]

You can add support for new chips if you have the IDE version of the compiler using the device editor. The device editor modifies the database that has all the chip information and this is where all the magic happens.
The device header file is pretty much useless if you are writing your own peripheral drivers. Apart from the peripheral function definitions, the header file has the interrupt identifiers (#INT_XX) and the pin defines used for I/O.

[baltazar_aquino]

Upgrade is really just an Option.