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

[Art]

I doubt PBP will ever support anything in the 16/32 bit devices for the reasons posted above.
You can't write for them directly in assembler with MPLAB,
so how could a high level language that compiles to assembler be of any use?
I can't see a version of PBP ever existing that compiles BASIC to C code for these devices,
it would just be plain silly because they are both fairly high level languages, and C is far superior.

The apparent lack of awareness of exactly what is being missed out on is rather unfortunate.

On the other hand I think there will always be reasons to upgrade PBP to later versions.
The way it compiles your basic code to asm can always be improved upon,
and new features can always be added for the chips it does support.

I don't see much of a long term future for PBP with the way Microchip is going though.

Having just started with a dsPic, I can recommend Micrchip's C-30 compiler.
When the free trial expires, all you lose are the code optimisation features that reduce
the program memory consumed by your program, etc.
Not too bad for a free product that would otherwise cost close to $500.

[Acetronics2]

I doubt PBP will ever support anything in the 16/32 bit devices for the reasons posted above.
You can't write for them directly in assembler with MPLAB,
so how could a high level language that compiles to assembler be of any use?
.

Hi, Art,

I won't be so sure ...

What are MPLAB ASM30 and ASM 32 , for you ???

Have a look to the relevant chapters in MPLAB HELP ...

Alain

one example for ASM32:

#include



</PRE>

############################


</PRE>

# main routine


</PRE>

############################


</PRE>

.text


</PRE>

.set noreorder


</PRE>

.ent main


</PRE>

main:


</PRE>

# Do something here


</PRE>

nop


</PRE>

# Infinite loop


</PRE>

1:


</PRE>

b 1b


</PRE>

nop


</PRE>

.end main


</PRE>

.globl main


</PRE>

[Art]

Ah, well I stand corrected.
Maybe I just made that assumption because I see no transitional asm file on the way from C code to hex file
when I compile a C-30 project. A member here recently prompted me to check.

The question is do the asm30 and asm32 products cost money that would have to be spent
in addition to the PBP compiler that supported them (if it ever did exist) ?

[rmteo]

The question is do the asm30 and asm32 products cost money that would have to be spent in addition to the PBP compiler that supported them (if it ever did exist) ?

I am not aware of MC ever charging for the use MPASM so my guess is that the same would apply to MPASM30 and MPASM32. The products are copyrighted by MC but since they are useable only with the copyright owners products, I don't think that there is an issue here. It is the same with other manufacturers AFAIK.