Joseph H Allen wrote:

> I'm in my 30-day eval period for the C30 compiler, after which it still
> works but prevents optimization.  This sucks (especially since it's gcc),
> because even for the program above there is a 3X performance increase
> between no optimization and -O3.
> 
> I have AVR tools... I'll have to do a speed comparison.
Is that AVR GCC tools?

The optimisation does not go away altogether, you still get -O1, 
whatever that is worth.

The -O1, -O2 etc optimisation groups? Some of the individual 
optimisations are still available but I have no idea which ones end up 
in which group.

In article <fio8u4$t8u$1@pcls6.std.com>,
Joseph H Allen <jhallen@TheWorld.com> wrote:

>I have AVR tools... I'll have to do a speed comparison.

Here's the speed comparison:
	PIC24FJ64GA002, 32 MHz (16 MIPS), MPLAB-C30
vs.	ATMEGA32, 16 MHz (16 MIPS), WinAVR.

ATmega32 (8 bit)
	-O0	.33 Hz	398 bytes
	-O1	.82 Hz	276 bytes
	-O3	1.42 Hz	264 bytes (unrolls loops)

PIC24FJ64 (16 bit)
	-O0	.48 Hz	1140 bytes (372 code bytes)
	-O1	.74 Hz	1056 bytes (288 code bytes)
	-O3 -funroll-loops
		1.3 Hz	1113 bytes (345 code bytes)

The result is the frequency in Hz of a GPIO pin being toggled by the code.

(the PIC image is larger because of a large interrupt vector table, so I
give the code separately).  Both compilers will aggressively inline, so I
moved a function to a different file to prevent it.  I wanted there to be
some subroutine calls in the test.

This test is unfair to the PIC since the code is not complex enough to show
off its math and larger register file.  On the other hand, it does give you
an idea what happens with simple loops and calls.

>	void e()
>	{
>	}

>	void dly() // Just this function in a different file to prevent inlining
>	{
>		int x;
>		for (x = 0; x != 5; ++x)
>			e();
>	}

>	int main()
>	{
>		int x;
>		PORTA = 1;
>		TRISA = 0;
>		for (;;)
>		{
>			PORTA = 1;
>			for (x = 0; x != 10000; ++x) dly();
>			PORTA = 0;
>			for (x = 0; x != 10000; ++x) dly();
>		}
>	}
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

On 30 Nov, 06:00, jhal...@TheWorld.com (Joseph H Allen) wrote:
> I've been playing with a PIC24FJGA002: a 16-bit, 16 MIPS PIC in a 28-pin DIP
> with 8KB RAM.
>
> Here are some quick-start hints:
>
> Programming:  I bought a cheap ICD2 clone from ebay, one fromwww.mdfly.com
> They don't advertise that it works with this chip, but it does for both
> programming and debugging.  However, you need to make your own programming
> socket (or do in-circuit).  Unlike older PICs:
>
>         You need a 10 uF capacitor between VCAP and ground.  The PIC needs
>         this to generate its internal 2.5V Vcore supply.
>
>         You need to ground DISVREG
>
>         Connect VPP to MCLR (MCLR is no longer labeled VPP- ICD2 will not
>         put 13V on MCLR, just pull it to either 3.3V and GND).
>
>         Set the MDFLY ICD2 clone to supply 3.3V (this is a jumper)- or set
>         it to Tself, and use your target board to power the PIC.
>
>         Connect PGC and PGD to any one of the three sets of PGCx and PGDx
>         pins. It does not matter which of the three you pick- I used PGC1 and
>         PGD1.
>
> Reset: Unlike some 8-bit PICs, you can not disable MCLR.  It needs a pull-up
> for the PIC to come out of reset.
>
> The C30 C compiler works fairly well.  Ints are 16-bits, like in MS-DOS.
> Here is a program which blinks a LED on RA0:
>
>         #include "pic24fxxxx.h"
>
>         void e()
>         {
>         }
>
>         void dly()
>         {
>                 int x;
>                 for (x = 0; x != 10; ++x)
>                         e();
>         }
>
>         int main()
>         {
>                 int x;
>                 PORTA = 1;
>                 TRISA = 0;
>                 for (;;)
>                 {
>                         PORTA = 1;
>                         for (x = 0; x != 10000; ++x) dly();
>                         PORTA = 0;
>                         for (x = 0; x != 10000; ++x) dly();
>                 }
>         }
>
> In MPLAB, create a project, select the device and select "FRC PLL" (built-in
> 8 MHz RC clock multiplied by 4 by PLL) config option.  Build it, and burn it
> into the chip or debug it.  Remember to select "Debug" or "Release" on the
> tool bar.  It needs to be "Debug" for debugging (adds -g to GCC).
>
> For programming, remember to hit to "release from reset" button after you
> program the part or nothing will happen :-)
>
> For debugging (I mean emulating), a part of the programming tool bar and the
> debug tool bar appear.  Hit the program button first, then hit the reset
> device button, and then debug: hit run, or right-click and hit goto cursor
> or whatever.
>
> Single-stepping is incredibly slow- I wonder if it has to reprogram the
> flash after each step.
>
> I'm in my 30-day eval period for the C30 compiler, after which it still
> works but prevents optimization.  This sucks (especially since it's gcc),
> because even for the program above there is a 3X performance increase
> between no optimization and -O3.
>
> I have AVR tools... I'll have to do a speed comparison.
> --
> /*  jhal...@world.std.com AB1GO */                        /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p-+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Single-stepping with the ICD 2 is slow, especially if you are
displaying registers. It's nothing to do with programming the flash as
the instructions are moved into RAM when they are executed.

Leon

I've been playing with a PIC24FJGA002: a 16-bit, 16 MIPS PIC in a 28-pin DIP
with 8KB RAM.

Here are some quick-start hints:

Programming:  I bought a cheap ICD2 clone from ebay, one from www.mdfly.com
They don't advertise that it works with this chip, but it does for both
programming and debugging.  However, you need to make your own programming
socket (or do in-circuit).  Unlike older PICs:

	You need a 10 uF capacitor between VCAP and ground.  The PIC needs
	this to generate its internal 2.5V Vcore supply.

	You need to ground DISVREG

	Connect VPP to MCLR (MCLR is no longer labeled VPP- ICD2 will not
	put 13V on MCLR, just pull it to either 3.3V and GND).

	Set the MDFLY ICD2 clone to supply 3.3V (this is a jumper)- or set
	it to Tself, and use your target board to power the PIC.

	Connect PGC and PGD to any one of the three sets of PGCx and PGDx
	pins. It does not matter which of the three you pick- I used PGC1 and
	PGD1.

Reset: Unlike some 8-bit PICs, you can not disable MCLR.  It needs a pull-up
for the PIC to come out of reset.

The C30 C compiler works fairly well.  Ints are 16-bits, like in MS-DOS. 
Here is a program which blinks a LED on RA0:

	#include "pic24fxxxx.h"

	void e()
	{
	}

	void dly()
	{
		int x;
		for (x = 0; x != 10; ++x)
			e();
	}

	int main()
	{
		int x;
		PORTA = 1;
		TRISA = 0;
		for (;;)
		{
			PORTA = 1;
			for (x = 0; x != 10000; ++x) dly();
			PORTA = 0;
			for (x = 0; x != 10000; ++x) dly();
		}
	}

In MPLAB, create a project, select the device and select "FRC PLL" (built-in
8 MHz RC clock multiplied by 4 by PLL) config option.  Build it, and burn it
into the chip or debug it.  Remember to select "Debug" or "Release" on the
tool bar.  It needs to be "Debug" for debugging (adds -g to GCC).

For programming, remember to hit to "release from reset" button after you
program the part or nothing will happen :-)

For debugging (I mean emulating), a part of the programming tool bar and the
debug tool bar appear.  Hit the program button first, then hit the reset
device button, and then debug: hit run, or right-click and hit goto cursor
or whatever.

Single-stepping is incredibly slow- I wonder if it has to reprogram the
flash after each step.

I'm in my 30-day eval period for the C30 compiler, after which it still
works but prevents optimization.  This sucks (especially since it's gcc),
because even for the program above there is a 3X performance increase
between no optimization and -O3.

I have AVR tools... I'll have to do a speed comparison.
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}