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"