The above mentioned PICs are currently 'unsupported' by PICC-Lite and I suspect all one needs to get 'em to work is the 'device' info file - i.e. the device library.
Does any one here have the libs for the two PICs, as that would really come in handy - seems like I'll be using a 16F877 to perform a job that the 16F88 could EASILY manage - Going from 18 pin to 40 pin, just for the extra ROM space too...
Another oddity I've come across is that when I compiled the code with the 16F84A, it exceeded the 1K ROM space (it gave some queer errors) so on a hunch I compiled as a 16f877, it compiled! If I disable the code for lcd control, it uses 50% of the 16f84, if I disable code for ps2 coms also 50%, so I know it's not vastly over 1K...
Rather than saying 1/8th of the space is used it says 50% ...
If I remember correctly, a 16f84 = 1K, 16f877 = 8K, um am I missing something here?
I'm thinking what it means is that 50% of the 2K bank, and it has four of these banks (i.e. 4 x 2k = 8K) - I just find that this is quite a strange way for the compiler to report how much space has been used ?!?
also, boostC is constantly improving. they respond quickly to any issues you have with it on their forum... this summer I requested that they add the method of bit accessing that was available in CC5x (ie - var.3 = 0 would clear bit 3 of variable 'var') and that was one of the first things they added after they finished 32-bit variable support.
Just today they emailed me asking me to try out their newest revision compiler on a program that I had previously spoken with them about.
here's the breakdown:
CC5x (free edition): 300 code words
CC5x (full version): 224 code words
BoostC (outdated free edition): 264 code words
BoostC (version 6.20 free edition): 234 code words
So even the free edition of BoostC is less than 1% larger than the $250 CC5x compiler, and significantly more optimized than the free edition of CC5x. That's one of the great things, even with the free edition you still get full optimization capability.