Decline of PicBasic ?

[Scampy]

I just wanted to share an experience with you guys that is somewhat related to this project.

I've had a 2.8" SPI serial TFT screen sitting in my electronics draw for sometime, and as there is nothing (or at least my searches turned up nothing) to support these devices in PBP I opted to get an Arduino Mega and experiment with that, given that there are lots of library files readily available. Now I've never attempted programming in C++ (or the variant the Arduino platform uses) so it was a steep learning curve (learning Klingon may have been simpler). But after a few days had managed to take one of the example files and hack it about to mimic the layout on the GLCD display in my existing vivarium controller project, only better as the display is colour. So what was going to be just an experiment to prove the TFT worked was now developing into a revision of my old PIC based project.

Over the following couple of weeks I had downloaded examples for DS18B20's, DS1307 RTC, etc and with the help of a friend via e-mails adapted them to suit the projects needs. But the road was never smooth and easy. The strange syntax with brackets, semi-colons, and lack of structure like BASIC made things tricky. Simple things like reading the state of a switch and then jumping out of the main loop to a menu seems to be too low level that its complicated to detect the moment the switch is pressed. It ignores what logic would seem to be easy. For example using the included example that lights an LED when the button is pressed, substitute the making of pin high when the button is pressed to print something on the screen and it doesn't work. The biggest headache has been serial communications.... My PIC / PBP project can be updated via serial and a PC application written in Liberty Basic - it works just fine - replicating that in C++ has caused us so much frustration, whether serial ports on the processor are flakey, or there is a timing issues (no DT INT here ) we have no idea. I did manage to get reliable communications working, but that was the only thing happening, sending numbers back and forth and updating an array, add in the option of reading a single DS18B20 and displaying text on the TFT and the serial coms become unstable with data missing after transmission. I've used a com sniffer to confirm data movement, and the problem is code related.

So for me it's a shame that PBP hasn't kept pace with things like TFT screens, Ethernet etc. After this experience with C++ I realise how much I love using PBP. Maybe given the input and development of routines by Darrel PBP would have been developed further to cover these items of hardware, but sadly we lost such a wonderful person with so much expertise. I just wish I had the skill and experience to be able to develop PBP include files to use TFTs, GLCDs etc but I'm no where near that talented.

Having messed about with C++ I much prefer PBP and will, where possible, use this as my preferred language.

[richard]

So for me it's a shame that PBP hasn't kept pace with things like TFT screens

did you upgrade to pbp3 ?
did you upgrade to pbp3.1 ?


is it any wonder progress has ceased ?

if you upgraded to pbp3 the tft include I provided to the forum is a working system that everyone who has tried it has got functional
all three of them that I know of.
imho pbp is dead with a small amount of deckchair shuffling [on titanic] going on .
I now have ported nearly all my code to xc8 , the mcc is a splendid thing for the chips it supports. my last stumbling block is usb-cdc, mcc seems to have missed usb support for the ubiquitous 18f4550

[Scampy]

Hi Richard,

No I didn't upgrade at the time due to the cost and personal circumstances. Maybe it's something that I should look at, but then you have already stated that you are porting your contributions to another platform and will (by the sounds of things) no longer supporting PBP, so maybe it's not a good time for me to upgrade to PB3 given how quiet it is around here and I should consider other options.

[mpgmike]

my last stumbling block is usb-cdc, mcc seems to have missed usb support for the ubiquitous 18f4550

Frankly, after spending 2 years struggling with USB I bit the bullet & purchased HIDmaker. Using HIDmaker, I'm better understanding what I read about and fought with for 2 years. The punch line is I'm functional with USB now.

Scampy and others, a very wise man once told me, "If it is to be, it is up to me." It's nice when I can post an issue on the forum and find someone that has tackled it already. However, when I can't, I just dive in and figure it out myself. All those wonderful Audrino Include files were developed by individuals with the attitude, "If it is to be, it is up to ME!"

[Ioannis]

Mike:
1. Since arduino libs you can find online are if I may say, un-official you cannot trust them for something serious. For hobby it is ok
2. About the hid maker. Can you build a project and never worry about port settings like USB to serial converters? I mean make a really plug and play device?

Ioannis

[mpgmike]

HIDmaker creates the files needed to transfer data between the PIC (in variations of C as well as PBP) and the PC (in Visual Basic, Delphi, and I believe another tool). You get skeletal code to build around. After playing with it for a few months, I'm developing quite a sophisticated dashboard for my controllers. As for the port settings, I just find it and connect. I love HIDmaker!

[Ioannis]

That's nice. So I need to extend now on VB...

Ioannis

[mpgmike]

There is a few sites with a limited function free version. I bought the professional version of Visual Studio 2015. Of course, the newest is 2017. I also bought about a half dozen books to try to learn how to use it. I have worked with industrial PLCs & HMIs in the past which helped me grasp VB quicker than I otherwise could have. At this point I'm barely functional with VB, but I'm getting some cool things done with it.