16/32 bits PIC support in PBP?


+ Reply to Thread
Results 1 to 11 of 11
  1. #1

    Question 16/32 bits PIC support in PBP?

    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
    Last edited by Acetronics2; - 5th May 2010 at 11:57.

  2. #2
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924

    Default

    Quote Originally Posted by comwarrior View Post
    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.
    Dave
    Always wear safety glasses while programming.

  3. #3
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530

    Default

    Quote Originally Posted by comwarrior View Post
    The question is, does pbp support anything higher than PIC18's?
    No.

    Quote Originally Posted by comwarrior View Post
    if not, is their any future developments to be done towards 16/32 bit PIC's?
    None that I know of.

    Quote Originally Posted by comwarrior View Post
    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.

    Quote Originally Posted by comwarrior View Post
    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?

  4. #4

    Default

    Quote Originally Posted by scalerobotics View Post
    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?
    Last edited by comwarrior; - 5th May 2010 at 21:52.

  5. #5
    Join Date
    May 2007
    Posts
    604

    Default

    Quote Originally Posted by comwarrior View Post
    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.

  6. #6

    Default

    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????

  7. #7
    Join Date
    Mar 2003
    Location
    Commerce Michigan USA
    Posts
    1,166

    Default

    comwarrior, Thin Quad Flat Pac....

    Dave Purola,
    N8NTA

  8. #8
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    984

    Default

    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.

  9. #9
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,573

    Talking no 16 and 32 bits assemblers ... joking' I hope ...

    Quote Originally Posted by Art View Post
    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>
    Last edited by Acetronics2; - 7th May 2010 at 12:46. Reason: html code bugs !!!
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  10. #10
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    984

    Default

    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) ?

  11. #11
    Join Date
    May 2007
    Posts
    604

    Default

    Quote Originally Posted by Art View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts