Jim, it sounds as if HiTech is also a serious option then - I'll have to do some price comparisons.. I am glad to see that compilers have grown up over the last two years or so - it should make my job a bit easier.. Thanks for your trouble Roland -----Original Message----- From: Jim Ham To: PICLIST@MITVMA.MIT.EDU Date: 10 May 1999 01:17 Subject: Re: MPC, HiTech and 17C756 >Roland and others: > >My experience is with C17 and HiTech. I also gave up on C17 and am now >using HiTech. I have successfully ported an application from Borland C >V5.01 to the HiTech environment. The port was _very_ easy! The only real >difference was in how RAM is handled and in the syntax of casting a void >pointer. Learning to use the on-board C756 peripherals took much longer >than the initial port. > >As of today I only know of two problems with the HiTech compiler and the >17C756: > >1. far pointers don't work all the time. In my case I simply keep track of >RAM management for some of the larger blocks and specifically define them >as bank 1, bank 2, etc. This works and is not too much of a hassle. This >way Hitech has enough room in bank 0 for all its needs. It will be better >when far pointers work as they should. > >2. A corollary of the above: There is a bug in the code that impliments >copying of structures. HiTech has a patch for this that makes it work fine. > >All comments below apply only to the HiTech compiler, not to MPC. > >At 10:05 PM 5/9/99 +0200, you wrote: >>Hello everyone, >> >>Having made a mistake in purchasing MPLab-C17 two years ago and finding it >>unable to correctly assemble a while or do...until loop for the 17C44 I want >>to gather some info on MPC, which from previous discussions on the list >>seems to be the compiler to go for. So here goes: >> >>1. Has anyone here used MPC with the 17C756 before? > >My application is about 8K and compiles fine. > >>2. Is the 17C756 supported yet? > >Yes. > >>3. If so, is the I2C master implemented using the built in hardware module >>yet? > >I am using both I2C and SPI. Since I started with C17, I modified their >libraries to work. This was a two step process: Make them work at all :-<, >then make them work with the HiTech compiler. I am using the built-in >hardware for both. > >>4. And the A/D converter? > >I'm also using the A/D, seems to work fine. I have not gotten to testing it >for accuracy, etc. > >>5. Has anyone used the an I2C EEPROM with the 17C756 and its hardware I2C >>module (C or otherwise) - comments, problems? > >I use the I2C hardware to talk to a 24LC16. Works fine. I use the (highly >modified) C17 libraries. > >>6. How well does MPC integrate into MPLab? > >I use MPLab with the 17C756 PicMaster. > >Breakpoints break at the right place, but MPLab puts the cursor in the >wrong place. I usually wind up placing the breakpoints in the C code >listing, but do any necessary stepping in the assembly window. This is >workable, but could be a lot better. Neither HiTech nor MicroChip want to >own up to this issue. > >Symbols (both ram and rom) are read correctly by MPLab. You can watch and >change values by symbol name with no problem. > >Ocassionally MPLab freezes after makeing the project (Win95). My workaround >to this is to 1. use the task manager to kill MPLab, 2. delete all >temporary files from the project, 3. restart MPLab, 4. Make a >non-consequential edit in one module (delete an empty line for instance). >5. Remake and usually it works. MICROCHIP are you listening? what's going >on here? > >>7. Any other comments about MPC or another compiler? > >HiTech email support is very good. You almost always get a helpful response >within one day, sometimes sooner. > >I spent _way_ too much time trying to get C17 to work before I switched. > >The only significent differences in HiTech C and traditional C that I can >think of is: >1. HiTech does not promote a char to an int when passing a fuction argument >(good!) >2. HiTech defines an addition 'bit' type that allows direct bit >manipulation (good!) >3. No recursion > >Of course there is no real stack on a PIC, so you have to design your >program appropiately. > >I've even written my interrupt routines in C and they work perfectly. When >I look at the produced code I just don't see any justification for doing >them by hand. It's not that you couldn't do it better in assembly, it's >only that you couldn't do it enough better to make it worthwhile. > >> >>Thanks in advance for any comments - I have a fairly large and processor >>intensive project in the workings, and have had enough of assembly - I have >>paid my dues, and gained a very good understanding of the inner workings, >>but simply don't have time to code this one in asm. My reason for using the >>17C756 is that it has the built in A/D and extra capture and PWM modules, >>which I need, and the price difference from the '44 is negligible >>considering some of the other necessary components in the application. And >>its available! > >There are enough quirks with any new compiler/processor environment that >you should plan on spending more than a few days to get it all to work - I >did. More than once I thought I found a compiler bug where it turned out to >be something else. In the end I wound up with a lot of respect for the >compiler. The structure copying bug certainly had me going though :-( . > >Regards, > >Jim Ham > > >Jim Ham, Porcine Associates >(650)326-2669 fax(650)326-1071 >"http://www.porcine.com" >