16/32 bits PIC support in PBP?

[comwarrior]

Since the FAQ is empty after the apparent upgrade I decided this is the best place to post my question and i can't find the answer in the PBP's product description.

I have an older version of PBP that I've been meaning to upgrade for a while, just never got around to it...

I'm now looking at the possible necessity to use PIC24's and above.
The question is, does pbp support anything higher than PIC18's?
if not, is their any future developments to be done towards 16/32 bit PIC's?
If NO then theirs no point in upgrading...

Thanks

[mackrackit]

Since the FAQ is empty after the apparent upgrade I decided this is the best place to post my question and i can't find the answer in the PBP's product description.

What FAQ is empty? If you mean the one here on the forum you need to check again.

[ScaleRobotics]

The question is, does pbp support anything higher than PIC18's?

No.

if not, is their any future developments to be done towards 16/32 bit PIC's?

None that I know of.

If NO then theirs no point in upgrading...

Maybe not for you. But plenty of people would disagree with you, and say that the extra USB support for newer chips, Arraywrite/read and (depending on how old the version of PBP is) longs, etc, the upgrade is plenty worth the $25.

I'm now looking at the possible necessity to use PIC24's and above.

Just curious. Is is the 16 million instructions per second that is too slow for your application, or did you need some DSP? Or is it the "more power!" (Tim Taylor) syndrome?

[comwarrior]

No.
Just curious. Is is the 16 million instructions per second that is too slow for your application, or did you need some DSP? Or is it the "more power!" (Tim Taylor) syndrome?

nope... faster analogue scanning, WAY more IO lines, WAY better math to play with bigger numbers! more communications 'ports'...

When you have a system running on a 18F4550 @48MHz with int clock and every AN/IO pin is used and the program barely keeps up, you know your not far off needing to upgrade...
i know it's just keeping up because the 'optional' code is the update to the LCD, everything else is interrupt driven...

Oh, and you can add more timers to the list... my code ATM has to share!

:edit
So, the question now is why doesn't PBP support > PIC18's?

[rmteo]

So, the question now is why doesn't PBP support > PIC18's?

Probably has to do with the target market. Plus, the 16-bit devices have a completely different architecture, different instruction set, vectored interrupts, etc. Would need a complete re-write of the compiler - same situation with the 32-bitters. Best option would be to go with the C30 and C32 compilers if you are looking to higher performance and more sophisticated peripherals.

[comwarrior]

Actually, i've just discovered the PIC18F97J60, it seems to have enough IO/ports etc...
I'm also impressed that it has a direct memory bus...

Having to use everything at 3.3V is going to be annoying... but i'll make it work...
I also have the 'fun' of re-visiting the TCP/IP stack and OSI layers from a none microsoft, none Linux point of view... Completely from scratch, none of the crap that comes 'pre-installed'...

Although, what the hell is a TQFP? I know QFP, it's like PLCC with pins on all 4 sides (according to my PCB software)... TQFP????

[Dave]

comwarrior, Thin Quad Flat Pac....

Dave Purola,
N8NTA