Decline of PicBasic ?

[queenidog]

I just went through a process of selecting between Arduino, PBP/PIC, and Raspberry Pi. I have hardware for all and have used each one for a project.
My next project will use i2c which the mentioned hardware all supports. I have a bunch of Arduino boards, but programming is C++. Rasberry Pi has no good editor (like PBP), in fact the "nano" editor is 30 years out of date. I programmed Motorola assembler for years with a better editor 30 years ago!!
So, after considering all three, I'm doing my project with PIC 16F887 and PBP. Why? Best editor on the market (MicroCode Studio), tons of pin-compatible chips, easiest programming in the world, by FAR. RPI would have meant Python language which is as bad as C++. Too syntax heavy, no easy subroutine methods, hard to use labels and macros.

[Scampy]

I just went through a process of selecting between Arduino, PBP/PIC, and Raspberry Pi. I have hardware for all and have used each one for a project.
My next project will use i2c which the mentioned hardware all supports. I have a bunch of Arduino boards, but programming is C++. Rasberry Pi has no good editor (like PBP), in fact the "nano" editor is 30 years out of date. I programmed Motorola assembler for years with a better editor 30 years ago!!
So, after considering all three, I'm doing my project with PIC 16F887 and PBP. Why? Best editor on the market (MicroCode Studio), tons of pin-compatible chips, easiest programming in the world, by FAR. RPI would have meant Python language which is as bad as C++. Too syntax heavy, no easy subroutine methods, hard to use labels and macros.

I quite agree with your logic, however outside of these basic protocols such as I2C, etc PBP is seriously lagging behind the competition. Mikrobasic would appear to support all the add-on boards that they make for their development range of board. Arduino has a stack of library files for all manor of things to make projects easy to get started even if you have little understanding of C++. For me, as a casual user, the cost of upgrading to PBP3 when that came out was not an option, but I don't feel that even with this release there is native support for things such as ethernet (fixed and wifi) etc.

[mpgmike]

Like Queenidog, I occasionally look at other available options. Just looking at PIC, I compared the PBP package to Microchip's MPLAB X using CX8, and a few other things. I stay with PBP because I am comfortable with the language, first and foremost. Microchip charges $995 for their XC8, but they support it with a plethora of prefab turn-key plug-ins and code generating wizards. If you have issues, they have their forum. I saw posts where folks tried getting ahold of a live human being at Microchip for support and it was almost funny. Charles Leo (MELabs) takes my calls, answers my emails, and supports PBP very well in most areas. He is mostly a one-man show. The fact that we got the K40's in a relatively short period of time is a testament to his tenacity. As I type, he is nose-to-the-grindstone preparing the next PBP3.1.x update to include K42 and a couple other tweaks. Looking at other available options, $269 for PBP3.1 seems to be very well spent money.

With that said, I stay with PIC because Microchip keeps up-to-date with new features and new products. PIC is extremely competitive in today's MCU market. I engineer entire projects, so putting a 20-pin MCU on my board makes more sense than interfacing a daughter board (Audrino or RPi). A friend of mine that has worked at an engineering level with analog electronics since the early 1970s finally took the plunge and bought something Audrino. He couldn't fully express just how proud he was that he could control a stepper motor; adding I couldn't possibly know how difficult it was, much harder than I'd think. I gave him the verbal pat on the back, thinking how PIC has Enhanced CCP that makes it rather simple.

Go the direction that makes the most sense to you. I love the PIC/PBP package. I just wanted to share a few thoughts.

[Art]

There’s a free version of XC8, which I haven’t tried, but suspect the difference in efficiency between the free and paid version are much greater
than between the paid and free version of XC16.

XC16 is GCC which Microchip only charge for the use of optimisation options, which is rude, because Microchip didn’t contribute anything to GCC.
That said, you can always compile GCC yourself.

It’s a dream, and I’d never use PBP for a 16 bit pic even if it ever was supported. PBP will never be as developed as GCC.
The difference between C and BASIC isn’t the same as the difference between RISC assembler and BASIC.. which early on,
was the general choice you had to make for 8 bit pics (whether the BASIC meant PicBASIC or BASIC stamps).

[richard]

There’s a free version of XC8, which I haven’t tried, but suspect the difference in efficiency between the free and paid version are much greater
than between the paid and free version of XC16

.
quite possible but the free xc8 combined with the mcc is extremely useful , I have nearly converted all my libs to xc8 now and swaping between chips and chip families is just sooo easy.
debugging is fairly easy you don't even need to set watches just hover over var in ide when debugger paused to see actual value .
pbp has been left in the dust

[Art]

I’d still go for PBP over XC8 for 8 bit pics... Probably just because I feel I’d have better control over the final asm.
That’s just a gut feeling, with no real evidence, the same goes for you with your PBP experience.
But keep it up with XC8 because you’ll have no problem using a 16 or 32 bit pic.

One question: Does XC8 have a floating point math library with associated trig functions, etc. ?
If not, a dsPic project will change your life!
But there are still simple tasks that are overdone using anything other than a cheap 8 bit micro.. for that I like PBP still.

[richard]

Does XC8 have a floating point math library with associated trig functions, etc. ?

yes it does , you can select 24 or 32 bit format floats.
math.lib with sprintf add 9k to a pic16 pgm size .