Bob, thanks for your reply.  It sounds as if MPC is good enough then.  I had
forgotten that of course I can implement anything not already supported in
libraries myself.  Does MPC support direct inline assembly code? Also, has
Bytecraft mentioned a date for the new version - I probably won't have time
for this until July/August anyway - I might be lucky. That's one thing about
getting good advance notice of upcoming projects - you get to think them
over and thoroughly investigate the options..

Thanks again
Roland
-----Original Message-----
From: Bob Bullock <bobb@UNISERVE.COM>
To: PICLIST@MITVMA.MIT.EDU <PICLIST@MITVMA.MIT.EDU>
Date: 09 May 1999 23:19
Subject: Re: MPC and 17C756


>I am currently working on a large project using the 17C756 and the MPC
>compiler.  I can say for certain the MPC compiler does support the 756.  It
>does have library routines for the peripherals you mention, but I am not
>sure that it supports I2C in master mode utilising the 756 hardware support
>for master mode.  I doubt that it does but don't have my manual handy at
>the moment.  Over the eight months that we have been working on this
>project we have found around 15 bugs with the compiler.  Walter at
>ByteCraft has been pretty responsive in fixing most of the bugs when they
>were real show stoppers, but there still remain a number that we have to
>work around.  Plan on checking the compiled code for the first while until
>when something doesn't work as intended.  In fairness to ByteCraft, I
>beleive this reflects on a much higher percentage of uses compiling for 16C
>parts which I have not heard any complaints about bugs.  Also, I beleive
>they are working on a new version of the compiler with substantial
>enhancements, which would no doubt address these problems.
>
>I do not have any direct experience with other C compilers.  ALthough we
>are using most of the peripherals you mentioned, we have not used any of
>the library support routines included with the compiler.  This doesn't
>refelect on the routines, it just seems that we needed the absolute control
>of the behaviour by coding our own.  Didn't use I2C at all.
>
>The other compiler we are trying at the moment is the one from IAR and
>although it costs quite a bit more, I would give it a serious look.
>
>At 10:05 PM 99/05/09 +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?
>>2. Is the 17C756 supported yet?
>>3. If so, is the I2C master implemented using the built in hardware module
>>yet?
>>4. And the A/D converter?
>>5. Has anyone used the an I2C EEPROM with the 17C756 and its hardware I2C
>>module (C or otherwise) - comments, problems?
>>6. How well does MPC integrate into MPLab?
>>7. Any other comments about MPC or another compiler?
>>
>>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!
>>
>>Cheers
>>  Roland
>>
>>
>Regards
>
>Bob Bullock
>KoolKits Electronics Ltd.
>bobb@koolkits.com
>www.koolkits.com
>