Future PBP


Closed Thread
Results 1 to 20 of 20

Thread: Future PBP

  1. #1
    Join Date
    Dec 2014
    Posts
    7

    Default Future PBP

    So, what's the deal with PBP now that DT has passed? Is it abandon-ware or what? No updates in what...3+ years or so?

    I don't know about the rest of the die-hard PBP users in the world, but after over 15 years of using PBP (with a healthy smattering of straight assembly for tight & accurate code and timing) and PICs of various flavors almost exclusively for development, I find myself almost being forced to switch camps (STM32's to be a bit more specific, and yes, I know, apples and oranges, but when an STM32F415 costs the same as a PIC18Fxxxx, well, there ya go). And I don't want to switch camps. PBP has always been an absolute piece of cake to use. Almost have to due to the lack of any advancement in PBP itself. Tired of using MPLAB to write C & assembly when I could be using PBP for the "newer" chips that are now almost 3 years old.

  2. #2
    Join Date
    Dec 2014
    Posts
    7


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    Nothing?

    https://goo.gl/maps/Jnksb

    This is it?
    3 years of practically nothing new?

    Yep.

    Done and done...

    Over and/or Out...

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


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    Quote Originally Posted by skimask View Post
    Nothing?

    https://goo.gl/maps/Jnksb

    This is it?
    3 years of practically nothing new?

    Yep.

    Done and done...

    Over and/or Out...
    Hi, Skimask

    Don't tell me it's because of the shop on the left side ....

    Seriously ... it's obvious everyone of us need more and more calculating power - even for blinking the little LED - ( humour ... )

    but one day, we MUST reach 8 bits limitations ..., so, What to do ???

    I must admit THAT helps : http://www.mikroe.com/mini/pic32/ ( "thru hole" usable !!! )

    Best regards

    Alain
    ************************************************** ***********************
    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 " !!!
    *****************************************

  4. #4
    Join Date
    Dec 2014
    Posts
    7


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    Nope, not the "8-bit limitations" at all. Sure, I'd like to use PBP with the new 80 & 100 pin TQFP's. But that's not the point. There's also plenty of <28 pin PICs with newer features.

    3 years. No updates. Really?

  5. #5
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    Quote Originally Posted by skimask View Post
    Nope, not the "8-bit limitations" at all. Sure, I'd like to use PBP with the new 80 & 100 pin TQFP's. But that's not the point. There's also plenty of <28 pin PICs with newer features.

    3 years. No updates. Really?
    As you said "when an STM32F415 costs the same as a PIC18Fxxxx" why even bother.
    Why pay for overpriced toys when you can have
    professional grade tools for FREE!!!

  6. #6
    Join Date
    Aug 2006
    Location
    Look, behind you.
    Posts
    2,818


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    You know, I have an old Phillips screwdriver that I really like. I have some newer and more expensive ones, but I go to this one first. I just like it, wouldn't trade it for a new one like it. Seems PBP is like that too. My projects do not depend on the newest fancy featured PICs so PBP is here to stay for me. NOW WHEN they upgrade it to program 16 & 32 bit PICS, I will buy the upgrade. "C" is really only as good as your libraries and I HATE the syntax, I E Punctuation hassels, but then I don't write code in notepad either
    Last edited by Archangel; - 17th January 2015 at 03:27.
    If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
    .
    Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
    .
    There simply is no "Happy Spam" If you do it you will disappear from this forum.

  7. #7
    Join Date
    Dec 2014
    Posts
    7


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    Quote Originally Posted by rmteo View Post
    As you said "when an STM32F415 costs the same as a PIC18Fxxxx" why even bother.
    Somedays I couldn't agree more, but at the moment, abstraction and familiarity. I'm sure in a few years, that'll likely change completely. Familiar with PICs, know them inside and out, and I'm satisfied with the level of abstraction that PBP provides (basically the lack of the real need to know the guts), and yet can dig deep into the PICs guts when needed. Also at the moment, not very familiar with ARM, specifically the STM32F4 series, and with that, the IDEs available for the ARMs (Arduino styles/knockoffs not included) don't provide the abstraction wanted to easily kick something up quickly. Not to mention, there aren't a lot of ARMs in DIP packages. Yes, they're out there, just not a lot.

    Main point being...3 years and no updates? WTF?

    Double-dog dare anybody to find any one useful thread regarding 'updates' or a 'next version' with any meaningful information other than vapor ware.

    As for me, I'm modifying PBP to include a couple of newer choice smaller PICs as well as couple of the larger ones.
    Last edited by Demon; - 19th January 2015 at 05:48.

  8. #8
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    As long as you are doing simple hobby stuff (and DIP packages are pretty much irrelevant outside of the hobby and experimental arenas), sure, stay with PBP and PICs. If you must have a high level of abstraction in order to deal with sophisticated hardware, there are things such as STM32CubeMX.
    Why pay for overpriced toys when you can have
    professional grade tools for FREE!!!

  9. #9
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    Quote Originally Posted by rmteo View Post
    there are things such as STM32CubeMX.
    that goes with C and as Dave said earlier, some really hate that syntax. At least frustrating for me. PBP fits perfectly to my taste, the speed I test my prototypes is remarkable comparing to C and the IDE I use (Microcode Studio) is really great in its simplicity.

    Many people, many preferences, but cannot deny that there are limitations that some day are too much. For example, I made an remote receiver using keeloq decoder in firmware and in PBP is on the limit. With C the same hardware performes much better using same resources (timers, interrupts etc).

    Charles, are you listening? People are waiting (long enough) for the good news.

    Ioannis
    Last edited by Ioannis; - 17th January 2015 at 10:43.

  10. #10
    Join Date
    Dec 2014
    Posts
    7


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    2 big projects in the past 2 years. Fair money makers too. Prototyped them in PBP using 'available' PICs, and by available I mean supported by PBP, PIC18F87J50.
    Worked fine, but ran short of I/O by about 40 pins. '595's and '165's worked for the prototype, but made for a messy PCB in the final project.
    Ended up switching to the 18F97J94 and using the .asm file as a template for generating the 18F97J94 code.
    Ending up eating the extra hours in dev time re-coding.

  11. #11
    Join Date
    Oct 2009
    Posts
    583


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    I develop code for my hobby projects, so mostly thing are simple and within the capabilities of PBP out of the box. I like the structure and syntax which I find is close to the BASIC I used on computers back in the '80s so often it's easy to debug or follow someone else's code. However, I do find that it hasn't kept pace with its competitors or hardware development. The Arduino and Raspberry Pi have a strong following, with support for modern colour LCD displays, wi-fi, and a host of other peripherals, both hardware and in library files... PBP appears to be lacking commands for these items, and has relied on the likes of Darrel, Mr E, Henrik etc to come up with routines to fill gaps and make PBB work simpler or better. I'm guessing that the developing team behind PBP is small, and the resources to hand are limited which is why the likes of MikroElectronika are leagues ahead.

    The other issue I have, is that once purchased, Mikroebasic, C, Pascal etc are all a one time purchase with free updates, be that major or minor. When PB3 was launched, whilst there was an upgrade path, it still cost money. I'm sure the same will happen when / if another major release of PB comes out.

  12. #12
    Join Date
    Jul 2003
    Location
    Lancashire
    Posts
    50


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    does anyone have any meaningful information on an update to PBP3. I have used PBP since it launched and I`m comfortable with it, but I`m hitting limitations with both it and the IDE which equally hasn't updated in 3 years and of course the new PICs now available are not supported.
    Regards Pete

  13. #13
    Join Date
    Dec 2006
    Location
    Brasil, Sao Paulo, Campinas
    Posts
    54


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    I really like the PBP and also hate the C syntax. Whenever needed, I was helped by everyone here at Forun.
    Recently however, I played with the Arduino and I would love that PBP did something like libraries specific to the various devices available today as accelerometer, GPS, Bluetooth modules, pressure / temperature / humidity sensor, graphics and touch displays, and many others since do this in sometimes nail is complicated and requires further study the datasheet. The Help could also be updated with current examples of use of these devices. An improvement in the configuration of the fuses would be cool, because I think it would be easier if when choosing the pic model, already brought the template settings to the body of the program according to the version of the compiler used. I know there are many posts about it but agree, requires extra work. I was also sad about the loss of Darrel because their work helped a lot, but I believe that other colleagues will continue the improvements and in order to keep on top PBP implementations.
    Regardless of anything, I got used well PBP, are only suggestions

  14. #14
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    I just ported most of my reuseable BASIC code to C, and it is really very little drama.
    I see little reason to go back to BASIC now I can only think of a few assembly bit banging reasons
    just to make a point, but the grunt of the dsPic would probably still do it faster.

    What started as a simple project became one dsPic that runs most useful code I’ve written
    (PBP/asm code that I would use again), and a lot of C as well, with plenty of room left.

    When you write in another language a while, it’s difficult to switch back, even one you’re familiar with.
    It’s like that with C, if I write a BASIC program right now,
    it will no doubt have braces and backslash comments until I try to compile it.

  15. #15
    Join Date
    Feb 2012
    Location
    PERTH AUSTRALIA
    Posts
    838


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    yes i been slowly working my way to use C and reviewing the future of using PBP for any new projects , even simple ones

    PBP no updates in over 3 years, no support for anything other than 8bit chips , its hard to see it being more without some serious upgrades to support larger chips and features that have been long overdue

  16. #16
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    It’s more important to me than I thought. But the option to use bigger stuff.. it’s good to make the option exist, and be easy.

    Some simple ones... It would be hard to beat PBP. It’s not like I’d use a different language if I did something with a 16F877.

    Incidentally, I read in other threads at least two people say they just don’t like C syntax.
    I ported my calendar code to C for no reason because the dsPic has a calendar.
    The only symbol difference is modulus of a division is // in PBP, but that is a comment in C, so the modulus symbol in C is %.
    Something a litte more complicated LCD graphics. The only thing not written in BASIC straight into the C compiler is
    an assembler routine which could be done in BASIC anyway, and the LCDOUT command you are expected to code yourself in C.

    What I’m saying is it wouldn’t take a program as respectable as PBP that has to manage bank switching,
    talk to routine it places through intermediate variables, etc. to write a BASIC parser that converted directly to C
    and compile with Microchip C compiler taking advantage of their optimisations, etc.
    I’m not saying it would be without difficulty, but not compared with what PBP has to do.
    I don’t understand what that hasn’t been done. I would guess it is the market might not be that big.

  17. #17
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,588


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    What if you compile PBP, then use the generated assembler to compile to C?

    Robert

  18. #18
    Join Date
    Aug 2003
    Posts
    985


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    It’s the fact that the BASIC is so close to the C that would make it easier.
    When your PBP program is compiled to assembler, all of your macro commands
    like software serout, sound, pause, anything like that is moved to the beginning of code,
    and those routines called from another small section of code where you originally wrote the command.

    The simpler things like conditional branching and anything logically you do with variables stays where it is.
    It also often has to shove lookup tables at the top of the nearest code page, etc.

    Converting a BASIC program to C there would be almost none of that.
    It’s not something I’m planning to do, but someone could.. it is still a bit of an undertaking,
    but for the most part, just simple syntax conversion.

    Don’t get me wrong, it’s not all this easy, but for the most part, what is converted could just be stacked in the new file in order.

    BASIC
    Code:
    x var WORD
    y var WORD
    
    if (x == y) {x = y + 4;}
    C
    Code:
    WORD x;
    WORD y;
    
    if x = y then x = y + 4
    Last edited by Art; - 17th May 2015 at 04:48.

  19. #19
    Join Date
    Oct 2004
    Posts
    440


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    Take a look at BCX (Basic to C Converter)
    I haven't tried it and know little about it.

    Norm
    Last edited by Normnet; - 17th May 2015 at 06:11.

  20. #20
    Join Date
    Feb 2013
    Posts
    1,078


    Did you find this post helpful? Yes | No

    Default Re: Future PBP

    String variables, this is all we need....

Similar Threads

  1. Replies: 2
    Last Post: - 12th November 2014, 08:57
  2. The Future Of Hobby Electronics.
    By T.Jackson in forum Off Topic
    Replies: 53
    Last Post: - 2nd February 2009, 07:39
  3. PBP File Extension: .BAS vs .PBP
    By nedtron in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 13th February 2006, 06:48

Members who have read this thread : 2

You do not have permission to view the list of names.

Posting Permissions

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